From nobody Wed Apr 1 08:32:56 2020 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 4F8D73A10B1; Wed, 1 Apr 2020 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.326 X-Spam-Level: * X-Spam-Status: No, score=1.326 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 Zg5sUk6RV9J8; Wed, 1 Apr 2020 08:32:50 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 A7A413A0DBC; Wed, 1 Apr 2020 08:32:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Gyan Mishra'" , "'Robert Raszuk'" Cc: , "'Linda Dunbar'" , "'Huaimo Chen'" , References: In-Reply-To: Date: Wed, 1 Apr 2020 11:32:33 -0400 Message-ID: <000901d6083a$c74b8930$55e29b90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D60819.40411520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKSfST1hIhLqutN7AUxpygpzUbG+AFazhlRAofSi0UCFlWrfwF+743TAegh46IB3VDOsQImv3lwpoBaP8A= Content-Language: en-us X-Antivirus: AVG (VPS 200401-0, 04/01/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 15:32:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01D60819.40411520 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Gyan:=20 =20 +1 to Roberts comments. Robert, Linda and I have taken this topic off = line. If you are interested, ping.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gyan Mishra Sent: Tuesday, March 31, 2020 9:52 PM To: Robert Raszuk Cc: idr@ietf.org; Linda Dunbar; Huaimo Chen; bess@ietf.org Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi = using SDWAN SAFI to encode SDWAN Instance ID in the NLRI =20 =20 =20 Thanks Robert!! =F0=9F=91=8D =20 For me to really comprehend I have to have to put the tire to the road = and test in my Dev lab. Any caveats with Cisco XR? Ping me off list on = cisco specific reply. =20 Kind regards =20 Gyan =20 On Tue, Mar 31, 2020 at 6:43 AM Robert Raszuk wrote: Hi Gyan, =20 As topic 1 - Extended community which is used for filtering incoming = updates can be configured under BGP AF - there is nothing in the = protocol which mandates that such RTs need to be configured under VRF = section.=20 =20 As of topic 2 - This is huge misconception by many people who think that = SAFI 128 requires MPLS transport. So let me clearly state that SAFI 128 = application can happily run for many years now over pure IP transport. = VPN labels and transport paradigm are completely separate.. Hint: = RFC7510 or RFC4023. Moreover - let me also state that MPLS transport = does not bring any benefits other then few bits savings in the packet = header as compared with say IPv4 transport. Contrary it costs a lot of = complexity in the control plane and forwarding planes of the network = elements.=20 =20 Thx, R. =20 =20 =20 On Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra = wrote: =20 Robert & Linda=20 =20 Sorry to inject myself into this thread. =20 You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 is the BGP = control plane service layer overlay from PE to RR. Agreed. By default = all PEs including the SDWAN PE have RT Filtering enabled by default and = only import the RT into the VRF at the control plane level if the VRF is = configured with RT advertised by the RR is being imported by the PE, if = not the SAFI 128 prefixes are dropped. So I understand that the BGP = updates is a control plane function, but how would the routes get = imported by the PE if the VRF is not defined on the PE. RFC 4684 RTC = capability allows only the RTs imported on the PE to be advertised by = the RR to reduced the SAFI 128 route advertised by the RR that would = result in being filtered on the PE. =20 So how would that work using SAFI 128 RT to provide the network slicing = for SDWAN without VRF configured. =20 Also you mentioned that SAFI 128 L3 vpn services overlay can run over = any underlay and that does not have to be MPLS based. I know SAFI 128 = works with SR-MPLS but there you are reusing the MPLS data plane. With = SRv6 due to PM draft signaling by egress PE for end.dx instantiation, so = there is not any service label necessary as is with MPLS and thus SAFI = 128 works with SRv6. =20 How would SAFI 128 work with IP underlay used with SDWAN? =20 Even with inter-as option b c ab, with BGP LU you do have topmost label = which is via BGP labeled unicast. For inter as options if SAFI128 would = work w/o BGP LU you could just run SAFI 128 over IP. I have never tried = but I think the control plane would come up but the data plane would be = broken. =20 Kind regards=20 =20 Gyan=20 =20 On Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar = wrote: Robert,=20 =20 Want to confirm the following two points with you. Do I interpret your = words correctly?=20 =20 * If a CPE supports traditional VPN with multiple VRFs, and supports = multiple SDWAN instances, the traditional VRF configuration is still = same which are carried by BGP Route Target Extended community. =20 * For the SDWAN Instances supported by the same CPE, we can use Extended = Community with a different name (say SDWAN Target ID). When the SDWAN = Target ID is used, the SAFI 128 can be used for routes for the SDWAN = instance, with the exception that the label in the NLRI is not the MPLS = label carried by the data packets . =20 =20 Thank you.=20 =20 Linda Dunbar From: Robert Raszuk =20 Sent: Tuesday, March 24, 2020 3:32 AM To: Linda Dunbar Cc: Huaimo Chen ; idr@ietf.org; bess@ietf.org Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi = using SDWAN SAFI to encode SDWAN Instance ID in the NLRI =20 Hi Linda, =20 Nope you do not need VRFs. RT construct works at the control plane = level. VRF may be useful for traffic separation purposes on multitenant = CPEs or if you would like to relax requirements for unique IP across = SDWAN sites - but not a must otherwise.=20 =20 My main point was that BGP SAFI 128 gives you for free transport for = multiple routing contexts so why not leverage it as is?=20 =20 Moreover you may suddenly also discover that RTC (RFC4684) is your SDWAN = friend too.=20 =20 Many thx, R. =20 =20 =20 =20 On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar = wrote: Robert,=20 =20 Thank you very much for the feedback.=20 =20 If using your suggested Route Target approach to represent the SDWAN = Instance ID, does it mean that a SDWAN Edge has to use the same approach = to configure the VRF for SDWAN instances?=20 If the edge node supports both traditional VPN and SDWAN, will it cause = confusion for RT to represent both?=20 =20 RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is = encoded in the MP_REACH_NLRI Path Attribute.=20 =20 What do you mean by saying =E2=80=9Cdifferent name to Route target(s) = carried in the SAFI 128=E2=80=9D? =20 Do you mean having a different name (say SDWAN_Target) in = Extended_Communities Path Attribute, and have MP_REACH_NLRI Path = Attribute including the SAFI 128?=20 =20 SDWAN Instance ID is for the control Plane, not to be carried by the = data packets. SAFI 128 for VPN has the Label encoded in the NLRI field = that is to be carried by the data packets. But SDWAN Instance ID is not = carried by the Data Packets. Is it correct?=20 =20 Thank you.=20 Linda =20 =20 =20 =20 From: Robert Raszuk =20 Sent: Monday, March 23, 2020 2:28 PM To: Linda Dunbar Cc: Huaimo Chen ; idr@ietf.org; bess@ietf.org Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi = using SDWAN SAFI to encode SDWAN Instance ID in the NLRI =20 Hi Linda, =20 I think you are mixing data plane and control plane.=20 =20 In SDWAN data plane is of no issue as you are interconnecting sites in a = given VPN over mesh of secure tunnels.=20 =20 You are asking how to keep control plane separate between VPN instances. = This is precisely what RFC4364 does already and RT import/export is used = to indicate the instance which given set of reachability belongs. Why to = reinvent the wheel and do something new just for the heck of it :) ?=20 =20 To be original you can at best invent a different name to Route = target(s) carried in the SAFI 128 but let's keep the mechanism the same. = That would be my suggestion. =20 Kind regards, R. =20 PS. While this is obvious for some many folks are still confused. = RFC4364 does not need to run over MPLS data plane. It can run over IPSec = or over DTLS or over UDP/IP just fine.=20 =20 On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar = wrote: IDR experts: =20 SDWAN is an overlay network arching over multiple types of networks. A = SDWAN edge node may need to map client traffic to different SDWAN = network instances (or segmentations). It might not be feasible to use the AS number in the BGP message to = differentiate the SDWAN network instances as multiple SDWAN instances = may share the same AS number. =20 We would like to hear feedback from IDR group on using similar method as = Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN = Instance ID to prefixes.=20 =20 When MPLS VPN SAFI (=3D128) is present, MPLS label is carried by NLRI = [RFC8277] as: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Label |Rsrv |S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 2: NLRI with One Label =20 We would like to propose the SDWAN Instance ID being encoded in the = Label field as follows when SDWAN SAFI (=3D74 allocated by IANA) is = used,: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SDWAN Instance ID (Label) |Rsrv |S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 NLRI with SDWAN Instance ID.=20 =20 Greatly appreciate any comments or other suggestions...=20 =20 Thank you, Linda Dunbar =20 From: Huaimo Chen =20 Sent: Monday, March 23, 2020 9:14 AM To: Linda Dunbar ; idr@ietf.org Cc: bess@ietf.org Subject: Re: [Idr] FW: Is there any problem of using Private AS as = "Identifier" to differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage? =20 Hi Linda, =20 It seems that using another SAFI is a possible solution. =20 Best Regards, Huaimo _____ =20 From: Linda Dunbar Sent: Friday, March 20, 2020 12:54 AM To: Huaimo Chen ; idr@ietf.org Cc: bess@ietf.org Subject: RE: [Idr] FW: Is there any problem of using Private AS as = "Identifier" to differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage?=20 =20 Huaimo,=20 =20 Thank you very much for the suggestion.=20 Do you mean using the similar approach as VPN Label carried by NLRI Path = Attribute [RFC8277] for SDWAN Segmentation Identifier? If yes, the UPDATE message should not use the MPLS VPN SAFI (=3D128) to = avoid confusion, right?=20 =20 Linda =20 From: Huaimo Chen =20 Sent: Thursday, March 19, 2020 6:45 PM To: Linda Dunbar ; idr@ietf.org Cc: bess@ietf.org Subject: Re: [Idr] FW: Is there any problem of using Private AS as = "Identifier" to differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage? =20 Hi Linda, =20 It seems that a label may be used as an "Identifier" to = differentiate SD-WAN Segmentation. =20 Best Regards, Huaimo _____ =20 From: Idr on behalf of Linda Dunbar = Sent: Thursday, March 19, 2020 1:22 PM To: idr@ietf.org Cc: bess@ietf.org Subject: [Idr] FW: Is there any problem of using Private AS as = "Identifier" to differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage?=20 =20 BGP Experts,=20 =20 Do you know if there is any problem of using Private AS as = "Identifier" to differentiate SD-WAN Segmentation? Here is the = discussion in BESS WG. Want to get IDR WG feedbacks for this question.=20 =20 Thank you.=20 Linda =20 From: Linda Dunbar=20 Sent: Thursday, March 19, 2020 11:54 AM To: Najem, Basil ; bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: Is there any problem of using Private AS as "Identifier" to = differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage? =20 Based on Basil=E2=80=99s comment on needing an identifier to = differentiate SDWAN instances, I added a section to = draft-dunbar-bess-bgp-sdwan-usage . Want to hear people=E2=80=99s = feedback.=20 =20 3.1 Requirements 3.1.1Supporting Multiple SDWAN Segmentations The term =E2=80=9Cnetwork segmentation=E2=80=9D is used extensively in = SDWAN deployment. In general (and in this document), the = =E2=80=9CNetwork Segmentation=E2=80=9D is referring to the process of = dividing the network into logical sub-networks using isolation = techniques on a forwarding device such as a switch, router, or firewall. = For a homogeneous network, such as MPLS VPN or Layer 2 network, VRF or = VLAN are used to separate network segments.=20 As SDWAN is an overlay network arching over multiple types of networks, = it is important to have distinct identifiers to differentiate SDWAN = network instances (or segmentations). When different SDWAN network = segments do not have their own assigned AS numbers, a very easy way is = to use Private AS numbers, in the range of 64512 to 65535, to = differentiate different SDWAN segmentations.. When using BGP to control = the SDWAN networks, the Private AS numbers are carried by the BGP UPDATE = messages to their corresponding RRs. =20 Greatly appreciate any feedback on this description.=20 =20 Is there any scenario that Private AS cannot be used?=20 =20 Thank you very much.=20 =20 Linda Dunbar =20 From: Najem, Basil =20 Sent: Friday, February 7, 2020 3:02 PM To: Linda Dunbar ; bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage = description of using BGP UPDATE messages to achieve SD-WAN Application = Based Segmentation=20 =20 =20 =20 Hi Linda; =20 The SD-WAN Segment is part of the SD-WAN fabric; in other words, there = could be more than one Segment over a single underlay depending on the = design and the business requirements. =20 Each Segment represents a single and an isolated L3 domain; therefore, I = suggested that we may need to include the Segment ID in the BGP update = messages in order to identify and build the routing the table for each = Segment (based on the Segment ID). =20 Hope this helps. =20 Regards; =20 Basil =20 =20 From: Linda Dunbar =20 Sent: February-03-20 10:40 AM To: Najem, Basil ; bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: [EXT]RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage = description of using BGP UPDATE messages to achieve SD-WAN Application = Based Segmentation=20 =20 Basil,=20 =20 Thank you very much for the comments.=20 Your suggested wording change will be incorporated in the next revision. = =20 As for your suggestion of Segment and Segment ID of a SDWAN node (to be = included in the BGP UPDATE), does the =E2=80=9CSegment=E2=80=9D mean the = different Underlay?=20 In the figure below, C-PE1 has 3 WAN ports: 2 to MPLS network and 1 to = Public Internet.=20 Do you mean C-PE1 has 3 WAN =E2=80=9Csegments=E2=80=9D?=20 If not, can you elaborate more?=20 =20 =20 =20 Thanks, Linda =20 From: Najem, Basil =20 Sent: Sunday, February 02, 2020 5:48 PM To: Linda Dunbar ; bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage = description of using BGP UPDATE messages to achieve SD-WAN Application = Based Segmentation=20 =20 =20 Hello Linda; =20 I haven=E2=80=99t gone through the entire document; however, I have the = following quick comments =20 A. Regarding the following paragraph: =20 1. Augment of transport, which refers to utilizing overlay paths = over different underlay networks. Very often there are multiple parallel = overlay paths between any two SDWAN edges, some of which are private = networks over which traffic can traverse without encryption, others = require encryption, e.g. over untrusted public networks.=20 =20 The traffic that traverses the privet networks can be either encrypted = or unecrypted (in other words, the assumption that the traffic is NOT = encrypted is not always correct). I would change the parpagaph to the = following (for clarity): =20 1. Augment of transport, which refers to utilizing overlay paths = over different underlay networks. Very often there are multiple parallel = overlay paths between any two SDWAN edges, some of which are private = networks over which traffic can traverse with or without encryption, = others require encryption, e.g. over untrusted public networks.=20 =20 =20 B. Another thing that we need to discuss is the Segment ID; each Segment = (at the SD-WAN Edge) MUST have an ID. The SD-WAN Policy will map the = Application Flow to the Segment. Since the Segment is a =E2=80=9Crouting = domain=E2=80=9D, the BGP update will be exchanged with the memebers of a = particular Segment.=20 =20 As such: Should we include the Segment ID as an attribute in the BGP = update messages? Perhaps we need to further discuss this in details. =20 Any feedback is welcomed and it=E2=80=99s highly appreciated. =20 Regards; =20 Basil =20 =20 From: Linda Dunbar =20 Sent: January-31-20 5:17 PM To: bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: [EXT]solicit feedback on draft-dunbar-bess-bgp-sdwan-usage = description of using BGP UPDATE messages to achieve SD-WAN Application = Based Segmentation=20 =20 BESS participants: =20 =E2=80=9CSDWAN=E2=80=9D networks is characterized by:=20 1. Augment of transport, which refers to utilizing overlay paths = over different underlay networks. Very often there are multiple parallel = overlay paths between any two SDWAN edges, some of which are private = networks over which traffic can traverse without encryption, others = require encryption, e.g. over untrusted public networks.=20 2. Enable direct Internet access from remote sites, instead = hauling all traffic to Corporate HQ for centralized policy control.=20 3. Some traffic are routed based on application IDs instead of = based on destination IP addresses.=20 =20 =20 https://datatracker.ietf..org/doc/draft-dunbar-bess-bgp-sdwan-usage/ = describes = examples of using BGP UPDATE messages to achieve the SDWAN Application = Based Segmentation, assuming that the applications are assigned with = unique IP addresses. In the Figure below, the following BGP Updates can be advertised to = ensure that Payment Application only communicates with the Payment = Gateway: =20 =20 BGP UPDATE #1 from C-PE2 to RR for the RED P2P topology (only propagated = to Payment GW node: - MP-NLRI Path Attribute:=20 * 30.1.1.x/24 - Tunnel Encap Path Attribute * IPsec Attributes for PaymentGW ->C-PE2 =20 BGP UPDATE #2 from C-PE2 to RR for the routes to be reached by Purple: - MP-NLRI Path Attribute: * 10.1.x.x * 12.4.x.x - TunnelEncap Path Attribute: * Any node to C-PE2 =20 =20 Your feedback is greatly appreciated.=20 =20 Thank you very much.=20 =20 Linda Dunbar _____ =20 External Email: Please use caution when opening links and attachments / = Courriel externe: Soyez prudent avec les liens et documents joints=20 _____ =20 External Email: Please use caution when opening links and attachments / = Courriel externe: Soyez prudent avec les liens et documents joints=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr = =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --=20 Gyan Mishra Network Engineering & Technology=20 Verizon=20 Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com =20 =20 --=20 Gyan Mishra Network Engineering & Technology=20 Verizon=20 Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com =20 =20 ------=_NextPart_000_000A_01D60819.40411520 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Gyan:

 

+1 to Roberts comments.=C2=A0 =C2=A0=C2=A0Robert, Linda and I have = taken this topic off line.=C2=A0 If you are interested, ping. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gyan = Mishra
Sent: Tuesday, March 31, 2020 9:52 PM
To: = Robert Raszuk
Cc: idr@ietf.org; Linda Dunbar; Huaimo Chen; = bess@ietf.org
Subject: Re: [Idr] Seeking feedback of = draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN = Instance ID in the NLRI

 

 

 

Thanks Robert!! 👍

 

For me to really comprehend I have to have to put the = tire to the road and test in my Dev lab.  Any caveats with Cisco = XR?  Ping me off list on cisco specific = reply.

 

Kind regards

 

Gyan

 

On = Tue, Mar 31, 2020 at 6:43 AM Robert Raszuk <robert@raszuk.net> = wrote:

Hi Gyan,

 

As topic 1 - Extended community which is used = for filtering incoming updates can be configured under BGP AF = - there is nothing in the protocol which mandates that such RTs need to = be configured under VRF section. 

 

As of topic 2 - This is huge misconception by many = people who think that SAFI 128 requires MPLS transport. So let me = clearly state that SAFI 128 application can happily run for many years = now over pure IP transport. VPN labels and transport paradigm are = completely separate.. Hint: RFC7510 or RFC4023. Moreover - let me also = state that MPLS transport does not bring any benefits other then = few bits savings in the packet header as compared with say IPv4 = transport. Contrary it costs a lot of complexity in the control plane = and forwarding planes of the network = elements. 

 

Thx,
R.

 

 

 

On = Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra <hayabusagsm@gmail.com> = wrote:

 

Robert  & = Linda 

 

Sorry to inject myself into this = thread.

 

You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 = is the BGP control plane service layer overlay from PE to RR. = Agreed.  By default all PEs including the SDWAN PE have RT = Filtering enabled by default and only import the RT into the VRF at the = control plane level if the VRF is configured with RT advertised by the = RR is being imported by the PE, if not the SAFI 128 prefixes are = dropped.  So I understand that the BGP updates is a control plane = function, but how would the routes get imported by the PE if the VRF is = not defined on the PE.  RFC 4684 RTC capability allows only the RTs = imported on the PE to be advertised by the RR to reduced the SAFI 128 = route advertised by the RR that would result in being filtered on the = PE.

 

So how would that work using SAFI 128 RT to provide = the network slicing for SDWAN without VRF = configured.

 

Also you mentioned that SAFI 128 L3 vpn services = overlay can run over any underlay and that does not have to be MPLS = based.  I know SAFI 128 works with SR-MPLS but there you are = reusing the MPLS data plane.  With SRv6 due to PM draft signaling = by egress PE for end.dx instantiation, so there is not any service label = necessary as is with MPLS and thus SAFI 128 works with = SRv6.

 

How would SAFI 128 work with IP underlay used with = SDWAN?

 

Even with  inter-as option b c ab, with BGP LU = you do have topmost label which is via BGP labeled unicast.  For = inter as options if SAFI128 would work w/o BGP LU you could just run = SAFI 128 over IP.  I have never tried but I think the control plane = would come up but the data plane would be = broken.

 

Kind regards 

 

Gyan 

 

On = Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Robert, =

 <= /o:p>

Want to = confirm the following two points with you. Do I interpret your words = correctly?

 <= /o:p>

  • If a CPE supports traditional VPN with multiple VRFs, and = supports multiple SDWAN instances, the traditional VRF configuration is = still same which are carried by BGP Route Target Extended community. =  
  • For the SDWAN Instances supported by the same CPE, we can = use Extended Community with a different name (say SDWAN Target ID). When = the SDWAN Target ID is used, the SAFI 128 can be used for routes for the = SDWAN instance,  with the exception that the label in the NLRI is = not the MPLS label carried by the data packets . =  

 <= /o:p>

Thank you. =

 <= /o:p>

Linda = Dunbar

From:= Robert Raszuk <robert@raszuk.net>
Sent: Tuesday, = March 24, 2020 3:32 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: = Huaimo Chen <huaimo.chen@futurewei.com>; idr@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking = feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode = SDWAN Instance ID in the NLRI

 <= /o:p>

Hi = Linda,

 <= /o:p>

Nope you do = not need VRFs. RT construct works at the control plane level. VRF may be = useful for traffic separation purposes on multitenant CPEs or if = you would like to relax requirements for unique IP across SDWAN sites - = but not a must otherwise. 

 <= /o:p>

My main = point was  that BGP SAFI 128 gives you for free transport for = multiple routing contexts so why not leverage it as = is? 

 <= /o:p>

Moreover = you may suddenly also discover that RTC (RFC4684) is your = SDWAN friend too. 

 <= /o:p>

Many th= x,
R.

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Tue, Mar = 24, 2020 at 5:15 AM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Robert, =

 <= /o:p>

Thank you = very much for the feedback.

 <= /o:p>

If using = your suggested Route Target approach to represent the SDWAN Instance ID, = does it mean that a SDWAN Edge has to use the same approach to configure = the VRF for SDWAN instances?

If the edge = node supports both traditional VPN and SDWAN, will it cause confusion = for RT to represent both?

 <= /o:p>

RT is = encoded in the Extended_Communities Path Attribute, SAFI 128 is encoded = in the MP_REACH_NLRI Path Attribute.

 <= /o:p>

What do you = mean by saying =E2=80=9Cdifferent name to Route target(s) carried in the = SAFI 128=E2=80=9D?  

Do you mean = having a different name (say SDWAN_Target) in Extended_Communities Path = Attribute, and have MP_REACH_NLRI Path Attribute including the SAFI 128? =

 <= /o:p>

SDWAN = Instance ID is for the control Plane, not to be carried by the data = packets. SAFI 128 for VPN has the Label encoded in the NLRI field that = is to be carried by the data packets. But SDWAN Instance ID is not = carried by the Data Packets. Is it correct?

 <= /o:p>

Thank you. =

Linda

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

From:= Robert Raszuk <robert@raszuk.net>
Sent: Monday, = March 23, 2020 2:28 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: = Huaimo Chen <huaimo.chen@futurewei.com>; idr@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking = feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode = SDWAN Instance ID in the NLRI

 <= /o:p>

Hi = Linda,

 <= /o:p>

I think you = are mixing data plane and control = plane. 

 <= /o:p>

In = SDWAN data plane is of no issue as you are interconnecting sites in = a given VPN over mesh of secure = tunnels. 

 <= /o:p>

You are = asking how to keep control plane separate between VPN instances. = This is precisely what RFC4364 does already and RT import/export is used = to indicate the instance which given set of reachability belongs. Why to = reinvent the wheel and do something new just for the heck of it :) = ? 

 <= /o:p>

To be = original you can at best invent a different name to Route target(s) = carried in the SAFI 128 but let's keep the mechanism the same. That = would be my suggestion.

 <= /o:p>

Kind = regards,

R.

 <= /o:p>

PS. While = this is obvious for some many folks are still confused. RFC4364 does not = need to run over MPLS data plane. It can run over IPSec or over DTLS or = over UDP/IP just fine. 

 <= /o:p>

On Mon, Mar = 23, 2020 at 6:47 PM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

IDR = experts:

 <= /o:p>

SDWAN is an = overlay network arching over multiple types of networks. A SDWAN edge = node may need to map client traffic to different SDWAN network instances = (or segmentations).

It might = not be feasible to use the AS number in the BGP message to differentiate = the SDWAN network instances as multiple SDWAN instances may share the = same AS number.

 <= /o:p>

We would = like to hear feedback from IDR group on using similar method as =  Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN = Instance ID to  prefixes.

 <= /o:p>

When =  MPLS VPN SAFI (=3D128) is present, MPLS label is carried by NLRI = [RFC8277] as:

 <= /o:p>

      = 0            =        = 1            =        = 2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     |    = Length     = |            =      = Label           &n= bsp;     |Rsrv |S|

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     = |            =             &= nbsp; Prefix          =             &= nbsp;        ~<= /p>

     = ~            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

         &= nbsp;           &n= bsp; Figure 2: NLRI with One Label

 <= /o:p>

We would = like to  propose the SDWAN Instance ID being encoded in the Label = field as follows when SDWAN SAFI (=3D74 allocated by IANA) is = used,:

 <= /o:p>

      = 0            =        = 1            =        = 2            =        3

      0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     = |    Length     = |      SDWAN Instance ID = (Label)        |Rsrv = |S|

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     = |            =             &= nbsp; = Prefix           &= nbsp;           &n= bsp;       ~

     = ~            =             &= nbsp;           &n= bsp;           &nb= sp;    =           |=

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 <= /o:p>

  =             &= nbsp;         NLRI with SDWAN = Instance ID.

 <= /o:p>

Greatly = appreciate any comments or other suggestions...

 <= /o:p>

Thank = you,

Linda = Dunbar

 <= /o:p>

From:= Huaimo Chen <huaimo.chen@futurewei.com>
Sent: = Monday, March 23, 2020 9:14 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>; idr@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is = there any problem of using Private AS as "Identifier" to = differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage?

 <= /o:p>

Hi Linda,

 

    It seems that using another SAFI is = a possible solution.

 

Best Regards,

Huaimo

From: Linda = Dunbar <linda.dunbar@futurewei.com>
Sent: = Friday, March 20, 2020 12:54 AM
To: Huaimo Chen <huaimo.chen@futurewei.com>; idr@ietf.org <idr@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: RE: [Idr] FW: = Is there any problem of using Private AS as "Identifier" to = differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage?

 <= /o:p>

Huaimo, =

 

Thank you very much for the = suggestion.

Do you mean using the similar approach as = VPN Label carried by NLRI Path Attribute [RFC8277] for SDWAN = Segmentation Identifier?

If yes, the UPDATE message = should not use the MPLS VPN SAFI (=3D128) to avoid confusion, right? =

 

Linda

 

From: Huaimo Chen <huaimo.chen@futurewei.com>
Sent: = Thursday, March 19, 2020 6:45 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; idr@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is = there any problem of using Private AS as "Identifier" to = differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage?

 

Hi = Linda,

 

    It seems that a label may be used as = an "Identifier" to differentiate SD-WAN = Segmentation.

 

Best = Regards,

Huaimo

From: Idr = <idr-bounces@ietf.org> on behalf of Linda Dunbar = <linda.dunbar@futurewei.com>
Sent: = Thursday, March 19, 2020 1:22 PM
To: idr@ietf.org <idr@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: [Idr] FW: Is = there any problem of using Private AS as "Identifier" to = differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage? =

 

BGP = Experts,

 

Do you know if =  there is any problem of using  Private AS as  = "Identifier" to differentiate SD-WAN Segmentation? Here is the = discussion in BESS WG. Want to get IDR WG feedbacks for this question. =

 

Thank you. =

Linda

 

From: Linda Dunbar
Sent: Thursday, March = 19, 2020 11:54 AM
To: Najem, Basil <basil.najem@bell.ca>; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org
Su= bject: Is there any problem of using Private AS as = "Identifier" to differentiate SD-WAN Segmentation for = draft-dunbar-bess-bgp-sdwan-usage?

 

Based on Basil=E2=80=99s comment on needing an identifier = to differentiate SDWAN instances, I added a section to =  draft-dunbar-bess-bgp-sdwan-usage . Want to hear people=E2=80=99s = feedback.

 

3.1    = Requirements

3.1.1Supporting Multiple SDWAN = Segmentations

The term =E2=80=9Cnetwork = segmentation=E2=80=9D is used extensively in SDWAN deployment. In = general (and in this document), the =E2=80=9CNetwork = Segmentation=E2=80=9D is referring to the process of dividing the = network into logical sub-networks using isolation techniques on a = forwarding device such as a switch, router, or firewall. For a = homogeneous network, such as MPLS VPN or Layer 2 network, VRF or VLAN = are used to separate network segments.

As SDWAN is an = overlay network arching over multiple types of networks, it is important = to have distinct identifiers to differentiate SDWAN network instances = (or segmentations). When different SDWAN network segments do not have = their own assigned AS numbers, a very easy way is to use Private AS = numbers, in the range of 64512 to 65535, to differentiate different = SDWAN segmentations.. When using BGP to control the SDWAN networks, the = Private AS numbers are carried by the BGP UPDATE messages to their = corresponding RRs.

 

Greatly = appreciate any feedback on this description. =

 

Is there any scenario that = Private AS cannot be used? =

 

Thank you very much. =

 

Linda = Dunbar

 

From: Najem, Basil <basil.najem@bell.ca>
Sent: Friday, = February 7, 2020 3:02 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org
Su= bject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage = description of using BGP UPDATE messages to achieve SD-WAN Application = Based Segmentation =

 

 

 

Hi = Linda;

 

The SD-WAN Segment is part of the = SD-WAN fabric; in other words, there could be more than one Segment over = a single underlay depending on the design and the business = requirements.

 

Each Segment represents a single = and an isolated L3 domain; therefore, I suggested that we may need to = include the Segment ID in the BGP update messages in order to identify = and build the routing the table for each Segment (based on the Segment = ID).

 

Hope this = helps.

 

Regards;

 

Basil

 

 

From: Linda Dunbar <linda.dunbar@futurewei.com>
Sent: = February-03-20 10:40 AM
To: Najem, Basil <basil.najem@bell.ca>; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org
Su= bject: [EXT]RE: solicit feedback on = draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE = messages to achieve SD-WAN Application Based Segmentation =

 

Basil, =

 

Thank you very much for the = comments.

Your suggested wording change will be = incorporated in the next revision. =

 

As for your suggestion of = Segment and Segment ID of a SDWAN node (to be included in the BGP = UPDATE), does the =E2=80=9CSegment=E2=80=9D mean the different Underlay? =

In the figure below, C-PE1 has 3 WAN ports: 2 to MPLS = network and 1 to Public Internet.

Do you mean C-PE1 = has 3 WAN =E2=80=9Csegments=E2=80=9D?

If not, can you = elaborate more? =

 

 

 <= o:p>

Thanks, = Linda

 

From: Najem, Basil <basil.najem@bell.ca>
Sent: Sunday, = February 02, 2020 5:48 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org
Su= bject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage = description of using BGP UPDATE messages to achieve SD-WAN Application = Based Segmentation =

 

 

Hello = Linda;

 

I haven=E2=80=99t gone through the = entire document; however, I have the following quick = comments

 

  1. Regarding the following = paragraph:

 

1.       = Augment of transport, = which refers to utilizing overlay paths over different underlay = networks. Very often there are multiple parallel overlay paths between = any two SDWAN edges, some of which are private networks over which = traffic can traverse without encryption, others require encryption, e.g. = over untrusted public networks.

 

The traffic = that traverses the privet networks can be either encrypted or unecrypted = (in other words, the assumption that the traffic is NOT encrypted is not = always correct). I would change the parpagaph to the following (for = clarity):

 

1.       = Augment of transport, = which refers to utilizing overlay paths over different underlay = networks. Very often there are multiple parallel overlay paths between = any two SDWAN edges, some of which are private networks over which = traffic can traverse with or without = encryption, others require encryption, e.g. over untrusted public = networks.

 

 

  1. Another thing that we need to = discuss is the Segment ID; each Segment (at the SD-WAN Edge) MUST have = an ID. The SD-WAN Policy will map the Application Flow to the Segment. = Since the Segment is a =E2=80=9Crouting domain=E2=80=9D, the BGP update = will be exchanged with the memebers of a particular Segment. =

 

As such: Should we include the Segment ID as an attribute in the BGP = update messages? Perhaps we need to further discuss this in = details.

 

Any feedback is = welcomed and it=E2=80=99s highly appreciated.

 

Regards;<= o:p>

 

Basil

 

 

From: = Linda Dunbar <linda.dunbar@futurewei.com>
Sent: = January-31-20 5:17 PM
To: bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org
Su= bject: [EXT]solicit feedback on draft-dunbar-bess-bgp-sdwan-usage = description of using BGP UPDATE messages to achieve SD-WAN Application = Based Segmentation

 

BESS = participants:

 

=E2=80=9CSDWAN=E2=80=9D = networks is characterized by:

1.       = Augment of transport, = which refers to utilizing overlay paths over different underlay = networks. Very often there are multiple parallel overlay paths between = any two SDWAN edges, some of which are private networks over which = traffic can traverse without encryption, others require encryption, e.g. = over untrusted public networks.

2.       = Enable direct Internet = access from remote sites, instead hauling all traffic to Corporate HQ = for centralized policy control.

3.       = Some traffic are routed = based on application IDs instead of based on destination IP addresses. =

 

 

https://datatracker.ietf..org/doc/draft-dunbar-bess-bgp= -sdwan-usage/ describes examples of using BGP UPDATE messages to = achieve the SDWAN Application Based Segmentation,  assuming that = the applications are assigned with unique IP addresses.

In the Figure below, the = following BGP Updates can be advertised to ensure that Payment = Application only communicates with the Payment Gateway:

 

 

BGP UPDATE #1 from C-PE2 to = RR for the RED P2P topology (only propagated to Payment GW = node:

-        = MP-NLRI Path Attribute: =

      • 30.1.1.x/24

-        = Tunnel Encap Path = Attribute

      • IPsec Attributes for PaymentGW = ->C-PE2

 

BGP UPDATE #2 from C-PE2 to = RR for the routes to be reached by Purple:

-        = MP-NLRI Path = Attribute:

      • 10.1.x.x
      • 12.4.x.x

-      = ;  TunnelEncap Path = Attribute:

      • Any node to = C-PE2

 

 

Your feedback is greatly = appreciated.

 

Thank you very much. =

 

Linda = Dunbar

E= xternal Email: = Please use caution when opening links and attachments / = C= ourriel externe: = Soyez prudent avec les liens et documents joints =

E= xternal Email: = Please use caution when opening links and attachments / = C= ourriel externe: = Soyez prudent avec les liens et documents joints =

____________= ___________________________________
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

-- =

Gyan&= nbsp; Mishra

Netwo= rk Engineering & Technology 

Veriz= on 

Silve= r Spring, MD 20904

Phone= : 301 502-1347

Email= : gyan.s.mishra@verizon.com

 <= /o:p>

 

-- =

Gyan&= nbsp; Mishra

Netwo= rk Engineering & Technology 

Veriz= on 

Silve= r Spring, MD 20904

Phone= : 301 502-1347

Email= : gyan.s.mishra@verizon.com

 <= /o:p>

 

------=_NextPart_000_000A_01D60819.40411520-- From nobody Wed Apr 1 15:08:00 2020 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 89CC53A0FAC for ; Wed, 1 Apr 2020 15:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fneWMQbCkxtE for ; Wed, 1 Apr 2020 15:07:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9E5FD3A0FA1 for ; Wed, 1 Apr 2020 15:07:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jJlWT-00063z-Oc for idr@ietf.org; Wed, 01 Apr 2020 22:07:45 +0000 Date: Wed, 01 Apr 2020 15:07:45 -0700 Message-ID: From: Randy Bush To: Interminable Discussion Room User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: [Idr] router id X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:07:57 -0000 i have a vague memory that when v6 came along we 'fessed up to router id being essentially a nonce, though with preferred values. is there a ref somewhere? thanks. randy From nobody Wed Apr 1 15:12:08 2020 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 C6F8B3A1032 for ; Wed, 1 Apr 2020 15:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=instituut-net.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 3LvsjzGB-Mmn for ; Wed, 1 Apr 2020 15:12:05 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 B22A43A1031 for ; Wed, 1 Apr 2020 15:12:04 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id z7so1395702wmk.1 for ; Wed, 01 Apr 2020 15:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sN/HHFDApdqCZJznC1ahTVEO+OlWySA/0bNS2H+Wl7o=; b=11IcCqqM/0ibOPE0QPS/okkIXvq2l9KUlZZc92sFOINFnyujHQb9ydv8OcFDZq8O1L uJHaWFXJVP4IwlzPgwdEXh7iUCG+eAF/xcpnVYTpKrdGovTojwdHAFN+7FV/Ni9tfvKQ dlaWTxr/eELmIeC7KzsfujJ8tRC43/DByAUoSMInjgrQeScHlR2At0uIJcABRT3yoyIe GkIYkpH6ySw6XjPe/ME+dodwFJCUCIeVaqzB+1inSX/dog6YHoLkteVcOsdAdCudlZ52 KCMgmlsmwMX2kO0i2OQr2SOj2lLLCzicQw4/rhJwdICJsTcqGNBM+CbhtSRpwvANgV4Q QjGQ== 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; bh=sN/HHFDApdqCZJznC1ahTVEO+OlWySA/0bNS2H+Wl7o=; b=HMslsBnGAOy5EcAsM1OqTjjmIq4QPkbo1j6DDQkZF30FyK9j4cN1y+jU90vjQYhVNX IhGO3rk2v8TBMV6aIkilsw1Crgp+gwvtn3KmHjsVYXh6qEeQUD6cjtvKn79/4Ka5T9sK PGwdFEaViYYKx4jxtFJQDrl/bvSW6D7R7vzbJMtY2etNBzaOfKbuh/+gyvLVK5y74BIL sWZwuZZvKaVgzmzjBiyLHTfBTj73KXhQu+TijXE9lfEJ3sWO+Ke7aEeUUxXTpbOf432E r+SDBj5AaFzThCibbTwgDWilv/SSVuV5lqolMNXvsIZUcEsFcEf+uFlM0VBH6ULcO0GA rQUQ== X-Gm-Message-State: AGi0PubTqFHxMhPPb9uvBV752EW63oMj0eqKscnmeXwYP0eTyFrC6CQc RFFzUJeAtocA4KKwyvpo0XvW0zVcZz8= X-Google-Smtp-Source: APiQypIKFCKhJPTxK3cJmsyV0IMxRqZoHdAgI1HNW/wDMsLx5+f/t5YLROIhh37F2rvPuSd8pqPC3Q== X-Received: by 2002:a1c:a9ca:: with SMTP id s193mr114187wme.177.1585779122342; Wed, 01 Apr 2020 15:12:02 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id c85sm4320642wmd.48.2020.04.01.15.12.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2020 15:12:01 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id bc3f91af; Wed, 1 Apr 2020 22:12:00 +0000 (UTC) Date: Wed, 1 Apr 2020 22:12:00 +0000 From: Job Snijders To: Randy Bush Cc: Interminable Discussion Room Message-ID: <20200401221200.GZ60268@vurt.meerval.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Idr] router id X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:12:07 -0000 On Wed, Apr 01, 2020 at 03:07:45PM -0700, Randy Bush wrote: > i have a vague memory that when v6 came along we 'fessed up to router id > being essentially a nonce, though with preferred values. is there a ref > somewhere? thanks. Section 4 https://tools.ietf.org/html/rfc2545 "... The BGP Identifier is a 32 bit unsigned integer exchanged between two peers at session establishment time, within an OPEN message. This is a system wide value determined at startup which must be unique in the network and should be derived from an IPv4 address regardless of the network protocol(s) a particular BGP-4 instance is configured to convey at a given moment." Kind regards, Job From nobody Wed Apr 1 15:15:36 2020 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 1628B3A103F for ; Wed, 1 Apr 2020 15:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaKmQf3NKQfn for ; Wed, 1 Apr 2020 15:15:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 B6E093A1040 for ; Wed, 1 Apr 2020 15:15:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jJle0-00065U-1y; Wed, 01 Apr 2020 22:15:32 +0000 Date: Wed, 01 Apr 2020 15:15:30 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: Interminable Discussion Room In-Reply-To: <20200401221200.GZ60268@vurt.meerval.net> References: <20200401221200.GZ60268@vurt.meerval.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] router id X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:15:35 -0000 > Section 4 https://tools.ietf.org/html/rfc2545 nom nom From nobody Wed Apr 1 15:20:12 2020 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 1E7D93A1045 for ; Wed, 1 Apr 2020 15:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 ZrQR8HAEVpCr for ; Wed, 1 Apr 2020 15:20:08 -0700 (PDT) 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 6DE153A1041 for ; Wed, 1 Apr 2020 15:20:08 -0700 (PDT) Received: from jmbp.local ([IPv6:2601:647:4200:5811:10b0:79d2:4b05:ce8c]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id 031MK7uN067908; Wed, 1 Apr 2020 22:20:07 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4200:5811:10b0:79d2:4b05:ce8c] claimed to be jmbp.local To: Randy Bush , Interminable Discussion Room References: From: Joel Jaeggli X-Pep-Version: 2.0 Message-ID: <4074fcfc-e1ec-b86a-9741-a86661a964e3@bogus.com> Date: Wed, 1 Apr 2020 15:20:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------FA3281BBBE4FDB627AB1114E" Content-Language: en-US Archived-At: Subject: Re: [Idr] router id X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:20:10 -0000 This is a multi-part message in MIME format. --------------FA3281BBBE4FDB627AB1114E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/1/20 15:07, Randy Bush wrote: > i have a vague memory that when v6 came along we 'fessed up to router i= d > being essentially a nonce, though with preferred values. is there a re= f > somewhere? thanks. are you thinking of https://tools.ietf.org/html/rfc6286 which at least updates 4271 > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --------------FA3281BBBE4FDB627AB1114E Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBF0zjHcBCAC/VccTV8/Owi3MQVGop8umVKn4stHzV/F4/5+ixMnzkhhRsI1L 305ew6Uh+ypYkKn28X7B5+3zNIRxK+JKkV9QKufSBPFcTd41xoknMtCMSr5QZIln A61tLz2oCIdB6eiTrzI60pHwd0idCOmAEqUP8JLfaQZK9JNQ416Kb/8CHiDhkG0N 17l0EYT+uVVBlUbSAgbaw6gO2csUPeASB6oiFd9AdCBVMQsQ4Q57Giz1oFam/FJw igtZ4TG+fW8dM1k8ngyonN8RzdTwnkkPLCNrttdOfjrv9llianW9Jz48l52ViT39 S82tYLkDuNbQ0AJKK8lniYz0yvs47k5WHF/VABEBAAG0H0pvZWwgSmFlZ2dsaSA8 am9lbGphQGJvZ3VzLmNvbT6JAVQEEwEIAD4WIQTSCLPd1dloH5f5hauFzc47B3GZ 7AUCXTOMdwIbAwUJAeEzgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCFzc47 B3GZ7HcvCAChCaaK8xnP5z7bxz5y5tX15fpEzjjhz0fHe32gJ2uZblWzhX6ch/6z 2k51Pcnf0FJj788Nu+WI0kF/U81jByvbz5WPlEBm7E/D0HLxsIWkbt0AlNjiDIP8 WuTZ0Lom/m7YFzwLTN7g+MI5Jqui/LEKcKAqoo5ioGsDGOIa9Fq7/WWkx7fIYvTR pqSpPKdZs3kz1z9QvncyM3IrY7fOMD4hShCwcA2HU+rl61g6aIZmpG7LXT0ZlHfY UMk8zxL/8/S89p7ZPxhxrjDeYMPxlexmWY9KZS6Ek6ugO2udHeEDagpUpUrmqEgg tK8qSsmclqqWXWps5Bl8JLueamnwV+77uQENBF0zjHcBCADWGXodjIueeHPimoj7 55ExPKJvP8ECZProTxJ86N5xmLP9Fbs70FKSxRwv4at1fWgvEwOU9w0ibq7CT+wo neboxFsWh6GEHlskSlgr5MpqCJXSpcoHABR7aBaBecFAD2YS3Zaf7GUCHcl51Bb8 7Xuj59tS8S5RCMtQ5spAL1unLt/rIBbEaiJR24/vJQLuZAJtAeUQgy0s2daBFKfL j/7AIVGTpbFSpM3iiOOjFnvQsWapzxheLNS57OY7DaQWDsd/E8zFHcTJLpotST4r AkWnXvrCxOkFKX+WJ1TKiy8I0enIa1U8aB+9YswHy4fE3GbGqeMDjSxCziNLKKe+ MlZ1ABEBAAGJATwEGAEIACYWIQTSCLPd1dloH5f5hauFzc47B3GZ7AUCXTOMdwIb DAUJAeEzgAAKCRCFzc47B3GZ7G9dB/9mvCNEjuJVv9IdcziUFrWX8r0rZPRTw+iH 1EKxpE5RWU+LTf3dNJWz/s8pItLkevjIz4tLOdoAa8awj4xqoLkoVFr/LTU7ugaF ZksanT5/E5ZsDm/ngsdUAgOwZvalOU6cdj7Utzk1xWbGfPLnx86a8VzEaCMtzNX6 roW3zJPBcxnDekuvuHnEiAvUBDGhf2GcVafVRuyM0MOlT7jQ0B8N6mcmojJFSJvO 4jFLiT2/9vPgl4i41S3P8jbjEBQ24U26BDBuB3yNOvoaPDcRUsC1sKHHZCr1cwan 0E4HFJ5kouvANneQTsH+QtWnGZ9mtDrmR+qZ4p7+4dXve+HsG64S =3DmE9q -----END PGP PUBLIC KEY BLOCK----- --------------FA3281BBBE4FDB627AB1114E-- From nobody Wed Apr 1 15:53:42 2020 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 6B7053A0A04 for ; Wed, 1 Apr 2020 15:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-R4UqwrM347 for ; Wed, 1 Apr 2020 15:53:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D540D3A0A01 for ; Wed, 1 Apr 2020 15:53:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jJmEr-00069x-3K; Wed, 01 Apr 2020 22:53:37 +0000 Date: Wed, 01 Apr 2020 15:53:35 -0700 Message-ID: From: Randy Bush To: Joel Jaeggli Cc: Interminable Discussion Room In-Reply-To: <4074fcfc-e1ec-b86a-9741-a86661a964e3@bogus.com> References: <4074fcfc-e1ec-b86a-9741-a86661a964e3@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] router id X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:53:42 -0000 > https://tools.ietf.org/html/rfc6286 that was the one in my rotting mind. > which at least updates 4271 but it does not admit it Network Working Group Y. Rekhter, Ed. Request for Comments: 4271 T. Li, Ed. Obsoletes: 1771 S. Hares, Ed. Category: Standards Track January 2006 From nobody Wed Apr 1 17:27:24 2020 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 B3B6B3A15BB for ; Wed, 1 Apr 2020 17:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 70bu_4WSWEHw for ; Wed, 1 Apr 2020 17:27:20 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 B7F303A15BA for ; Wed, 1 Apr 2020 17:27:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; SavedFromEmail: shares@ndzh.com Date: Wed, 01 Apr 2020 20:27:13 -0400 In-Reply-To: Importance: normal From: Susan Hares To: Randy Bush , Interminable Discussion Room MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_14810439726102510" Message-ID: <1585787238_172445@FUMC-WEB2> X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] router id X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 00:27:23 -0000 ----_com.samsung.android.email_14810439726102510 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhpcyBpcyB3aHkgdGhlIDQgYnl0ZXMgYmVjYW1lIGHCoCBiZ3AgaWRlbnRpZmllci7CoFN1ZVNl bnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTNyBlZGdlLCBhbiBBVCZUIDRHIExURSBzbWFydHBo b25lCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBSYW5keSBCdXNoIDxy YW5keUBwc2cuY29tPiBEYXRlOiA0LzEvMjAgIDY6MDcgUE0gIChHTVQtMDU6MDApIFRvOiBJbnRl cm1pbmFibGUgRGlzY3Vzc2lvbiBSb29tIDxpZHJAaWV0Zi5vcmc+IFN1YmplY3Q6IFtJZHJdIHJv dXRlciBpZCBpIGhhdmUgYSB2YWd1ZSBtZW1vcnkgdGhhdCB3aGVuIHY2IGNhbWUgYWxvbmcgd2Ug J2Zlc3NlZCB1cCB0byByb3V0ZXIgaWRiZWluZyBlc3NlbnRpYWxseSBhIG5vbmNlLCB0aG91Z2gg d2l0aCBwcmVmZXJyZWQgdmFsdWVzLsKgIGlzIHRoZXJlIGEgcmVmc29tZXdoZXJlP8KgIHRoYW5r cy5yYW5keV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fSWRy IG1haWxpbmcgbGlzdElkckBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWRy ----_com.samsung.android.email_14810439726102510 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5UaGlzIGlzIHdoeSB0aGUgNCBieXRlcyBiZWNhbWUgYSZuYnNwOyBiZ3AgaWRlbnRpZmll ci4mbmJzcDs8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5T dWU8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9k aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUi IGRpcj0iYXV0byI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9 ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTNyBlZGdlLCBhbiBBVCZhbXA7VCA0 RyBMVEUgc21hcnRwaG9uZTwvZGl2PjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCIgZGly PSJhdXRvIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFJhbmR5IEJ1c2ggJmx0O3JhbmR5QHBzZy5j b20mZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogNC8xLzIwICA2OjA3IFBNICAoR01ULTA1OjAwKSA8L2Rp dj48ZGl2PlRvOiBJbnRlcm1pbmFibGUgRGlzY3Vzc2lvbiBSb29tICZsdDtpZHJAaWV0Zi5vcmcm Z3Q7IDwvZGl2PjxkaXY+U3ViamVjdDogW0lkcl0gcm91dGVyIGlkIDwvZGl2PjxkaXY+PGJyPjwv ZGl2PjwvZGl2PmkgaGF2ZSBhIHZhZ3VlIG1lbW9yeSB0aGF0IHdoZW4gdjYgY2FtZSBhbG9uZyB3 ZSAnZmVzc2VkIHVwIHRvIHJvdXRlciBpZDxicj5iZWluZyBlc3NlbnRpYWxseSBhIG5vbmNlLCB0 aG91Z2ggd2l0aCBwcmVmZXJyZWQgdmFsdWVzLiZuYnNwOyBpcyB0aGVyZSBhIHJlZjxicj5zb21l d2hlcmU/Jm5ic3A7IHRoYW5rcy48YnI+PGJyPnJhbmR5PGJyPjxicj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5JZHIgbWFpbGluZyBsaXN0PGJyPklk ckBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjxi cj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_14810439726102510-- From nobody Wed Apr 1 19:37:52 2020 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 C1A893A0856; Wed, 1 Apr 2020 19:37:37 -0700 (PDT) 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.123.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158579505773.30833.9460063822198215651@ietfa.amsl.com> Date: Wed, 01 Apr 2020 19:37:37 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-inter-as-topology-ext-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 02:37:38 -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 Extension for Inter-AS Topology Retrieval Authors : Aijun Wang Huaimo Chen Ketan Talaulikar Shunwan Zhuang Filename : draft-ietf-idr-bgpls-inter-as-topology-ext-08.txt Pages : 12 Date : 2020-04-01 Abstract: This document describes the process to build Border Gateway Protocol- Link State (BGP-LS) key parameters in inter-domain scenario, defines one new BGP-LS Network Layer Reachability Information (NLRI) type (Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let Software Definition Network (SDN) controller retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-inter-as-topology-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-inter-as-topology-ext-08 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-inter-as-topology-ext-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/ From nobody Wed Apr 1 20:24:04 2020 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 12D083A0870 for ; Wed, 1 Apr 2020 20:24:03 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2ZkdXR8UmF8 for ; Wed, 1 Apr 2020 20:24:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6437F3A086B for ; Wed, 1 Apr 2020 20:24:01 -0700 (PDT) Received: from lhreml714-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 27625B830A1EEC98423E for ; Thu, 2 Apr 2020 04:24:00 +0100 (IST) Received: from lhreml714-chm.china.huawei.com (10.201.108.65) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 2 Apr 2020 04:23:59 +0100 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 2 Apr 2020 04:23:59 +0100 Received: from DGGEML524-MBX.china.huawei.com ([169.254.1.149]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0487.000; Thu, 2 Apr 2020 11:23:55 +0800 From: wangyali To: "Acee Lindem (acee)" , "idr@ietf.org" Thread-Topic: [IDR] draft-liu-idr-flowspec-ifit-04 Thread-Index: AdYInbV/0wjgMW/CRm2a6SsEu58ISw== Date: Thu, 2 Apr 2020 03:23:55 +0000 Message-ID: <1520992FC97B944A9979C2FC1D7DB0F404DF08CC@dggeml524-mbx.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.62] Content-Type: multipart/alternative; boundary="_000_1520992FC97B944A9979C2FC1D7DB0F404DF08CCdggeml524mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] [IDR] draft-liu-idr-flowspec-ifit-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 03:24:03 -0000 --_000_1520992FC97B944A9979C2FC1D7DB0F404DF08CCdggeml524mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Acee, This is Yali. Thanks for your question on IDR Interim Meeting. Please find = my reply as follows. >>Acee: I sorta see the community (to turn on/off). Why do you want this in the flow specification. I think you just need a ta= g in the packet for IOAM. Are you trying to prevent attacks that are coming in via OAM? YW: One use case is SLA assurance of game or video service for VIP users. S= o that we can enable specific IFIT option types to these packets of target = flow that match the game or video flow specifications (e.g. source and dest= ination address, port number, DSCP). Thus desired telemetry data (e.g. pack= et loss and delay) can be exported to determine if there is QoS degradation= . So taking advantages of the automatic distribution of traffic policies supp= orted by BGP Flowspec mechanism, and the encoding formats in extended commu= nity used to propagate actions , this draft defines the IFIT Action specifi= c extended community to instruct adding a specific IFIT-Option-Types into p= ackets of flows that match the Flow Specifications as well as updating rele= vant IFIT-Data-Field in packets automatically. Best regards, Yali --_000_1520992FC97B944A9979C2FC1D7DB0F404DF08CCdggeml524mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Acee,

 

This is Yali. Thanks for your q= uestion on IDR Interim Meeting. Please find my reply as follows.=

 

>>Acee: I sorta see the c= ommunity (to turn on/off).

 Why do you want this in t= he flow specification. I think you just need a tag in the packet for IOAM.&= nbsp;

 Are you trying to prevent= attacks that are coming in via OAM?

YW: One use case is SLA assuran= ce of game or video service for VIP users. So that we can enable specific I= FIT option types to these packets of target flow that match the game or vid= eo flow specifications (e.g. source and destination address, port number, DSCP). Thus desired telemetry data (= e.g. packet loss and delay) can be exported to determine if there is QoS de= gradation.

 

So taking advantages of the aut= omatic distribution of traffic policies supported by BGP Flowspec mechanism= , and the encoding formats in extended community used to propagate actions = , this draft defines the IFIT Action specific extended community to instruct adding a specific IFIT-Option-Type= s into packets of flows that match the Flow Specifications as well as updat= ing relevant IFIT-Data-Field in packets automatically.

 

Best regards,=

Yali

--_000_1520992FC97B944A9979C2FC1D7DB0F404DF08CCdggeml524mbxchi_-- From nobody Wed Apr 1 23:27:54 2020 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 8ABA23A090C; Wed, 1 Apr 2020 23:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxVGLTZf1x6D; Wed, 1 Apr 2020 23:27:49 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4353A0908; Wed, 1 Apr 2020 23:27:42 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb5e8585d17f7-558ac; Thu, 02 Apr 2020 14:27:30 +0800 (CST) X-RM-TRANSID: 2eeb5e8585d17f7-558ac X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.53.197]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75e8585d18cf-90285; Thu, 02 Apr 2020 14:27:30 +0800 (CST) X-RM-TRANSID: 2ee75e8585d18cf-90285 From: "Weiqiang Cheng" To: Cc: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: Date: Thu, 2 Apr 2020 14:27:31 +0800 Message-ID: <00e801d608b7$ca38b640$5eaa22c0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E9_01D608FA.D85BF640" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAAmms7gAGN6EBA= Content-Language: zh-cn Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 06:27:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E9_01D608FA.D85BF640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The use case is valid. Support the adoption. B.R. Weiqiang Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 8:36 PM To: 'IDR List' Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares ------=_NextPart_000_00E9_01D608FA.D85BF640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The use = case is valid.

Support = the adoption.

 =

B.R.

Weiqiang = Cheng

 

From: Idr = [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR = List' <idr@ietf.org>
Subject: [Idr] WG Adoption - = draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - = 4/13)

 

This begins a 2 week WG adoption call for = draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at: =

https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path maximum transmission unit for = the

SR = policy via BGP. 

 

Any discussion regarding on whether one desires =

SR Policy = should be clearly distinguished from the

Technical discussions on the = mechanisms to pass SR policy MTU.

 

The questions for the people to = discuss on this draft are:

 

1) Is there a need for this = mechanism in networks using

        MPLS-SR or = SR-V6 and SR policy?

 

2) Are there any error handling issues besides what is = being

     Taken care of in = RFC7752bis-03.txt

 

3) Do you think this draft is ready to be adopted? =

     In this category, please list = any concerns you have

     regarding adoption.  This = category can include

     general concerns about = BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  =  

 

Cheers, Sue Hares  

 

 

 

 

 

------=_NextPart_000_00E9_01D608FA.D85BF640-- From nobody Thu Apr 2 04:45:32 2020 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 3E00B3A107F; Thu, 2 Apr 2020 04:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfvJ-kd92N5W; Thu, 2 Apr 2020 04:45:23 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80125.outbound.protection.outlook.com [40.107.8.125]) (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 6D7303A1079; Thu, 2 Apr 2020 04:45:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W6QU/bdTvsd0qHdnRGTZ7VNm74B49GItC5du191h1ajqUiAr2rYStYz2onssPNTjMbG34IZi9zVKwjxxGe6fC/eA5235pG4/wMybxCfSze/P7xNkXTiESKg3G7ejG01FpokS06uAOrOj6utRFResY3rbTZC4bCdBkx6VVHtkZcqbqpienqWS4fsEGPXCFtTtk9QRjFljeb1JgxjwJNqPAKydGN5sI0oVz9BJs4Nt6ZL+DM7Hvk9XI/biVqfj0dvO7DpFw7a1YwUNjwtN2OpZCivGFkY3tD/FBm3/OVG9xKoSKZ/SIpEbETZLrGzOSUXnrqNcOGFBx+bjR/kmDUvkog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WPDBIfnB9UqXnKtCKvjwQr0KRCBhAd+pJr1PoriLRY4=; b=ZB5oWa1AjN/8AWO2Hje/9OiDeduPye6PWrsVYgcrUF6NIGZ2McW6j4s7yGg7Yf5EjX7fU9CumCDYZov3J99q/8lvh/4KKx9kWpX8G3UjnRqkJb2EQQNNo1ykdt6K6c22ZdK9GyXA/Rb0pgE1PZiVICqoLG/kgtAcXPHlCpK0wzu8yWjlwp+ziEqO7scsRMAnMDDI37zLVRpUD9VCRctVdeBnABrf5dRbUrTMY/LuZsj7KGuDXms1GwZ1ihq15IbMV+rYnQTzTjJt/i+zszdMaaznTTXu+4ZiBxgJV+HNH8EzABN+jJZ6tWvFk2gONLMRZfT1SumUaQ3Lu8ecr2Y5+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WPDBIfnB9UqXnKtCKvjwQr0KRCBhAd+pJr1PoriLRY4=; b=Q6dO0uVJtpRoLKcE6RMVKIF63xF04/MHuLsIFzklewoG/zCpAAXMzvNJpQ90pOcQkJqmwbhdoPA0NY5CPxjeZDqZr48zpybcllDMJNpZVEh7+OzmZIccQncGYEw8vCnpWA++Gg9UPcvC9AOBD6swmtSdW7LmTLbQ4OcXVjt7P2k= Received: from DB7PR07MB5657.eurprd07.prod.outlook.com (20.178.85.222) by DB7PR07MB4667.eurprd07.prod.outlook.com (52.135.135.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.11; Thu, 2 Apr 2020 11:45:21 +0000 Received: from DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee]) by DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee%5]) with mapi id 15.20.2878.013; Thu, 2 Apr 2020 11:45:21 +0000 From: tom petch To: "Scharf, Michael" , "idr@ietf.org" CC: tcpm IETF list Thread-Topic: Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 Thread-Index: AdX9YZybm8xvduWhO0ywtFiDNCmPqgFQZ2TYAAS+u+ABizF/AA== Date: Thu, 2 Apr 2020 11:45:20 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D9F11D2@rznt8114.rznt.rzdir.fht-esslingen.de> , <6EC6417807D9754DA64F3087E2E2E03E2DA3BAFD@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA3BAFD@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-originating-ip: [81.131.229.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f75e123c-5298-4126-8116-08d7d6fb52c9 x-ms-traffictypediagnostic: DB7PR07MB4667: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5657.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(396003)(366004)(39860400002)(346002)(136003)(376002)(71200400001)(91956017)(81156014)(66446008)(76116006)(66946007)(5660300002)(8936002)(64756008)(66476007)(8676002)(52536014)(81166006)(966005)(66556008)(186003)(110136005)(6506007)(316002)(55016002)(9686003)(478600001)(66574012)(2906002)(26005)(7696005)(4326008)(86362001)(33656002); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZZRNoKPVvN9ZEYQPereJxBRvWXqa54h9RwQHURHbNklOXO189ec1mmZTjCS6Y9pfObgFR/XyyeaQIn3Rkbkk/iQbcVB+TFpGEypo34uZQhvYuiVXipUQHBb4c6LAogu+ew+whCusnl1OjEEVDtYO4qOGxoS/6W2vTiJ9CkzbwC2ocp8Mfe8SS3OeXmz1azJoN8EO9OPbR8Miti8zP8nRl3pzdI3EnZUEvwme03mFNayA/q9i+Kr60uCyswzqwuTCmFan3CCfRACoMLy/Q9WJy7BXma215odrem1ILMNjVEmNSfsOJ99yWhIwvMg3NMfaQTYPSILkprQzvezubUTBix0uFUMfvgs+WE8imqdvpjD3fjr6jR26/qXqCAx9x1ishXmHdriFTssmZNooe85oZQEErhFW1Ok/dc8u/PV1C8tM5gwKwbvlYaAkb5dHZBclPnp3zWWiCDLfMG4JBbYoMPL8K4LfDMV1PeGFikYCjTZM0Qm5hpBbvXmMOK5DCXHzbBBwIT9bJNUvmo1Gk0dZ4A== x-ms-exchange-antispam-messagedata: ksxkZUZ7rBl9Q7WjGLXQmibnq3zUUTeUwz35RifmNAMN52sH6OqRv29Beuou8Ql0th8tT52YGKgbSmpxttfnSapVc3QM1oAhGiGUz1269Y6rFEIE/j4EWXcPbGDWP+hnS8tlQMcJt2BXoVAbVt1yYQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: f75e123c-5298-4126-8116-08d7d6fb52c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 11:45:20.8198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eafUr0ePkuzggerqmmQOypE4BSSh6UnhLg+o1Fr1cRDP8ydhnFfRbuJ5zmBYBc2OUKXAUYoUfyVugxA0C+j+6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4667 Archived-At: Subject: Re: [Idr] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 11:45:30 -0000 Michael,=0A= apologies, this got lost - inline=0A= =0A= From: Scharf, Michael =0A= Sent: 25 March 2020 16:39=0A= =0A= Hi Tom,=0A= =0A= > -----Original Message-----=0A= > From: tom petch =0A= > Sent: Wednesday, March 25, 2020 1:53 PM=0A= >=0A= > From: Idr on behalf of Scharf, Michael=0A= > =0A= > Sent: 18 March 2020 20:12=0A= >=0A= > Hi all,=0A= >=0A= > This is a heads-up regarding the ongoing adoption call for draft-scharf-t= cpm-=0A= > yang-tcp-04 in TCPM.=0A= >=0A= > =0A= > Michael=0A= >=0A= > I note that you have also sent this to Netconf and that you import groupi= ngs=0A= > from the netconf-tcp draft which makes the netconf draft a Normative=0A= > Reference except that this I-D does not mention that fact.=0A= =0A= [I-D.ietf-netconf-tcp-client-server] is listed as first normative reference= in draft-scharf-tcpm-yang-tcp and that dependency is also mentioned in the= abstract. With the current structure of the models, it is not clear to me = why a reference in the reverse direction would be needed.=0A= =0A= =0A= RFC8407 says that YANG import must have a reference which must be a Normati= ve Reference for the I-D.=0A= =0A= So far, the feedback from the NETCONF chairs was that draft-ietf-netconf-tc= p-client-server would most likely finish before a TCPM document. The work i= n the NETCONF WG started much earlier.=0A= =0A= =0A= I note that the chair is also the author:-)=0A= =0A= > I think this is problematic. Progress on the netconf I-D has been slow f= or some=0A= > years and so your I-D could have to wait a while. The solution would be = to=0A= > progress the netconf draft but I do not know how this can be expedited.= =0A= =0A= That is an interesting line of thought. Actually, when I wear the hat of a = co-chair of TCPM, I get told again and again that TCPM is too slow... We cu= rrently try our best to speed up a bit. However, due to the complexity of T= CP, the heterogeneity of implementations, and the scale of deployment of th= e protocol, TCPM needs some time to process documents. This would almost ce= rtainly also apply to a YANG model. In addition, TCPM has not dealt with YA= NG so far, i.e., it is a new topic for the working group.=0A= =0A= Realistically, even if we as authors try our best, the normative reference = to the netconf I-D would only become a problem if that document does not pr= ogress at all for a longer time.=0A= =0A= Would you prefer a TCPM document without that normative reference? In any c= ase, I doubt that timing should be the main motivation for that. Would ther= e be other reasons?=0A= =0A= =0A= I see TCPM as the best of source of information about TCP in the IETF and s= o best qualified to produce an accurate YANG module which other WG then imp= ort. The downside is that TCP has so many facets that the temptation will = be to produce the kitchen sink which is never complete; but with ruthless c= ontrol from Chairs and AD to keep a limit on the scope then I think that th= e TCPM WG is the place for it.=0A= =0A= Tom Petch=0A= =0A= > There are a lot of details in this I-D that I think of as admin which nee= d fixing to=0A= > conform to YANG Guidelines but would not see that as a bar to adoption=0A= > whereas dependency on netconf is more debatable IMHO.=0A= =0A= Indeed, many details require further work. That is well understood.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= =0A= > Tom Petch=0A= >=0A= >=0A= > You may want to pay attention. For instance, this document defines groupi= ngs=0A= > for TCP-AO and MD5, which are used by draft-ietf-idr-bgp-model.=0A= >=0A= > If you support work of this document in TCPM, or if you have any comments= ,=0A= > please free to provide feedback on the TCPM list (tcpm@ietf.org).=0A= >=0A= > Thanks=0A= >=0A= > Michael (TCPM chair hat off)=0A= >=0A= >=0A= > Von: Michael Tuexen=0A= > Gesendet: Montag, 16. M=E4rz 2020 21:44=0A= > An: tcpm IETF list=0A= > Cc: draft-scharf-tcpm-yang-tcp@ietf.org tcp@ietf.org>=0A= > Betreff: Request for feedback on WG adoption of draft-scharf-tcpm-yang-tc= p-04=0A= >=0A= > Dear all,=0A= >=0A= > this mail starts a WG adoption call for=0A= > https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-04=0A= >=0A= > So I would like to solicit feedback regarding support for or objections a= gainst=0A= > the=0A= > adoption of the document as a WG document in TCPM.=0A= >=0A= > Please provide feedback before March 31st.=0A= >=0A= > For the context and current state of the document, see the presentation s= ent=0A= > yesterday=0A= > to the mailing list by Mahesh.=0A= >=0A= > Best regards=0A= > Michael=0A= >=0A= >=0A= =0A= From nobody Thu Apr 2 06:48:44 2020 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 B26943A129E for ; Thu, 2 Apr 2020 06:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aedOEQ6OTjfZ for ; Thu, 2 Apr 2020 06:48:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A463A129B for ; Thu, 2 Apr 2020 06:48:39 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6166DE29B5A8E2228BE7 for ; Thu, 2 Apr 2020 14:48:37 +0100 (IST) Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 2 Apr 2020 14:48:36 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme754-chm.china.huawei.com (10.3.19.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 2 Apr 2020 21:48:34 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1713.004; Thu, 2 Apr 2020 21:48:34 +0800 From: "Dongjie (Jimmy)" To: 'IDR List' CC: Susan Hares , John Scudder Thread-Topic: [Idr] Draft agenda of IDR virtual interim on April 8th\\RE: IDR virtual Interims - March 30th and April 8th - Please comment within 8 hours Thread-Index: AdYI9TY11/kI+fdFQeC4SKi0/zIlsw== Date: Thu, 2 Apr 2020 13:48:34 +0000 Message-ID: <36b877c792f942c38fe331196087b22b@huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.171.254] Content-Type: multipart/alternative; boundary="_000_36b877c792f942c38fe331196087b22bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] Draft agenda of IDR virtual interim on April 8th\\RE: IDR virtual Interims - March 30th and April 8th - Please comment within 8 hours X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 13:48:42 -0000 --_000_36b877c792f942c38fe331196087b22bhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here is the draft agenda of the second virtual interim on April 8th, Please= let me and the chairs know whether you have other topic to present & discu= ss on the meeting. Presenters, please remember to send your slides to me and CC the chairs by = end of April 6th (Monday). 1.Administrivia 5 minutes 2. BGP YANG Model Status and Issues Draft: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-08 Presenter: Mahesh Jethanandani Time period: 5 minutes 3. Presentations - new drafts or status updates 1) Flowspec for L2 and Tunneled Traffic Draft: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13 https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-08 Presenter: Donald Eastlake Time period: 15 minutes 2) BGP Well-known Large Communities Draft: https://tools.ietf.org/html/draft-heitz-idr-wklc-00 Presenter: Jakob Heitz Time period: 10 minutes 3) SDWAN WAN Ports Property Advertisement in BGP UPDATE (moved from= 1st interim) Draft: https://tools.ietf.org/html/draft-dunbar-idr-sdwan-port-safi-06 Presenter: Linda Dunbar Time period: 10 minutes 4) BGP Extended Community Registries Update Draft: https://tools.ietf.org/html/draft-cl-idr-bgp-ext-com-registry-update= -00 Presenter: Christoph Loibl Time period: 10 minutes Best regards, Jie From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) Sent: Tuesday, March 24, 2020 10:59 PM To: 'IDR List' Cc: Susan Hares Subject: [Idr] Draft agenda of IDR virtual interim on March 30th\\RE: IDR v= irtual Interims - March 30th and April 8th - Please comment within 8 hours Hi all, Here is the draft agenda of the first IDR virtual interim on March 30th. Pl= ease check whether your slot request is included correctly. Presenters, please remember to send your slides to me and CC the chairs by = end of March 28th (Saturday). Best regards, Jie IDR Virtual meeting 1: 9-12pm EDT on 3/30/2020 Information about remote participation: https://ietf.webex.com/meet/idr Draft agenda: 1. Chairs' slides - 2020 in IDR 10 mins 2. What's next in Flow Specification 20 mins 3. Progress report from Auto-Configuration Design team 20 mins 4. Presentations - new drafts or status updates 80 mins 1) draft-shen-idr-flexible-color-tunnel-selection-01 Draft: https://tools.ietf.org/html/draft-shen-idr-flexible-color-tunnel-sel= ection-01 Presenter: Yimin Shen Time period: 10 minutes 2) draft-li-ldr-bgp-request-cp-sr-te-policy-01 Draft: https://tools.ietf.org/html/draft-li-ldr-bgp-request-cp-sr-te-policy= -01 Presenter: Huaimo Chen Time period: 10 minutes 3) draft-chen-idr-ctr-availability-00 Draft: https://tools.ietf.org/html/draft-chen-idr-ctr-availability-00 Presenter: Huaimo Chen Time period: 10 minutes 4) draft-qin-idr-sr-policy-ifit-00 Draft: https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit-00 Presenter: Giuseppe Fioccola Time period: 10 minutes 5) draft-wang-lsr-ifit-node-capability-advertisement-00 Draft: https://tools.ietf.org/html/draft-wang-lsr-ifit-node-capability-adve= rtisement-00 Presenter: Yali Wang Time period: 10 minutes 6) draft-liu-idr-flowspec-ifit-04 Draft: https://tools.ietf.org/html/draft-liu-idr-flowspec-ifit-04 Presenter: Yali Wang Time period: 10 minutes 7) draft-dunbar-idr-sdwan-port-safi-06 Draft: https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-port-safi Presenter: Linda Dunbar Time period: 10 minutes 8) draft-ietf-idr-bgp-open-policy-08 Draft: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-08 Presenter: Randy Bush/Alexander Azimov Time period: 10 minutes From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Saturday, March 21, 2020 12:42 AM To: 'IDR List' > Subject: [Idr] IDR virtual Interims - March 30th and April 8th - Please com= ment within 8 hours Greetings: The IESG allotted IDR two times slots: March 30th, and April 8th. John = and I have decided to sign up for both slots. Virtual interims work best as a combination of discussion topics and draft = presentations. The times for the IDR interims will be: 9-12pm on 3/30/2020 These time slots are early for the US-West coast, and late for Japan/China. However, it seems like everyone can attend. Topics: 1) chairs status - 2020 in IDR 2) What's next in Flow Specification 3) Progress report from Auto-Configuration Design team 4) Presentations - new drafts or status updates 9-11pm on 4/8/2020 1) Flow-Specification - Next Generation ideas 2) BGP Model issues 3) Presentations - new drafts or status updates For a draft presentation slot, you need to have an IDR Draft submitted 1 we= ek ahead of the date. For 3/30, you need a draft submitted by 3/23. For 4/8, you need a draft submitted by 4/1. For a presentation for the topic issue: a) Flow specific b) Progress report from Auto-Configuration Design team, c) BGP Model issues, or d) your topic. You only need a slide set. If you are proposing a topic for 4/8/2020, Please send a note to the chairs. Proposing a topic does not mean the topic will be accepted. I will submit a request for these times slots today by 8pm. If you have any wild concerns send a note to the chairs or the list. Cheers, Susan Hares --_000_36b877c792f942c38fe331196087b22bhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here is the draft agenda of the second virtual interim on April 8= th, Please let me and the chairs know whether you have other top= ic to present & discuss on the meeting.

 

Presenters, please remember to send your slides to me and CC the chairs= by end of April 6th (Monday).

 

1.Administrivia   5 m= inutes

=  

2. BGP YANG Model Status and Is= sues

Draft: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-08

Presenter: Mahesh Jethanandani =

Time period: 5 minutes &nb= sp; 

 

3. Presentations – new dr= afts or status updates

 

1)    = ;  Flowspec for L2 and Tunneled Traffic=

Draft: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13=

      =       https://tools.ietf.org/html/draft-ietf-idr= -flowspec-nvo3-08

Presenter: Donald Eastlake=

Time period: 15 minutes

 

2)    = ;  BGP Well-known Large Communities

Draft: https://tools.ietf.org/html/draft-heitz-idr-wklc-00

Presenter: Jakob Heitz

Time period: 10 minutes

 

3)    = ;  SDWAN WAN Ports Property Advertisement in BGP U= PDATE    (moved from 1st interim)

Draft: https://tools.ietf.org/html/draft-dunbar-idr-sdwan-port-safi-06

Presenter: Linda Dunbar

Time period: 10 minutes

 

4)    = ;  BGP Extended Community Registries Update

Draft: https://tools.ietf.org/html/draft-cl-idr-bgp-ext-com-registry-update-00=

Presenter: Christoph Loibl=

Time period: 10 minutes

 

Best regards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Tuesday, March 24, 2020 10:59 PM
To: 'IDR List' <idr@ietf.org>
Cc: Susan Hares <shares@ndzh.com>
Subject: [Idr] Draft agenda of IDR virtual interim on March 30th\\RE= : IDR virtual Interims - March 30th and April 8th - Please comment within 8= hours

 

Hi all,

 

Here is the draft agenda of the first IDR virtual interim on Marc= h 30th. Please check whether your slot request is included corre= ctly.

 

Presenters, please remember to send your slides to me and CC the = chairs by end of March 28th (Saturday).

 

Best regards,

Jie

 

 

IDR Virtual meeting 1: 9-12p= m EDT on 3/30/2020

 

Information about remote par= ticipation:

https://ietf.webex.com/meet/idr

 

Draft agenda:

 

1. Chairs’ slides &= #8211; 2020 in IDR     10 m= ins

 

2. What’s next in Flow Specification    20 mins

 

3. Progress report from Auto= -Configuration Design team     20 mins

 

4. Presentations – new drafts or status updates    = ;     80 mins

 

1) draft-shen-idr-flexible-c= olor-tunnel-selection-01

Draft: https://tools.ietf.org/html/draft-shen-idr-flexible-color-tunnel-selection-= 01

Presenter: Yimin Shen

Time period: 10 minutes=

 

2) draft-li-ldr-bgp-request-= cp-sr-te-policy-01

Draft: https://tools.ietf.org/html/draft-li-ldr-bgp-request-cp-sr-te-policy-01=

Presenter: Huaimo Chen<= /o:p>

Time period: 10 minutes=

 

3) draft-chen-idr-ctr-availa= bility-00

Draft: https://tools.ietf.org/html/draft-chen-idr-ctr-availability-00

Presenter: Huaimo Chen<= /o:p>

Time period: 10 minutes=

 

4) draft-qin-idr-sr-policy-i= fit-00

Draft: https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit-00<= /span>

Presenter: Giuseppe Fioccola=

Time period: 10 minutes=

 

5) draft-wang-lsr-ifit-node-= capability-advertisement-00

Draft: https://tools.ietf.org/html/draft-wang-lsr-ifit-node-capability-advertiseme= nt-00

Presenter: Yali Wang

Time period: 10 minutes=

 

6) draft-liu-idr-flowspec-if= it-04

Draft: https://tools.ietf.org/html/draft-liu-idr-flowspec-ifit-04

Presenter: Yali Wang

Time period: 10 minutes=

 

7) draft-dunbar-idr-sdwan-po= rt-safi-06

Draft: https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-port-safi<= /o:p>

Presenter: Linda Dunbar=

Time period: 10 minutes=

 

8) draft-ietf-idr-bgp-open-p= olicy-08

Draft: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-08

Presenter: Randy Bush/Alexan= der Azimov

Time period: 10 minutes=

 

 

 

From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares
Sent: Saturday, March 21, 2020 12:42 AM
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] IDR virtual Interims - March 30th and April 8th - Ple= ase comment within 8 hours

 

Greetings:

 

The IESG allotted IDR two times= slots:  March 30th, and April 8th.  &= nbsp; John and I have decided to sign up for both slots.

Virtual interims work best as a= combination of discussion topics and draft presentations.

 

The times for the IDR interims = will be:

9-12pm on 3/30/2020<= /span>

 

These time slots are early for = the US-West coast, and late for Japan/China.

However, it seems like everyone= can attend. 

 

Topics:

1) chairs status – 2020 i= n IDR

2) What’s next in Flow Sp= ecification

3) Progress report from Auto-Co= nfiguration Design team

4) Presentations – new dr= afts or status updates

 

9-11pm on 4/8/2020 <= /span>

1) Flow-Specification – N= ext Generation ideas

2) BGP Model issues  =

3) Presentations – new dr= afts or status updates

 

For a draft presentation slot, = you need to have an IDR Draft submitted 1 week ahead of the date.

For 3/30, you need a draft subm= itted by 3/23.   

For 4/8, you need a draft submi= tted by 4/1.

 

For a presentation for the topi= c issue:

a) Flow specific

b) Progress report from Auto-Co= nfiguration Design team,

c) BGP Model issues, or

d) your topic.

 

You only need a slide set. = ;  If you are proposing a topic for 4/8/2020,

Please send a note to the chair= s.  Proposing a topic does not mean

the topic will be accepted.

 

I will submit a request for the= se times slots today by 8pm.  

 If you have any wild conc= erns send a note to the chairs or the list.

 

Cheers,  Susan Hares =

 

--_000_36b877c792f942c38fe331196087b22bhuaweicom_-- From nobody Thu Apr 2 11:01:07 2020 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 29FEF3A0FD5; Thu, 2 Apr 2020 11:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 khQjqi1gV6jy; Thu, 2 Apr 2020 11:01:03 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 6E7393A1028; Thu, 2 Apr 2020 11:01:01 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id a20so5476774edj.2; Thu, 02 Apr 2020 11:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=OWX9b+jjRF/5iF/XY4f5rQslXik/FVSnhF5+rDZQtQQ=; b=IZ6AqP0UWIBK1FTy3w3vU/I2JVsaTUV1+KFuV0jz7rHxz7et/U5OpOu3LCZPvuWEiP rYonPQWas8oHci8I7+nw78si6V3jD1ThATDj/YjmS+A5CHhZQIpgiOdr2QAY61bJ0zlE TCk8743ek0RPfSDdfhSVUssEXwWbt9YwWnEx1xo8lQm77SV729P4DlKXhxO0251U51qN pYNwTdMcKuJDJBFLMdemLyadbR/O3LLwRLepnxZliOiDJRnMo6qGpRUMH65UYnKIK7At 2dzxQDV7/kbdeNVae9cK7cvWuJ+qgq1ivKUqGYZ6Tt44NkhmswvwGsyZGfPSb7CpcIj4 AjeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=OWX9b+jjRF/5iF/XY4f5rQslXik/FVSnhF5+rDZQtQQ=; b=aW89ikawM8muAu/yEaUw4tyqtOwwFtKxEivLRh+7wbocTmpV/FZxb1xNbMnIV7Jk0t qZHteoy7l9geVP5RL0yBrvQgb7ajYNf9fnolaJ4VYjcv6BapLgPQHqqdA4/0buUqwqkA 7gBbVqDJsxL0LrhBdUn4xLKmNA295RYguAxnt99oGGa/L7ki+WmjpKZ+uVyxFyMA88/H lkWaKRbtl/zSSFiOw5+nDsPQCBVQtUrWqv7in6D27ur88AKL46AsI9YwUIry7+ZS+kkE C4au3kiNMpB3FacGPQsIqlfI8UHwqymC00gYc138zwcQcQh1u1cKLW15rBjfIQHp9xve yeZA== X-Gm-Message-State: AGi0PubJkAjp6iqh/vGtEqqI8+05ZE+YXTihlwrG27cHNo/99xqtWNXX CEmTyqa87ftr4Yq7mHfbio+/429Yxphfnt3+DaqlftpY X-Google-Smtp-Source: APiQypKwPnCZ3t5BNvPco0vvdiu4LBkYnVDBYMBuGQ7EpH/Z2SO/aYJQl4XIZVJs0jSMqpYEO16CV5wH6FMN1jYmTeg= X-Received: by 2002:a50:ab1e:: with SMTP id s30mr4305026edc.336.1585850459602; Thu, 02 Apr 2020 11:00:59 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 2 Apr 2020 14:00:58 -0400 From: Alvaro Retana In-Reply-To: References: <66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark> MIME-Version: 1.0 Date: Thu, 2 Apr 2020 14:00:58 -0400 Message-ID: To: "draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org" , "Ketan Talaulikar (ketant)" , Jeff Tantsura Cc: Susan Hares , "idr-chairs@ietf.org" , "idr@ietf. org" Content-Type: multipart/alternative; boundary="0000000000004fc38405a2529590" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 18:01:05 -0000 --0000000000004fc38405a2529590 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeff: Hi! Just one more thing =E2=80=94 now the you took that out, we don=E2=80=99t n= eed =C2=A75 anymore. I=E2=80=99m going to start the IETF LC. Feel free to remove =C2=A75 when y= ou address any LC comments that may come in. Thanks!! Alvaro. On March 30, 2020 at 6:13:28 PM, Jeff Tantsura (jefftant.ietf@gmail.com) wrote: As communicated by Ketan, the authors have decided to address MSD in BGP-only networks someplace else. v16 has been published to reflect this change. --0000000000004fc38405a2529590 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Jeff:

Hi!

J= ust one more thing =E2=80=94 now the you took that out, we don=E2=80=99t ne= ed =C2=A75 anymore.

I=E2=80=99m going to start the IETF LC.=C2=A0 Feel free to remove =C2=A75 = when you address any LC comments that may come in.

Thanks!!

Alvaro.

On March 30= , 2020 at 6:13:28 PM, Jeff Tantsura (jefftant.ietf@gmail.com) wrote:

As communicated by Ketan, the authors have decided to address=C2=A0= =C2=A0MSD in BGP-only networks someplace else.
v16 has been published to reflect this chan= ge.

=
--0000000000004fc38405a2529590-- From nobody Thu Apr 2 11:06:53 2020 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 771443A0486; Thu, 2 Apr 2020 11:06:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr@ietf.org, Susan Hares , shares@ndzh.com, aretana.ietf@gmail.com, idr-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158585079435.26366.1343069688827418363@ietfa.amsl.com> Date: Thu, 02 Apr 2020 11:06:34 -0700 Archived-At: Subject: [Idr] Last Call: (Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 18:06:35 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-04-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3273/ https://datatracker.ietf.org/ipr/3023/ From nobody Fri Apr 3 00:39:19 2020 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 8C6333A133D for ; Fri, 3 Apr 2020 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nBFsANRwp88 for ; Fri, 3 Apr 2020 00:39:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2793A1339 for ; Fri, 3 Apr 2020 00:39:08 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0310F9EEBFA5B3E01E93 for ; Fri, 3 Apr 2020 08:39:01 +0100 (IST) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 3 Apr 2020 08:38:31 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.59]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Fri, 3 Apr 2020 15:38:26 +0800 From: "Chengli (Cheng Li)" To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC+IftQ Date: Fri, 3 Apr 2020 07:38:26 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029A907Bdggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 07:39:17 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB029A907Bdggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, I support this document to be adopted since the mechanism is useful and the= text is mature. 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? [Cheng ] Yes. The PMTU should be calculated and set for SID list in order t= o appropriately encapsulate SRv6 Packet. Also, overhead of BSID and FRR should be considered when calculating PMTU,= so it will be good to provide a protocol interface for Controller to set t= he PMTU for SID list based on different PMTU considerations. 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt [Cheng] I think no. But the error handling should align with the error hand= ling in https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-polic= y-08#section-5 Will update it in next revision. [ When the error determined allows for the router to skip the malformed NLRI(s) and continue processing of the rest of the update message, then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'. ] 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. [Cheng]I think it is ready to be adopted. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 8:36 PM To: 'IDR List' Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_C7C2E1C43D652C4E9E49FE7517C236CB029A907Bdggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

I support this documen= t to be adopted since the mechanism is useful and the text is mature.<= /o:p>

 

 

1) Is there a need for this mechanism in networks us= ing

        MPLS= -SR or SR-V6 and SR policy?

 

[Cheng ] Yes. The PMTU= should be calculated and set for SID list in order to appropriately encaps= ulate SRv6 Packet.

Also,  overhead o= f BSID and FRR should be considered when calculating PMTU, so it will be go= od to provide a protocol interface for Controller to set the PMTU for SID l= ist based on different PMTU considerations.

 

 

2) Are there any error handling issues besides what = is being

     Taken care of in RFC77= 52bis-03.txt

 

[Cheng] I think no. Bu= t the error handling should align with the error handling in https://tools.ietf.org/html/draft-ietf-idr-segmen= t-routing-te-policy-08#section-5

Will update it in next= revision.

 

[
 
When the error determined allows for the r=
outer to skip the malformed

   NLRI(s) and continue processing o= f the rest of the update message,

   then it MUST handle such malforme= d NLRIs as 'Treat-as-withdraw'.

]

 

3) Do you think this draft is ready to be adopted? <= o:p>

     In this category, plea= se list any concerns you have

     regarding adoption.  T= his category can include

     general concerns about= BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  =  

 

[Cheng]I think it is r= eady to be adopted.

 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoption call for draft-li-i= dr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org/doc/draft-li-idr-sr-= policy-path-mtu/

 

This draft distributes path maximum transmission uni= t for the

SR policy via BGP. 

 

Any discussion regarding on whether one desires

SR Policy should be clearly distinguished from the <= o:p>

Technical discussions on the mechanisms to pass SR p= olicy MTU.

 

The questions for the people to discuss on this draf= t are:

 

1) Is there a need for this mechanism in networks us= ing

        MPLS= -SR or SR-V6 and SR policy?

 

2) Are there any error handling issues besides what = is being

     Taken care of in RFC77= 52bis-03.txt

 

3) Do you think this draft is ready to be adopted? <= o:p>

     In this category, plea= se list any concerns you have

     regarding adoption.  T= his category can include

     general concerns about= BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  =  

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_C7C2E1C43D652C4E9E49FE7517C236CB029A907Bdggeml529mbxchi_-- From nobody Fri Apr 3 00:53:19 2020 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 B1C1D3A1396 for ; Fri, 3 Apr 2020 00:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzDhKqzwdZDf for ; Fri, 3 Apr 2020 00:53:15 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18453A1395 for ; Fri, 3 Apr 2020 00:53:14 -0700 (PDT) Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9344D3498047EB769786 for ; Fri, 3 Apr 2020 08:53:13 +0100 (IST) Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 3 Apr 2020 08:53:12 +0100 Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 3 Apr 2020 08:53:12 +0100 Received: from DGGEMM529-MBS.china.huawei.com ([169.254.14.174]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0487.000; Fri, 3 Apr 2020 15:53:08 +0800 From: Huzhibo To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/aB4Q Date: Fri, 3 Apr 2020 07:53:08 +0000 Message-ID: <06CF729DA0D6854E8C1E5121AC3330DFAF5D9355@dggemm529-mbs.china.huawei.com> References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.202.126] Content-Type: multipart/alternative; boundary="_000_06CF729DA0D6854E8C1E5121AC3330DFAF5D9355dggemm529mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] =?gb2312?b?tPC4tDogIFdHIEFkb3B0aW9uIC0gZHJhZnQtbGktaWRy?= =?gb2312?b?LXNyLXBvbGljeS1wYXRoLW10dS0wMy50eHQgLSAyIFdlZWsgV0cgYWRvcHRp?= =?gb2312?b?b24gY2FsbCAoMy8zMCAtIDQvMTMp?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 07:53:17 -0000 --_000_06CF729DA0D6854E8C1E5121AC3330DFAF5D9355dggemm529mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VHJhZGl0aW9uYWwgTVBMUyB1c2VzIHRoZSBMRFAgLyBSU1ZQIHByb3RvY29sIHRvIG9idGFpbiB0 aGUgUGF0aCBNVFUuIFNlZ21lbnQgUm91dGluZyByZW1vdmVzIHRoZSBMRFAgLyBSU1ZQIHByb3Rv Y29sIGFuZCByZXF1aXJlcyBhIG5ldyBtZWNoYW5pc20gdG8gY2FsY3VsYXRlIHRoZSBQYXRoIE1U VS4NClN1cHBvcnQgQWRhcHRpb24uDQoNClRoYW5rcw0KDQpaaGlibyBIdQ0KDQq3orz+yMs6IElk ciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN1c2FuIEhhcmVzDQq3osvNyrG8 5DogMjAyMMTqM9TCMzDI1SAyMDozNg0KytW8/sjLOiAnSURSIExpc3QnIDxpZHJAaWV0Zi5vcmc+ DQrW98ziOiBbSWRyXSBXRyBBZG9wdGlvbiAtIGRyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1t dHUtMDMudHh0IC0gMiBXZWVrIFdHIGFkb3B0aW9uIGNhbGwgKDMvMzAgLSA0LzEzKQ0KDQpUaGlz IGJlZ2lucyBhIDIgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1saS1pZHItc3ItcG9s aWN5LXBhdGgtbXR1LTAzLnR4dA0KDQpZb3UgY2FuIHZpZXcgdGhpcyBkcmFmdCBhdDoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1t dHUvDQoNClRoaXMgZHJhZnQgZGlzdHJpYnV0ZXMgcGF0aCBtYXhpbXVtIHRyYW5zbWlzc2lvbiB1 bml0IGZvciB0aGUNClNSIHBvbGljeSB2aWEgQkdQLg0KDQpBbnkgZGlzY3Vzc2lvbiByZWdhcmRp bmcgb24gd2hldGhlciBvbmUgZGVzaXJlcw0KU1IgUG9saWN5IHNob3VsZCBiZSBjbGVhcmx5IGRp c3Rpbmd1aXNoZWQgZnJvbSB0aGUNClRlY2huaWNhbCBkaXNjdXNzaW9ucyBvbiB0aGUgbWVjaGFu aXNtcyB0byBwYXNzIFNSIHBvbGljeSBNVFUuDQoNClRoZSBxdWVzdGlvbnMgZm9yIHRoZSBwZW9w bGUgdG8gZGlzY3VzcyBvbiB0aGlzIGRyYWZ0IGFyZToNCg0KMSkgSXMgdGhlcmUgYSBuZWVkIGZv ciB0aGlzIG1lY2hhbmlzbSBpbiBuZXR3b3JrcyB1c2luZw0KICAgICAgICBNUExTLVNSIG9yIFNS LVY2IGFuZCBTUiBwb2xpY3k/DQoNCjIpIEFyZSB0aGVyZSBhbnkgZXJyb3IgaGFuZGxpbmcgaXNz dWVzIGJlc2lkZXMgd2hhdCBpcyBiZWluZw0KICAgICBUYWtlbiBjYXJlIG9mIGluIFJGQzc3NTJi aXMtMDMudHh0DQoNCjMpIERvIHlvdSB0aGluayB0aGlzIGRyYWZ0IGlzIHJlYWR5IHRvIGJlIGFk b3B0ZWQ/DQogICAgIEluIHRoaXMgY2F0ZWdvcnksIHBsZWFzZSBsaXN0IGFueSBjb25jZXJucyB5 b3UgaGF2ZQ0KICAgICByZWdhcmRpbmcgYWRvcHRpb24uICBUaGlzIGNhdGVnb3J5IGNhbiBpbmNs dWRlDQogICAgIGdlbmVyYWwgY29uY2VybnMgYWJvdXQgQkdQLUxTLCBNUExTLVNSLA0KICAgIFNS LVY2LCBhbmQgU1ItUG9saWN5Lg0KDQpDaGVlcnMsIFN1ZSBIYXJlcw0KDQoNCg0KDQoNCg== --_000_06CF729DA0D6854E8C1E5121AC3330DFAF5D9355dggemm529mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Traditional MPLS uses the LDP / RSVP protocol to obtain the Path = MTU. Segment Routing removes the LDP / RSVP protocol and requires a new mec= hanism to calculate the Path MTU.

Support Adaption.

 

Thanks

 

Zhibo Hu

 

=B7=A2=BC=FE=C8=CB:= Idr [mailto:idr-bounces@ietf.org] =B4=FA=B1=ED Susan Hares
=B7=A2=CB=CD=CA=B1=BC=E4:= 2020=C4=EA3=D4=C230=C8=D5 20:36
=CA=D5=BC=FE=C8=CB: 'IDR List' <idr@ietf.org>
=D6=F7=CC=E2: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG ad= option call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

    SR-V6, = and SR-Policy.   

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_06CF729DA0D6854E8C1E5121AC3330DFAF5D9355dggemm529mbschi_-- From nobody Fri Apr 3 01:15:05 2020 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 CC0C03A13F6 for ; Fri, 3 Apr 2020 01:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVMcOR8GMBNY for ; Fri, 3 Apr 2020 01:15:02 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D683A13F4 for ; Fri, 3 Apr 2020 01:15:01 -0700 (PDT) Received: from lhreml739-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 124A5628797EB5016FAA for ; Fri, 3 Apr 2020 09:15:00 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml739-chm.china.huawei.com (10.201.108.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 3 Apr 2020 09:14:59 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 3 Apr 2020 16:14:49 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Fri, 3 Apr 2020 16:14:49 +0800 From: "Xiejingrong (Jingrong)" To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAADAHCFg Date: Fri, 3 Apr 2020 08:14:49 +0000 Message-ID: <362b7b36971743a8a0f47fffa2963f87@huawei.com> References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.202.118] Content-Type: multipart/alternative; boundary="_000_362b7b36971743a8a0f47fffa2963f87huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 08:15:04 -0000 --_000_362b7b36971743a8a0f47fffa2963f87huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption. MTU is essential for a tunnel of any kind, either a default/blind one, or a= better/optimized one provided optionally. This document defines a direct and simple extension to provide an MTU for a= tunnel rather than the default one. Thanks Jingrong From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 8:36 PM To: 'IDR List' Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_362b7b36971743a8a0f47fffa2963f87huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the adoption.

MTU is essential for a tunnel of any kind, either a default/blind= one, or a better/optimized one provided optionally.

This document defines a direct and simple extension to provide an= MTU for a tunnel rather than the default one.

 

Thanks

Jingrong

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

    SR-V6, = and SR-Policy.   

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_362b7b36971743a8a0f47fffa2963f87huaweicom_-- From nobody Fri Apr 3 01:18:06 2020 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 B9E5B3A1406; Fri, 3 Apr 2020 01:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=Cc5Lba/Y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TfA0oSbZ 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 icsIfoHpzNZn; Fri, 3 Apr 2020 01:17:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6C13A0C5A; Fri, 3 Apr 2020 01:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13656; q=dns/txt; s=iport; t=1585901876; x=1587111476; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3XgS+EYGBDmjwbKI7D/Hj+nbj+iaWklhxTCysUYnrrQ=; b=Cc5Lba/Y+oqqc8JVZhnkb+xZaTR0TsEMAuzoboxk+I3AS5Cw2Q6lHQ2H dJzVDWyYDzXEKJD3SGxmffbOQ5yty0uGJwRWvos7W5ckp6zBp3UJKBMLl yNv1xAuFhT7rj7jaIEEf534ABqlSAntYD1AKK2IXFHkXA3yVHF43una1z U=; IronPort-PHdr: =?us-ascii?q?9a23=3AdF6b3RSSIsGQf444c7gTX8653dpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOi83AM1ESHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgAt8IZe/4ENJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYEkLyQsBWxYIAQLKgqHVgOKZ4Jfkz2EYYJSA1QKAQE?= =?us-ascii?q?BDAEBIwoCBAEBhEQCgkMkNwYOAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQM?= =?us-ascii?q?SCxATAQE3AQ8CAQgOAwQBASQLMh0IAQEEAQ0FCBqDBYF+TQMuAQ6jPgKBOYh?= =?us-ascii?q?igieCfwEBBYFDQYM3GIIMAwaBOAGFIQ2HAhqBQT+BEAFDgk0+gmcBAQIBAYF?= =?us-ascii?q?jJAeDF4IsjhWIa4oxj1kKgj2Ge3CPUYJMiDeQdoRWilaJIpJ5AgQCBAUCDgE?= =?us-ascii?q?BBYFoI4FXcBU7gmlQGA2OHTiDO4UUhUF0AoEnjSwBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,339,1580774400"; d="scan'208,217";a="741471952" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2020 08:17:55 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0338HtA1020123 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Apr 2020 08:17:55 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 03:17:54 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 04:17:53 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 3 Apr 2020 03:17:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=boWC9b5ANX4UBzpaj7gxPu9eBYYZdkqn0CSAnKBkD4Nn4cvalSbVnEOcXsXtIfAe6AztMiaF9bMXJWPS9UyOUpSJ61b7gR+ZtCzQvsplFvBEFPI6gGneuT6rsf1sncToiEdiXGOS4VGy1eV9xmUpcwkMhpwa5AomfpGKFe0Xn1qtB7ZKXk7FbHuMQpiw1RXhdcMHRTKRuWTHOlv5nOVrFDfsDRip+xTjxX0H/0gM0JjN9IVcZ5cUTjqwWTKlqksNw05PfOl0XI9Zgo/oA7MM+KTqYla7+VSJ5IrGjZRjdc07Qk3qIGulVpXGsCgDYQ5hvScDpjQ7UUTgxvXYACfWTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nnkXanKtDl8uI87MFNHJDTM1f62jKGAh2o5axEoP6xc=; b=X481D2OW56NlSG5qA7mFAIgsA1L9m/v7Pt3362UTvl2SWif565Hc2zuKLwYPUOMwhVztf4+7UGDSthyEf/qzewI+gXBlzHnTYA92hORXtAD0FUkOAuoJGQScOAru+kX1G3aq5+h5cBURLKvDHOwspbUXR0ecxgbpnwHD234Iw0vfWBbSm0JxTETfRT1jg28H7GN+9hP/xiBxHJZCS4GcfRBQThGqZjGVZxBcA/nfZxe/9um3LDjZvQ1wN5S2nrRWlj2Z84MCJn6M9ZlP6kj6noXauqRYsLCR06Yh05OfbKtDxaaSAJI9Ar/dtuiN96huOmR7voVTgwugIw+7/zCxxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nnkXanKtDl8uI87MFNHJDTM1f62jKGAh2o5axEoP6xc=; b=TfA0oSbZhQiUO2g+l/Ib5Y3ogHax+ZhmwhBisZK/HVO4J8s6ZDyjyiTgR/QS8tv1I0dYPwrj7+vd1widj6ydGElco8Xxxmz2nEXihKaE01aZWPBJajj4brFaDtnzXsRF62bGbJUuNMwDJaAz2h9b0HcDVS65+IOdU/uxEdHdOiQ= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4745.namprd11.prod.outlook.com (2603:10b6:303:5e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Fri, 3 Apr 2020 08:17:52 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::dc3d:f0de:21ec:cf87]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::dc3d:f0de:21ec:cf87%7]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 08:17:52 +0000 From: "Ketan Talaulikar (ketant)" To: Susan Hares , "'IDR List'" CC: SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEw Date: Fri, 3 Apr 2020 08:17:52 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [72.163.220.7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e63c51fa-51ab-4677-6d66-08d7d7a7818c x-ms-traffictypediagnostic: MW3PR11MB4745: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(39860400002)(376002)(346002)(81156014)(9326002)(86362001)(966005)(55016002)(33656002)(478600001)(8676002)(9686003)(7696005)(81166006)(66946007)(66446008)(4326008)(53546011)(66556008)(64756008)(52536014)(66476007)(71200400001)(110136005)(26005)(6506007)(8936002)(186003)(76116006)(2906002)(5660300002)(316002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WYHUoCUwRyxrKgfgahRtTu4HJhVxpTzMf7jA4hVZFliQ+6dXkKMrZ+TKqetvIaJreFtvuzgtLYS8oVd6LZCzFkSduBHcNpKMN8h+LGJZo9DxQd4/3ptbQ7bku57GjAAuCsN2yYm+NCnDuTqc4CR1cU9GNKqZ9p3zu+UsKfiUvtWjm7EW+pgcYzZtIWL8R+V6fEAzufOtz7zF4WOvwtQtbgtlTp/4xn/K/kLHQbLwYsfd2uScAM9cikbyShF7egaUX8Dh9qcuOsiaHmd1QlV68EVxjofECL3MvmxifjkRMXynpIrF7Ux5wzqN9vdxGa6n/glZlRrQek7JAa4QBP3yZDA8VNxfy8nzPAn17jG9otFDNFlRWSgIRw8MZG0eWa/I0glcnVHIqgnyU9gquQUKDkITgqFmeWkQDYE969q1vvcsw4JzHZvbh6k8LG9XHDAOkX3ocJUmeurEvSXRQdXRO8WIUPLTIww6xu6VSg61DqFEW3pCENO64/6vWopCyxPRu80rS7GQF7QlViSN2PK6kA== x-ms-exchange-antispam-messagedata: rJAC8ebhSbXVr1xUZ5Y/Kyf+jISSQ+x+BFeFjqym2EkVshqMFINrTWVPQ7Cuy01m/DIgWgX4l9/0oXr4viQGmJLdWHsxpMyLx/qYfC0fbup26Vlj/GBYN5UvMwxfKRUBH9a06SMQdDmeU9McST6Z8g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45709BBDB2AD9FF81494A0CCC1C70MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e63c51fa-51ab-4677-6d66-08d7d7a7818c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 08:17:52.3911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PpYWzEifHwWLiVwMj3bi+ii27QbAYNO6LDHBNwEAINg03dxAkslv5aHReBd0W55jH9wVODeQ616bAReuIEACmA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4745 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 08:17:59 -0000 --_000_MW3PR11MB45709BBDB2AD9FF81494A0CCC1C70MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a few questions for the authors of this draft and some discussion po= ints for the WG. 1. What is precisely the definition of this "path MTU" for an SR Policy?= I am guessing that it includes all the labels/SIDs that are used for the S= R path? 2. While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path M= TU" for RSVP-TE LSPs, it does describe the procedures for the same for hand= ling IP packets/payloads on the headend. It does not cover the scenarios wh= ere the incoming packets may be themselves labelled. 3. Shouldn't the concept of "path MTU" for SR Policies and its' applicab= ility and operations be first defined in a (Spring WG?) document before we = introduce its signalling aspects in protocols like BGP? Note that such a do= cument would bring in requirements and guidelines for how the value is goin= g to be computed and it's usage for different steering mechanisms over SR P= olicies. 4. Finally, specific to the proposed encoding here, would this "path MTU= " not be more suitable on the CP level since each SL may have different siz= e label stack and different paths and one does not know which SL would be p= icked for a particular flow? So may be the lowest value computed for all SL= s is what gets applied to the packets at the CP (i.e. SR Policy) level? Thanks, Ketan From: Idr On Behalf Of Susan Hares Sent: 30 March 2020 18:06 To: 'IDR List' Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_MW3PR11MB45709BBDB2AD9FF81494A0CCC1C70MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

&nbs= p;

I have a = few questions for the authors of this draft and some discussion points for = the WG.

&nbs= p;

  1. What is precisely the defi= nition of this “path MTU” for an SR Policy? I am guessing that = it includes all the labels/SIDs that are used for the SR path?
  2. While https://= tools.ietf.org/html/rfc3209#section-2.6 defines “path MTU” = for RSVP-TE LSPs, it does describe the procedures for the same for handling= IP packets/payloads on the headend. It does not cover the scenarios where the incoming packets may be themselves labelled.=
  3. Sho= uldn’t the concept of “path MTU” for SR Policies and its&= #8217; applicability and operations be first defined in a (Spring WG?) docu= ment before we introduce its signalling aspects in protocols like BGP? Note that such a document would bring in requirements = and guidelines for how the value is going to be computed and it’s usa= ge for different steering mechanisms over SR Policies.
  4. Finally, specific to the= proposed encoding here, would this “path MTU” not be more suit= able on the CP level since each SL may have different size label stack and = different paths and one does not know which SL would be picked for a particular flow? So may b= e the lowest value computed for all SLs is what gets applied to the packets= at the CP (i.e. SR Policy) level?

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

    SR-V6, = and SR-Policy.   

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_MW3PR11MB45709BBDB2AD9FF81494A0CCC1C70MW3PR11MB4570namp_-- From nobody Fri Apr 3 02:18:56 2020 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 8B4FF3A1571 for ; Fri, 3 Apr 2020 02:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2s5_06HrDyH for ; Fri, 3 Apr 2020 02:18:50 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id D8B663A156F for ; Fri, 3 Apr 2020 02:18:49 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:62011.1939381549 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-113.66.219.135?logid-9EF0481657244255AE279BAD8707779C (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id B66842800B8; Fri, 3 Apr 2020 17:18:38 +0800 (CST) X-189-SAVE-TO-SEND: 44031110@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id 9EF0481657244255AE279BAD8707779C for idr@ietf.org; Fri Apr 3 17:18:41 2020 X-Transaction-ID: 9EF0481657244255AE279BAD8707779C X-filter-score: filter<0> X-Real-From: zhuyq8@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 From: To: "'Susan Hares'" , "'IDR List'" References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Date: Fri, 3 Apr 2020 17:18:36 +0800 Message-ID: <074601d60998$dd333d10$9799b730$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0747_01D609DB.EB578E80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHKANuaROx/Y2dwP02j+uh9JPrdx6h/LzLA Content-Language: zh-cn Archived-At: Subject: [Idr] =?gb2312?b?u9i4tDogIFdHIEFkb3B0aW9uIC0gZHJhZnQtbGktaWRy?= =?gb2312?b?LXNyLXBvbGljeS1wYXRoLW10dS0wMy50eHQgLSAyIFdlZWsgV0cgYWRvcHRp?= =?gb2312?b?b24gY2FsbCAoMy8zMCAtIDQvMTMp?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 09:18:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0747_01D609DB.EB578E80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I support the adoption. Thanks. B.R. Zhu Yongqing =20 =B7=A2=BC=FE=C8=CB: Idr =B4=FA=B1=ED Susan Hares =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA3=D4=C230=C8=D5 20:36 =CA=D5=BC=FE=C8=CB: 'IDR List' =D6=F7=CC=E2: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13) =20 This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03.txt=20 =20 You can view this draft at:=20 https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ =20 This draft distributes path maximum transmission unit for the=20 SR policy via BGP. =20 =20 Any discussion regarding on whether one desires=20 SR Policy should be clearly distinguished from the=20 Technical discussions on the mechanisms to pass SR policy MTU.=20 =20 The questions for the people to discuss on this draft are:=20 =20 1) Is there a need for this mechanism in networks using=20 MPLS-SR or SR-V6 and SR policy?=20 =20 2) Are there any error handling issues besides what is being=20 Taken care of in RFC7752bis-03.txt =20 3) Do you think this draft is ready to be adopted?=20 In this category, please list any concerns you have regarding adoption. This category can include=20 general concerns about BGP-LS, MPLS-SR,=20 SR-V6, and SR-Policy. =20 =20 Cheers, Sue Hares =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0747_01D609DB.EB578E80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I  = support the adoption. Thanks.

B.R.

Zhu = Yongqing

 

=B7=A2=BC=FE=C8=CB: Idr <idr-bounces@ietf.org> = =B4=FA=B1=ED = Susan = Hares
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA3=D4=C230=C8=D5 20:36
=CA=D5=BC=FE=C8=CB: 'IDR List' = <idr@ietf.org>
=D6=F7=CC=E2: [Idr] WG Adoption - = draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - = 4/13)

 

This begins a 2 week WG adoption call for = draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at: =

https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path maximum transmission unit for = the

SR = policy via BGP. 

 

Any discussion regarding on whether one desires =

SR Policy = should be clearly distinguished from the

Technical discussions on the = mechanisms to pass SR policy MTU.

 

The questions for the people to = discuss on this draft are:

 

1) Is there a need for this = mechanism in networks using

        MPLS-SR or = SR-V6 and SR policy?

 

2) Are there any error handling issues besides what is = being

     Taken care of in = RFC7752bis-03.txt

 

3) Do you think this draft is ready to be adopted? =

     In this category, please list = any concerns you have

     regarding adoption.  This = category can include

     general concerns about = BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  =  

 

Cheers, Sue Hares  

 

 

 

 

 

------=_NextPart_000_0747_01D609DB.EB578E80-- From nobody Fri Apr 3 10:28:05 2020 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 E45753A08A2 for ; Fri, 3 Apr 2020 10:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 TnsnLr9Q3DSz for ; Fri, 3 Apr 2020 10:27:58 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe59::720]) (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 CA0AC3A089C for ; Fri, 3 Apr 2020 10:27:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PgNWb4IaaNNdD/iXSursxxA6F8h0pY+B8yxUKlbBOyXV7V837OX5MDTqoRq5dV4lwzd1IFP9myHO/lZBAQB9ORYnyqhAfPNwxsnpSyfl5pKzbPqrVhevWZEpYjlo6Ar6ExLF3n0JWCQ9p6bzX8CADtBJVYLdRZAh68KdbwpjJd+0NhOhNxtxcgiu5ipjAQu0OL4uTJCH5sLg+K4ZVz+iXEP8EOJA3pDFEizF+kYzFPFLvTM7nyQXXlifZ93Y2akrINegBdC/G21QTJxIiKxzEJMimyR19JncNhpHYs5gnmlhsx2BhymdQe9NX2usWcOa9SE64Q7JR/a7m6mn4BXVsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m0e/PxiKeCwz0jxS5tLiygqt8NqLSA5j/eWvy9l4+EE=; b=M5/nPNgTu8W7CivLo+yig1jH0So2OkfbkFqvwnLzQKwxT6KcYFnwxVTKF07b2T7q9dZamDqlEUcvUh+cKIuge1Dw7VzmJ4eJLhhzscEWlMTZEOTKWeEhT9ZeSX677wSsuoRWdxkLJ9zNg9fpADf2ugjoIoggYN8QqPp2LtHSSewPpZQnXQt8Aq8rGZxixFsFbxz72ry24V4NijMPsVPjirxZZKLCHr7MiCgla1LQ/dCN67xTaIDN1XwPZiO8uhxrF6gZUXxV5lHVTrw8EXdV4IgBRfdAICWlhU9ulyy0egXL1HLYIlU0c8vRXP0tJXbE69e38eTM3EJfKsPhlaq4Aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m0e/PxiKeCwz0jxS5tLiygqt8NqLSA5j/eWvy9l4+EE=; b=hdmhQfGIabsLLR4wutn5V9uJtORYldvyQ2OrYrzV4do7nFAxhtrqf77TKD2qfEZwtWcSJHRr6cPra8CCPeKdjhGAxzQaEaIvilFu17lY3LN2x3+NYcZHIOEtPqS68XyjG90WkgjHtmn5sFi/2+83Dsb9dREk6pPtgVylQQIz4Ec= Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB1966.namprd13.prod.outlook.com (2603:10b6:301:30::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Fri, 3 Apr 2020 17:27:53 +0000 Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945%3]) with mapi id 15.20.2878.014; Fri, 3 Apr 2020 17:27:53 +0000 From: Linda Dunbar To: "idr@ietf.org" , "'shares@ndzh.com'" Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC+IftQAAJY6PAAEXO1QA== Date: Fri, 3 Apr 2020 17:27:53 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: 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=linda.dunbar@futurewei.com; x-originating-ip: [2605:6000:1526:d41e:f8f2:b132:58a2:62db] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 255084b2-6102-4cf8-2e48-08d7d7f45762 x-ms-traffictypediagnostic: MWHPR1301MB1966: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1301MB2096.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(39850400004)(366004)(396003)(136003)(346002)(376002)(86362001)(478600001)(76116006)(66556008)(316002)(53546011)(8936002)(64756008)(66446008)(66476007)(44832011)(7696005)(81166006)(8676002)(966005)(71200400001)(6506007)(110136005)(66946007)(2906002)(186003)(5660300002)(81156014)(9686003)(55016002)(33656002)(52536014)(491001); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yOJwTwhP03ggTFOfhEhRVzI6ra9hu49h1QOykyhaaC5/+fOiCpmeM1vO+CmUtZloeDcpw/hBDScrDXzXubNRldcb7+Qhbl7CaUxyBdPJd9h0VajKVjVTlSouSrApgxnlpLM8ASMho77E+HNoKymh82iDm6cVaYPqKtg3DF5PXJvZsb+KJYhPuL7qZkNJ6dMCxfO804kreFOLabUEFbe5K+5KmQUlPlu+oIXX6M9TE2SPHcy7LC7/4OckACtH7qTEPP+6AXNz/ILPxow380oI90EPi/fFwosak1lM9hhUsSqIsF14QSuELOeG9apPVsdXgr+ySfXoP4/Vu7KjtCEWLnHgzcnwSTNWS/dW4aTyq8xufgTO8XhbNxpHqrf3nDYdJPGhklmlEziM5NOpJoJJ/y1TjBnmlsz6syZRQMsUnapQEEUDswOEWhzOIjDmZsmnm9Y2bfUB+c8laPylLM/fIs5E9uN1lw9MIKEVIJEA9h0Xtfd70VaiYWDx0t36EDyUAWLVBT4eAtoL7LWOxYu/1+Yr40xRWPvQV7zfEQDoL6/ykMa3hWe5hwuRQF6/e7eK x-ms-exchange-antispam-messagedata: fJeaHTiVDoWeGVSG6fdqR8AryP8E/qOyjKSA54JIETU8+x0iwA8ydLeHXckrhE8UPCrc0uVPUB4pukxb/btrbl6oko0RBaRGedq+eIBZia1Ux8pW+lfPsFQQbEiIxkXCLJcb4Vgo0MLJbD1AqqiggTV0IkbsORQMaycDpPwn5lXjwiZO0JCQj6xqtFiJLuZuBU67bZNKaqhWvNA0CgVInA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR1301MB20962DBFAE3C5BBFB7BFAEB985C70MWHPR1301MB2096_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 255084b2-6102-4cf8-2e48-08d7d7f45762 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 17:27:53.3938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jG3F+V6SHj46G/55L9ukZGsBsEtOxyIK7U+QvqFS1dCmsig8ixZElHnOe6X2gyVdZohHlOdtEKL2mNohh2loqA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB1966 Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 17:28:03 -0000 --_000_MWHPR1301MB20962DBFAE3C5BBFB7BFAEB985C70MWHPR1301MB2096_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read the draft-li-idr-sr-policy-path-mtu-03 and I think it is very i= mportant subject to be specified. Therefore I support the WG Adoption of th= e draft, with the following comment: The draft should add a paragraph to describe why can't each node simply dro= p the packet if the packet size is larger than it can support? Since virtually all hosts send out MTU discovery (RFC8201) packets, if the = network drops the packet due to the size exceeding the MTU, the source host= s will adjust the packet size. For communication between hosts, there are m= any layers of encapsulation added. Not just SR domain. The hosts have to ad= just its packet size to reach their communication peers. My two cents, Linda Dunbar From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 8:36 PM To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_MWHPR1301MB20962DBFAE3C5BBFB7BFAEB985C70MWHPR1301MB2096_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have read the draft-= li-idr-sr-policy-path-mtu-03 and I think it is very important subject to be= specified. Therefore I support the WG Adoption of the draft, with the foll= owing comment:

 

The draft should add a= paragraph to describe why can’t each node simply drop the packet if = the packet size is larger than it can support?

Since virtually all ho= sts send out MTU discovery (RFC8201) packets, if the network drops the pack= et due to the size exceeding the MTU, the source hosts will adjust the pack= et size. For communication between hosts, there are many layers of encapsulation added. Not just SR domain. The host= s have to adjust its packet size to reach their communication peers.

 

My two cents,

 

Linda Dunbar

 

 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoption call for draft-li-i= dr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-= path-mtu/

 

This draft distributes path maximum transmission uni= t for the

SR policy via BGP. 

 

Any discussion regarding on whether one desires

SR Policy should be clearly distinguished from the <= o:p>

Technical discussions on the mechanisms to pass SR p= olicy MTU.

 

The questions for the people to discuss on this draf= t are:

 

1) Is there a need for this mechanism in networks us= ing

        MPLS= -SR or SR-V6 and SR policy?

 

2) Are there any error handling issues besides what = is being

     Taken care of in RFC77= 52bis-03.txt

 

3) Do you think this draft is ready to be adopted? <= o:p>

     In this category, plea= se list any concerns you have

     regarding adoption.  T= his category can include

     general concerns about= BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  =  

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_MWHPR1301MB20962DBFAE3C5BBFB7BFAEB985C70MWHPR1301MB2096_-- From nobody Fri Apr 3 13:24:29 2020 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 3B4083A0A07 for ; Fri, 3 Apr 2020 13:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 NrRKT-ZMbF3p for ; Fri, 3 Apr 2020 13:24:25 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2109.outbound.protection.outlook.com [40.107.94.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08203A0AA9 for ; Fri, 3 Apr 2020 13:24:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OiSo1WEcrVPTergGRGhrUPgLs0b8QRkb+Kx2v4SX/LCereGp2wOHsoWDGHXBbmDD1/jQCI6Nh5bMqh3JcKeLiHpL955GORvFCXI4EgyRHi6vkP33RapRYTzOPC0eLifYhEMu9CXADXOjB6T+RKhFmqnpfVWIgM2LyBKFlu+UMhv4O4q+WnTuw8nTw0r3pS7otPCtC/qW4iuzGJgGQhdtu9yr1Fx+pu8qxtYyJmnHD8B6RdhwEwJks7GZQDa/buZHsC2WfTi+knimPHFyyq33E0U1bDJRT55nmsVzBBVuC10TFWHQjDtgeod0T+EFPLJZG+ssfFTEBVOpWiDtuFUCTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R9gsh3XrCYClUMw5vr5ZcBUDBYbsA0mhmHRN/iZcJpw=; b=TlPZd/gZi0YYNOidFpyFzF1QvRj0rhL4HFfWSuz5u9bY7EHOzV8zB07x2/4xfgZIej8Ik1fcPXruy+AnMRk9rDqKa8SBzjksJsWwW6sizuyrnB57vArMCCHzM9JnjFmq4aInaclzRtWT4hMSNfjR1SQR+D5gSO7ufFE0Fo9Q7NzFhpXyhW5HYzeC/fGhBdt9e8keK6bYkKkY/F7i7yCD4MRforUyY2tgk6GQOo8y1pMw986g0TPcLbdWEhKYwLIQBjrZ6aeVucIvhon6BwuB05+wCZnbEXa1mO/GKcjl8kB4LAKnuG1TpETDC34MuLYXc+wsjsLnhmELAixXnmYMEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R9gsh3XrCYClUMw5vr5ZcBUDBYbsA0mhmHRN/iZcJpw=; b=s3BgyOgYyQB7zQ/7I1idGlvZjkOGpcFgirGNjA3uqXgnI4cs9kDdcR/EaIlePraytYaYGMzzQ5zZOrMKslGK/RcvJIhdZmloz+qTKlMNJpzolafInCa1a83pFHa+OaIePorcBb9jRTY0/T5q/ol4s7yNrqsRnOwpvS/ACC7Isrk= Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB2110.namprd13.prod.outlook.com (2603:10b6:301:30::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Fri, 3 Apr 2020 20:24:09 +0000 Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945%3]) with mapi id 15.20.2878.014; Fri, 3 Apr 2020 20:24:09 +0000 From: Linda Dunbar To: Susan Hares , 'IDR List' Thread-Topic: Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Thread-Index: AdYJ88Fzwt+5o6y3SbatjJfErRQpEw== Date: Fri, 3 Apr 2020 20:24:09 +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=linda.dunbar@futurewei.com; x-originating-ip: [2605:6000:1526:d41e:f8f2:b132:58a2:62db] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c9505fc9-53f2-429f-3bce-08d7d80cf725 x-ms-traffictypediagnostic: MWHPR1301MB2110: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1301MB2096.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(39850400004)(376002)(346002)(366004)(136003)(396003)(8936002)(2906002)(66556008)(81166006)(52536014)(966005)(66946007)(186003)(86362001)(53546011)(81156014)(110136005)(5660300002)(316002)(7696005)(66446008)(76116006)(6506007)(71200400001)(8676002)(64756008)(44832011)(55016002)(478600001)(66476007)(33656002)(9686003); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: udjj4pF9Jzxp82sWgYbTo7Mv2wyr5klv1Vn83AN8GfAaYIOCYkaRIY06gBjormnu/YWgeBkXZTZ4M4jfcDD4fTAJnV0VrIkik7sVjsDv75KQ60TM4+WwqGpA2o95jsMRuVUvozrgqrmslO2r0dRlVwtrKoAsAxrG6RsD4bDDXKwg3DGGrGHq5XaZrYuiVnxYJ44Y06KIn3Hnzc15zw4WM38wqeLlT7nCUaXpE2qCzy6l2DvTJSre47yncKMbArKRJEiDBYhFhsHnbdKdbI3wpP7lkkXfA/tkSp+fF2N8EN1Ohjm7fC+hT0SBeV7M5jZLb/aDOMiAZQZUXwQ/7G6rLhIMIf31/+pCehFF2beU+MrJix+njVem2ZgxFFbowW/G1142QeE9l7SuM8S2E5cnL05BjOgNxQLnVikAK1BZngg/wO2apEHBJYFgESgkxf0Kixd0LcAfIiJ3vLfsCtGDIN3T3QqhmezEOzp/oon87TdhhXAEWQ1f3G+4rcTuuKeyCoR+G4o4rzol7Oul2QZ4aQ== x-ms-exchange-antispam-messagedata: r3X+ayvcRstTguD45AVi6ohKCcJUquseiucecDx+Mwbl5U2rfy/sf98B/XbZ/lU3Er0IHhYdW2MeK9V7btpQnq4SQPFC91p37ANUGJF47e43yXtwAADpQ2/2vY3UgtcnPZIr7jGbcqeUBsHHUjZd+iz7X+XuoLcnqYIlFN/A0bKINNKBawEO1WitwL4rIPJrEDPJ7NXG8etMwR9elZKdoQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9505fc9-53f2-429f-3bce-08d7d80cf725 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 20:24:09.2175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 20ajajUyoACc0imQzb80/CqgHzDHvdkgcpTm/5tFK3VhYdMHEi1Tz7SRfDsqDOl8uxcAZ2eT3YVL8kxICE9Gwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB2110 Archived-At: Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 20:24:27 -0000 --_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jun, Need a few clarify questions for your draft. 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running be= tween IPsec peers? 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKE= v2 with the speaker without any configuration from the administer? If Node = B can only establish IPsec IKEv2 with another node C, does it matter if the= Node B receives or not receives the BGP update from the C? 2. How does the BGP UPDATE ease the IPsec configuration? Does it ease t= he configuration on the BGP UPDATE speaker? Or does it ease the configurati= on of the receiver? 3. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is = there still "Private Routing Instances"? 1. On Page 3, the draft states that only "Local Tunnel Endpoint address,= Public Routing Instance and CHILD SA traffic selector address range" are a= dvertised by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the no= de? Or can be a specific Ingress or egress port of the node sending out the= BGP UPDATE? Thank you very much. Linda Dunbar From: Idr On Behalf Of Susan Hares Sent: Monday, March 30, 2020 7:07 AM To: 'IDR List' Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and= draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 This begins a 2 week WG adoption call for two drafts BGP provisioned IPSEC= infrastructure 1) draft-hujun-idr-bgp-ipsec-02.txt: BGP Provisioned IPSEC Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/ 2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt: BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec-transport-mode/<= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=3D02= %7C01%7Clinda.dunbar%40futurewei.com%7Cdb1e68b21c294ff7e40f08d7d4a2e5e4%7C0= fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637211668440604245&sdata=3DXROXZN= 5YTy5GQEToYyAkFNHx71%2B%2FXnln1QJjMzeRQ6I%3D&reserved=3D0> These drafts were presented at IETF 104 and IETF 105. At IETF 105, there was a detailed discussion on the security issues. After IETF 105, the author modified his draft to take care of the Issues mentioned. Discussion during the WG Adoption should examine: 1) Has this draft addressed the necessary security issues to be adopted as IDR WG draft? 2) Is this useful generic IPSEC functionality for networks? The EVPN related to IPSEC continues in BESS. This draft is considered here as a general feature. 3) Are there any deployments of this draft? Stay safe and healthy... Sue --_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jun,

 

Need a few clarify questions for your draft.

 

  1. Does  draft= -hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers= ?

 

  1. Does receiving the IPsec BGP UPDATE triggers a node to start the &nbs= p;IKEv2 with the speaker without any configuration from the administer? If = Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the = BGP update from the C?
  2. How does the BGP UPDATE ease the IPsec configuration?= Does  it ease the configuration on the BGP UPDATE speaker? Or does it= ease the configuration of the receiver?
  3. How to differentiate  Public Routing Instances? =  

If the payload packet wi= thin the IPsec tunnel are simple IP forwarding, is there still “Priva= te Routing Instances”?

 

  1. On Page 3, the draft states that only “Local Tunnel Endpoint ad= dress, Public Routing Instance and CHILD SA traffic selector address range&= #8221; are advertised by the BGP.

Is the Local Tunnel Endp= oint address same as the LOOPBACK address of the node? Or can be a specific= Ingress or egress port of the node sending out the BGP UPDATE?

 

 

Thank you very much.

 

Linda Dunbar

 

From: Idr <idr-bounces@ietf.org> On = Behalf Of Susan Hares
Sent: Monday, March 30, 2020 7:07 AM
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.= txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020=

 

This begins a 2 week WG adoption call for  two = drafts BGP provisioned IPSEC infrastructure

 

1) draft-hujun-idr-bgp-ipsec-02.txt:

BGP Provisioned IPSEC Tunnel Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/<= o:p>

 

2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt:<= o:p>

BGP Provisioned IPsec Transport Mode Protected Tunne= l Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-= idr-bgp-ipsec-transport-mode/

 

These drafts were presented at IETF 104 and IETF 105= .

At IETF 105, there was a detailed discussion on the = security issues.

After IETF 105, the author modified his draft to tak= e care of the

Issues mentioned. 

 

Discussion during the WG Adoption should examine:

1) Has this draft addressed the necessary security i= ssues to

    be adopted as IDR WG draft?<= o:p>

 

2) Is this useful generic IPSEC functionality for ne= tworks?

 

   The EVPN related to IPSEC continue= s in BESS.

   This draft is considered here as a= general feature.

 

3) Are there any deployments of this draft?

 

 

Stay safe and healthy… Sue

 

--_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_-- From nobody Fri Apr 3 16:34:19 2020 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 C77C63A0FD1 for ; Fri, 3 Apr 2020 16:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 GjwOu8PHV8lc for ; Fri, 3 Apr 2020 16:34:08 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2109.outbound.protection.outlook.com [40.107.236.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423503A0FCE for ; Fri, 3 Apr 2020 16:34:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ng3iykp5OdRKo+eez4w6LccmMgTjTj/c1qL1mqIDCK9g4QtFlSdgupBmC0YsBHUqvYVuIzgmdeiwQJYZWHMG6PnMTI6abeKo6pMXA4mNqjpchev3noC1E+86905SgnI+GCJIo+ChCFqdEKkZJ8ZUAZv6GQacPzn7GSUPHxYE1akbvh5Sm9N/ZFCLMPvJLSyOT4vnWRYTeHhqsljcD5a3Lxu/Wp8EF7DLH4iwdVWOGQyRaRSoYtAaDf7sLUg08uhC0P1wOpuXOzrJgJ/CsVGuQBl/6BWrv4MY0gK7VJTZkvRjddAhBYHFpUdhw7GtLjbrkJjPWsX/L3jNeIYzkTDNRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DZLZRLBFU+zcFlgYfYgKg6J4UHXKCb3DN4EK/VWL7Uo=; b=ifiGRkq1oNLg9k0wB/NZH9y2NNkq6GXrjGeU+ZMsNkJewZDhpSO+3gkxRhBCz6bY6K974Mw57FqWVDrc4dBAAolTiilHE1nSMgD490qTex9gvzehfril1kjd90t5SeQpX7N5b/fxh5biKa5MaSINid078HgR+IFW/iVo28AnXxfHM+Xnz4/Jy0zK0JaV73ZHd0yFjafeWflhta8qXiLNqdSITsQiQzVjn8KIswkr3KMZdtW26XM8goVzbZiBkmqQz/HET2FLv1PqNez8YyzCthS1AXImk9/Z8nwnz82ig9OQWp8bmZVmZnEYnPwexcpOZSpjpk8aUWcXfqoIkmA3EA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DZLZRLBFU+zcFlgYfYgKg6J4UHXKCb3DN4EK/VWL7Uo=; b=FhA68VjtPYEpRPNFXsKNM9/y+3OuVvi2vSDzmuojcCzq+a+h3huuhjFnRYt/gm5HQWPtT+t/7r/lB9r2YFs/wAJ3DcmRellhq3uHPVra99lKpUY0U5rWoaHeXVfD44Y2ymeTItpa6X/Eh6adMu8qXf/Wny4jxydEQp7mJhvozRs= Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB2127.namprd13.prod.outlook.com (2603:10b6:301:31::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.14; Fri, 3 Apr 2020 23:34:00 +0000 Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945%3]) with mapi id 15.20.2878.014; Fri, 3 Apr 2020 23:34:00 +0000 From: Linda Dunbar To: Lou Berger , 'IDR List' Thread-Topic: questions about RFC5566 BGP IPsec Tunnel Encapsulation Attribute Thread-Index: AdYKDrwYA6vOulqiTbiMLggEnmqCDw== Date: Fri, 3 Apr 2020 23:34:00 +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=linda.dunbar@futurewei.com; x-originating-ip: [2605:6000:1526:d41e:f8f2:b132:58a2:62db] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b0d4b4fe-bc60-4a79-8c10-08d7d8277ca9 x-ms-traffictypediagnostic: MWHPR1301MB2127: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1301MB2096.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(346002)(366004)(136003)(376002)(396003)(39850400004)(478600001)(44832011)(86362001)(66556008)(52536014)(8936002)(33656002)(81156014)(7696005)(5660300002)(186003)(110136005)(2906002)(8676002)(81166006)(316002)(55016002)(76116006)(66446008)(66476007)(64756008)(9686003)(66946007)(4744005)(71200400001)(6506007); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TGKTE46F9c7pYNDB1YS0QftnTmv1DndIzpOKcrWKtIUPIl03432casky6Ng5W6M2bu8ol6DiyDQaeorHio011DA5aE4UyyediCN+cOD/ML9MZDbhfZf8VYhnlbzimRBMbrnulN/YZ7Rp2A2R/6zALl9Vtm6Esc1QzJ3NZrbGS7oMbYioB/o/V4XdDgliDT5sIas0N+K6Xa3zVCmLZKIIVjoztt6vfm3UX0D1kmi07ZuZZ3G9rIcbc17ICSspNkcYpu1rH+CKzJMRteoTIDdPqhLpGwr6qVmOrtmC7/ZIXnpW7bzdxTYq2iMYqgFX2xD/DO8HLO7mS5NRioAraA1LnEGFygHO8ZyFGBDDc3zJO8uS8Fdqy37BEwAUB08nhUP3r8VYHx9YunqESXSyZAm/zFSS6LajT2abxGF2iVjVlURajS4x/ewKenuUyfeVs2EB x-ms-exchange-antispam-messagedata: sFXI3nTXqlMtdL2iOXvns+twYeKPfdeH8HmJeqKJtqYQTXNQnEV1chYQ6/l0Y+zkVjqNSH5JjyPoXJ47lEef7O9TlT4a0rQ1amDxCCC+MK/rsZ5CUapcKXZeKVdRNMk5MlVRoTPCdVY5h5I0L9jSRFL7aFoHiG7ZoQVCKhoTHaCax2JjZVuNu2/So506G5CYQUO1lDJIL4gBX+PUC/EdwA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR1301MB20962C76678D4278BAE9A25085C70MWHPR1301MB2096_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0d4b4fe-bc60-4a79-8c10-08d7d8277ca9 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 23:34:00.1505 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6SNcBnBmeIfk4Vd/aMIiAH+zgq3AXDkxeN6Pl5iE6JxeyzUGfkeu5ppt4sAfMsxzza84Anxon10tC/K6Vu5LGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB2127 Archived-At: Subject: [Idr] questions about RFC5566 BGP IPsec Tunnel Encapsulation Attribute X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 23:34:16 -0000 --_000_MWHPR1301MB20962C76678D4278BAE9A25085C70MWHPR1301MB2096_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lou, Since you are the first author to RFC 5566 BGP IPsec Tunnel Encapsulation = Attribute, hope you (or anyone who knows the answer) can answer some questi= ons I have about the draft. Section 3 states that if R1 receives an Encapsulation SAFI update from R2, = R1 must initiate IPsec SA to R2 for all traffic with R2 as the nexthop. My question is that the UPDATE from R2 may be propagated to many nodes, do = all those receivers have to initiate the IPSec SA with R2? I would image all those nodes that need to establish IPsec SA with R2 shoul= d be configured by their administer, isn't it? How can a node trust another= node to initiate an IPsec SA? Thank you very much. Linda Dunbar --_000_MWHPR1301MB20962C76678D4278BAE9A25085C70MWHPR1301MB2096_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lou,

 

Since you are the first author to RFC 5566  BGP= IPsec Tunnel Encapsulation Attribute, hope you (or anyone who knows the an= swer) can answer some questions I have about the draft.

 

Section 3 states that if R1 receives an Encapsulatio= n SAFI update from R2, R1 must initiate IPsec SA to R2 for all traffic with= R2 as the nexthop.

 

My question is that the UPDATE from R2 may be propag= ated to many nodes, do all those receivers have to initiate the IPSec SA wi= th R2?

I would image all those nodes that need to establish= IPsec SA with R2 should be configured by their administer, isn’t it?= How can a node trust another node to initiate an IPsec SA?

 

Thank you very much.

Linda Dunbar   

--_000_MWHPR1301MB20962C76678D4278BAE9A25085C70MWHPR1301MB2096_-- From yangb9@chinatelecom.cn Sun Apr 5 02:54:37 2020 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 333403A08FE for ; Sun, 5 Apr 2020 02:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbruCIPzwHxd for ; Sun, 5 Apr 2020 02:54:33 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4673D3A0903 for ; Sun, 5 Apr 2020 02:54:33 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:63617.1944314717 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-116.22.35.150?logid-D9C601AA61C2432098319BF93A9DC1F8 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id EEA42280091; Sun, 5 Apr 2020 17:54:27 +0800 (CST) X-189-SAVE-TO-SEND: 71097365@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id D9C601AA61C2432098319BF93A9DC1F8 for shares@ndzh.com; Sun Apr 5 17:54:28 2020 X-Transaction-ID: D9C601AA61C2432098319BF93A9DC1F8 X-filter-score: filter<0> X-Real-From: yangb9@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Date: Sun, 5 Apr 2020 17:54:26 +0800 From: "yangb9@chinatelecom.cn" To: "Susan Hares" , "'IDR List'" References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> X-Priority: 3 X-GUID: 022F41B7-B32B-4EFA-943F-6E6CFE20F6AD X-Has-Attach: no X-Mailer: Foxmail 7.2.15.65[cn] Mime-Version: 1.0 Message-ID: <202004051754254707114@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart665160427781_=----" Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 10:17:56 -0000 This is a multi-part message in MIME format. ------=_001_NextPart665160427781_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0csDQogICAgU3Vwb3J0IHRoZSBhZG9wdGlvbi4NCg0KQlIuDQpCSU5HIFlBTkcNCg0KDQoN CnlhbmdiOUBjaGluYXRlbGVjb20uY24NCiANCkZyb206IFN1c2FuIEhhcmVzDQpEYXRlOiAyMDIw LTAzLTMwIDIwOjM1DQpUbzogJ0lEUiBMaXN0Jw0KU3ViamVjdDogW0lkcl0gV0cgQWRvcHRpb24g LSBkcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1LTAzLnR4dCAtIDIgV2VlayBXRyBhZG9w dGlvbiBjYWxsICgzLzMwIC0gNC8xMykNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIGFkb3B0aW9u IGNhbGwgZm9yIGRyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1tdHUtMDMudHh0IA0KIA0KWW91 IGNhbiB2aWV3IHRoaXMgZHJhZnQgYXQ6IA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS8NCiANClRoaXMgZHJhZnQgZGlzdHJp YnV0ZXMgcGF0aCBtYXhpbXVtIHRyYW5zbWlzc2lvbiB1bml0IGZvciB0aGUgDQpTUiBwb2xpY3kg dmlhIEJHUC4gIA0KIA0KQW55IGRpc2N1c3Npb24gcmVnYXJkaW5nIG9uIHdoZXRoZXIgb25lIGRl c2lyZXMgDQpTUiBQb2xpY3kgc2hvdWxkIGJlIGNsZWFybHkgZGlzdGluZ3Vpc2hlZCBmcm9tIHRo ZSANClRlY2huaWNhbCBkaXNjdXNzaW9ucyBvbiB0aGUgbWVjaGFuaXNtcyB0byBwYXNzIFNSIHBv bGljeSBNVFUuIA0KIA0KVGhlIHF1ZXN0aW9ucyBmb3IgdGhlIHBlb3BsZSB0byBkaXNjdXNzIG9u IHRoaXMgZHJhZnQgYXJlOiANCiANCjEpIElzIHRoZXJlIGEgbmVlZCBmb3IgdGhpcyBtZWNoYW5p c20gaW4gbmV0d29ya3MgdXNpbmcgDQogICAgICAgIE1QTFMtU1Igb3IgU1ItVjYgYW5kIFNSIHBv bGljeT8gDQogDQoyKSBBcmUgdGhlcmUgYW55IGVycm9yIGhhbmRsaW5nIGlzc3VlcyBiZXNpZGVz IHdoYXQgaXMgYmVpbmcgDQogICAgIFRha2VuIGNhcmUgb2YgaW4gUkZDNzc1MmJpcy0wMy50eHQN CiANCjMpIERvIHlvdSB0aGluayB0aGlzIGRyYWZ0IGlzIHJlYWR5IHRvIGJlIGFkb3B0ZWQ/IA0K ICAgICBJbiB0aGlzIGNhdGVnb3J5LCBwbGVhc2UgbGlzdCBhbnkgY29uY2VybnMgeW91IGhhdmUN CiAgICAgcmVnYXJkaW5nIGFkb3B0aW9uLiAgVGhpcyBjYXRlZ29yeSBjYW4gaW5jbHVkZSANCiAg ICAgZ2VuZXJhbCBjb25jZXJucyBhYm91dCBCR1AtTFMsIE1QTFMtU1IsIA0KICAgIFNSLVY2LCBh bmQgU1ItUG9saWN5LiAgIA0KIA0KQ2hlZXJzLCBTdWUgSGFyZXMgIA0KIA0KIA0KIA0KIA0K ------=_001_NextPart665160427781_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Support.

Best Regards,
Huaimo
From: Idr <idr-bounces@i= etf.org> on behalf of stefano previdi <stefano@previdi.net>
Sent: Tuesday, April 7, 2020 7:13 AM
To: Susan Hares <shares@ndzh.com>
Cc: IDR List <idr@ietf.org>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)
 
I support the adoption.

Thanks.
s.


> On Mar 30, 2020, at 2:35 PM, Susan Hares <shares@ndzh.com> wrote= :
>
> This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-= mtu-03.txt
> 
> You can view this draft at:
> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-li-idr-sr-policy-path-mtu%2F&amp;data=3D02%= 7C01%7Chuaimo.chen%40futurewei.com%7Cd38a5b3c6c3244e6acef08d7dae4be17%7C0fe= e8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637218548304749830&amp;sdata=3D= gvXnbU7daeeci6FDrRZx94oiB3TrTkQA24A2yphasEM%3D&amp;reserved=3D0
> 
> This draft distributes path maximum transmission unit for the
> SR policy via BGP. 
> 
> Any discussion regarding on whether one desires
> SR Policy should be clearly distinguished from the
> Technical discussions on the mechanisms to pass SR policy MTU.
> 
> The questions for the people to discuss on this draft are:
> 
> 1) Is there a need for this mechanism in networks using
>         MPLS-SR or SR-V6 and S= R policy?
> 
> 2) Are there any error handling issues besides what is being
>      Taken care of in RFC7752bis-03.txt
> 
> 3) Do you think this draft is ready to be adopted?
>      In this category, please list any concer= ns you have
>      regarding adoption.  This category = can include
>      general concerns about BGP-LS, MPLS-SR, =
>     SR-V6, and SR-Policy.  
> 
> Cheers, Sue Hares 
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fidr&amp;data=3D02%7C01%7Chuaimo.chen%40fut= urewei.com%7Cd38a5b3c6c3244e6acef08d7dae4be17%7C0fee8ff2a3b240189c753a1d559= 1fedc%7C1%7C0%7C637218548304749830&amp;sdata=3DNx%2FAH%2FmcOwx7V4shDgtq= 4SU4sNX2w%2F9BKt%2FSBjMplqM%3D&amp;reserved=3D0

_______________________________________________
Idr mailing list
Idr@ietf.org
https://nam= 11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Fidr&amp;data=3D02%7C01%7Chuaimo.chen%40futurewei.com%= 7Cd38a5b3c6c3244e6acef08d7dae4be17%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7= C0%7C637218548304749830&amp;sdata=3DNx%2FAH%2FmcOwx7V4shDgtq4SU4sNX2w%2= F9BKt%2FSBjMplqM%3D&amp;reserved=3D0
--_000_BY5PR13MB36511BF04241C3BB1B9A9283F2C30BY5PR13MB3651namp_-- From nobody Tue Apr 7 09:39:17 2020 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 063933A0E8E for ; Tue, 7 Apr 2020 09:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 Rczc5hNbmnHk for ; Tue, 7 Apr 2020 09:39:08 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 E215E3A0E87 for ; Tue, 7 Apr 2020 09:39:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Tue, 7 Apr 2020 12:38:58 -0400 Message-ID: <01aa01d60cfb$09ef2340$1dcd69c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AB_01D60CD9.82DFCD30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYM+YszaQKpvMuSQFO9dmXNJ7zgjg== Content-Language: en-us X-Antivirus: AVG (VPS 200406-0, 04/06/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IDR second session - 4/8 13:00-15:00 UTC (9-11am EDT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 16:39:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AB_01D60CD9.82DFCD30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Our second interim is on Wednesday 4/8/2020. -------------------- WebEx: https://ietf.webex.com/webappng/sites/ietf/meeting/download/5FF4D33B273CA952 E0536284FC0AC72E Etherpad for note-taking: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-idr-02?useMonospace Font=true Etherpad for virtual blue sheet:https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-2-bluesheet jabber: idr@jabbert.ietf.org 1.Administrivia + Status 10 minutes Status: Feedback on interims 2. BGP YANG Model Status and Issues Draft: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-08 Presenter: Mahesh Jethanandani Time period: 10 minutes Chair's questions for WG: 1) Does it matter that this is only machine friendly? 2) Are we ready for WG LC on this document? 3. Presentations - new drafts or status updates 1) Flowspec for L2 and Tunneled Traffic Draft: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13 https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-08 Presenter: Donald Eastlake Time period: 20 minutes Chair's questions for WG/presenters: 1) Are there implementations of draft-ietf-idr-flowspec-l2vpn-13.txt? 2) Are we ready for WG LC 3) Is the revision draft-idr-flowspec-nv03-08.txt ready for early allocation? 2) BGP Well-known Large Communities Draft: https://tools.ietf.org/html/draft-heitz-idr-wklc-00 Presenter: Jakob Heitz Time period: 10 minutes 4) BGP communities - Research into Worms Paper: https://archive.psg.com/181101.imc-communities.pdf Presenter: Randy Bush 4) Large Discussion time: 15 minutes 1) What are the operator needs? 2) What about the issues raised BGP researcher? 5) BGP Extended Community Registries Update Draft: https://tools.ietf.org/html/draft-cl-idr-bgp-ext-com-registry-update-00 Presenter: Christoph Loibl Time period: 10 minutes Question for WG: Should we adopt? 6) Open mic time Total time: ~1:15 minutes ------=_NextPart_000_01AB_01D60CD9.82DFCD30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our second = interim is on Wednesday 4/8/2020. 

 

--------------------

WebEx: https://ietf.webex.com/webappng/sites/ietf/m= eeting/download/5FF4D33B273CA952E0536284FC0AC72E

Etherpad for note-taking: = https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-idr-02?useMonosp= aceFont=3Dtrue

 

 

Etherpad for = virtual blue = sheet:https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-2-bluesheet

jabber:  = idr@jabbert.ietf.org

 

 

1.Administrivia + Status 10 minutes

  Status: Feedback on interims  =

 

2. BGP YANG Model Status and Issues

Draft: https://= tools.ietf.org/html/draft-ietf-idr-bgp-model-08

 

Presenter: = Mahesh Jethanandani

Time period: 10 = minutes 

Chair’s = questions for WG:

1) Does it matter = that this is only machine friendly?

2) Are we ready for WG LC on this document? =

 

3. Presentations = – new drafts or status updates

=

1)      = Flowspec for L2 and Tunneled Traffic

Draft: htt= ps://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13<= /p>

        http= s://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-08

Presenter: Donald Eastlake

Time period: 20 minutes

 

Chair’s questions for WG/presenters: =

1) Are there implementations of = draft-ietf-idr-flowspec-l2vpn-13.txt?

2) Are we ready for WG LC

3) Is the revision draft-idr-flowspec-nv03-08.txt = ready for early allocation?

 

2)      BGP Well-known Large = Communities

Draft: = https://tools.ietf.org/html/draft-heitz-idr-wklc-00

Presenter: Jakob Heitz

Time period: 10 minutes

 

4)  BGP = communities – Research into Worms

 Paper: https://archi= ve.psg.com/181101.imc-communities.pdf

Presenter:  Randy Bush

 

4) Large = Discussion time: 15 minutes

1) What = are the operator needs?

2) What = about the issues raised BGP researcher?  

 

= 5)      BGP Extended Community Registries = Update

Draft: = https://tools.ietf.org/html/draft-cl-idr-bgp-ext-com-registry-update-00

Presenter: Christoph = Loibl

Time period: 10 = minutes

Question for WG:  Should = we adopt?

 

6) Open mic time

 

Total time: = ~1:15 minutes

------=_NextPart_000_01AB_01D60CD9.82DFCD30-- From nobody Tue Apr 7 11:51:25 2020 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 213F33A0D73 for ; Tue, 7 Apr 2020 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_IMAGE_RATIO_02=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=juniper.net header.b=xmc/1mBe; dkim=pass (1024-bit key) header.d=juniper.net header.b=gcmceHvb 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 8hMaxr_4hf3a for ; Tue, 7 Apr 2020 11:51:21 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759D43A0D71 for ; Tue, 7 Apr 2020 11:51:21 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 037Im6P4010805; Tue, 7 Apr 2020 11:51:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=EHdgZL3MkPw1hWq1dzC2rizaKUahfM4p27M/axABDiI=; b=xmc/1mBeWgTIfkxi9T4ZgRaNa1FItmd9jGjYtmNiqldUGfr00ewQFHieA/peHtC3PliJ KJXp0TJT6WK3FECc4Nh9shFOy514E/67J1FpL4uGAjg9iDP0qX41bwNqzOPDAJmQp8ul mEae/LEVxDSsV/pnqA/vBgzgAa23vcdPSqhvjcVR0pm1H2AXCh6wbT6n7KIEn9NT1NsJ 2H2JNqMfO66YfvImwMXgSAxhraZVz/0Az3psb4+0OdCOzu0u3CJWD2vqOqDEWdRP8qpy vUBFJRGCQOKRVChn/+dmf+fmbvR6UIs1f+jR5Ky5hX5VsXaBtpDlP0CIJTgbkb9XuuE4 hA== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2050.outbound.protection.outlook.com [104.47.38.50]) by mx0a-00273201.pphosted.com with ESMTP id 308bxg23b9-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Apr 2020 11:51:20 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ncMUwHcXtGsqIQ52gytAMuBAn6lpOuOV+ijRmEAKIgnMPT+nIaHZ1H5JqwzyLs8RkO/FcwEc+gNATQ0kND5Tecl27DtW7ue8j1MKv5LR7A9sUdr6xyNmodm9tTGZ/nLLcpWPBcU/EhaWA0q1Hwgaum5F79dXY/n2VLIExdqnhxp34+qbzNo+HWnneElJSFGXm+TCuPJurS7w0Mk5kFYvEdunfD/InFCvHyxWPmYr+q7pRbqfJOsJnk4necwgLyaxIC41D1NIY6AupdGhe/SOkdZiB/9EUXqSooetfeRtqQn7DVi9/Ff16H6RUMWWidcqXxJw4SVxF5hg/+JtOwRQig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EHdgZL3MkPw1hWq1dzC2rizaKUahfM4p27M/axABDiI=; b=AFJSAKTz8YUG//atxkyJWw6AWeGyqKxEZCuWWUxSD1wxKvbt8xb22IYWJP5kxgTpGxcCSWTCD1Za844VzffudKCkukDVk+nrVxQbrbG7sXqzAH/KzNZ2YjMcicdw7tvJYoHCnsqzT9X4HZIb48hIea3G6B3Gp3EflPHS4okPmzDtlNwz3Upf9izDr/J9IgK4/02xNSTIdgNrlYk67hcIymAN+0iIdCSW9VHmKKsgd1Yzghrtae84HZOWF8Zb2I7bChkYmW+15kxU94jt+NSm62dfDw55Tc7v0NIRxfdx313v24nvfWhyoac2n1Ac1cYEdqLjhgjVzw/C+sUW+TgSTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EHdgZL3MkPw1hWq1dzC2rizaKUahfM4p27M/axABDiI=; b=gcmceHvbw5WQrxXmi+Gad3TiarL1jZBLsm1UM+1qSCO9ySYnflOXFJLI8HJdOFeTAOzqpA++7oMQNz6WIFOx75mdNf32XJfTFKcSDNsKkhHBQi+cRP04Z1fTiZAIcFuxVWXd0ULTB5zULtDe9mLfTCd+NNWogSFalYx6erIYNbo= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB6738.namprd05.prod.outlook.com (2603:10b6:208:64::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.14; Tue, 7 Apr 2020 18:51:15 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2900.012; Tue, 7 Apr 2020 18:51:15 +0000 From: John Scudder To: EXT - randy CC: "EXT - joelja@bogus.com" , Interminable Discussion Room Thread-Topic: [Idr] router id Thread-Index: AQHWCHIJXBgjZVKYGUCW5SSj9gbIh6hk1oAAgAAJW4CACSpHAA== Date: Tue, 7 Apr 2020 18:51:15 +0000 Message-ID: References: <4074fcfc-e1ec-b86a-9741-a86661a964e3@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-originating-ip: [2600:1700:37a0:3ca0:71eb:2155:fd58:729e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f2b4cb74-9338-4e57-5dfe-08d7db24a67f x-ms-traffictypediagnostic: BL0PR05MB6738: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(366004)(99936003)(2616005)(53546011)(5660300002)(81166006)(33656002)(6506007)(36756003)(6486002)(86362001)(6916009)(2906002)(186003)(81156014)(71200400001)(8676002)(558084003)(6512007)(4326008)(66476007)(66446008)(66556008)(8936002)(76116006)(66616009)(91956017)(54906003)(498600001)(66946007)(64756008); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y3nd6hj/xVKireEaxJY7tTCSe4ew+Ka942v1qGE0Swj5HhZ3yzPTt12KjU1aEn69A6cE+mjrl/fUDOI4bNh58kr2xZms7hQSduPWwbfq4Vt25P9V3QVel0DXLuSRVoAU0KgYxENdofxGkgl3ypDDxhljeZ7dAih2Og2fETtwQNZpyqenwTVhGgI5AkrCruDxxaXi9qvBbIldn9RsCBL4xzueOnlpsZMUaQfQmZfk+TJivmHmWk6TKp8O4wnjlV+Zp+TbFFVrrL9SImhUxdieaECNsJ7Nub7iT1SIgeNbt2Nrjhzy/sVqAXPB96FuXYQYktPfey4xE3QOiuRGgh1ksNRP7NmblZfTlaNH/YOUeaPy1cORFCABeLwGE7OIM8BWtETrJeyZB7TBxa3rhcuhFM9PnQVDo6Yz+gsiXloynj+rcrcIMpwYAgpAXyk52Fgc x-ms-exchange-antispam-messagedata: 3q9I5FaYuOl5sC5aSQS8OKCFwp4nPKZMFdkdzr8rYVJ+kuvbml/WDN+BVzqYtHqQ9275WvqhuuqGNxeJa2+csbT8E8ZiFN2E5N6rChcxCOLDwq+MA+GbiiKLk3Ak7quEZDPq+IRFcHE4wN3FyxudmrI9Ve4TYjJEjrLfxnzXiRJ1+10Xg6D3REeoN6QC8aZ7JfRQmcMU+bhWSRVy5jbdSw== x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f2b4cb74-9338-4e57-5dfe-08d7db24a67f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 18:51:15.3565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p3zb01O/hn3LDIe26M4K2Qfap3pHaj9sKQMyl8uqoeE7fyg9e/UdZJJyo9I4v0w8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB6738 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-07_08:2020-04-07, 2020-04-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 clxscore=1031 mlxscore=0 lowpriorityscore=0 phishscore=0 impostorscore=0 spamscore=0 suspectscore=0 adultscore=0 priorityscore=1501 mlxlogscore=955 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004070152 Archived-At: Subject: Re: [Idr] router id X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 18:51:23 -0000 --_004_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_ Content-Type: multipart/alternative; boundary="_000_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_" --_000_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gQXByIDEsIDIwMjAsIGF0IDY6NTMgUE0sIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb208bWFp bHRvOnJhbmR5QHBzZy5jb20+PiB3cm90ZToNCg0Kd2hpY2ggYXQgbGVhc3QgdXBkYXRlcyA0Mjcx DQoNCmJ1dCBpdCBkb2VzIG5vdCBhZG1pdCBpdA0KDQpVbmxlc3MgdGhlIGRhdGUgd2FzIGEgY2x1 ZSwgb25lIG9mIHVzIGlzIGNvbmZ1c2VkOg0KDQpbY2lkOjA1OURFN0ZDLUM0RjYtNEM0RS05NjE0 LUZBNDIwRDAwMTdGOEBhdHRsb2NhbC5uZXRdDQrigJRKb2huDQo= --_000_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk9uIEFwciAxLCAyMDIwLCBhdCA2OjUzIFBNLCBS YW5keSBCdXNoICZsdDs8YSBocmVmPSJtYWlsdG86cmFuZHlAcHNnLmNvbSIgY2xhc3M9IiI+cmFu ZHlAcHNnLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0Kd2hpY2ggYXQgbGVhc3QgdXBkYXRlcyA0Mjcx PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPmJ1dA0KIGl0IGRvZXMgbm90IGFkbWl0IGl0PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlVubGVzcyB0aGUgZGF0 ZSB3YXMgYSBjbHVlLCBvbmUgb2YgdXMgaXMgY29uZnVzZWQ6PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aW1nIGFwcGxlLWlubGluZT0i eWVzIiBpZD0iODRFM0NERUEtNzBEMS00RDI3LTkyNEEtNjBEREZCMzAzMjMyIiB3aWR0aD0iNjQw IiBoZWlnaHQ9IjE2NSIgc3JjPSJjaWQ6MDU5REU3RkMtQzRGNi00QzRFLTk2MTQtRkE0MjBEMDAx N0Y4QGF0dGxvY2FsLm5ldCIgY2xhc3M9IiI+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlEpvaG48 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_-- --_004_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_ Content-Type: image/png; name="PastedGraphic-1.png" Content-Description: PastedGraphic-1.png Content-Disposition: inline; filename="PastedGraphic-1.png"; size=94331; creation-date="Tue, 07 Apr 2020 18:51:15 GMT"; modification-date="Tue, 07 Apr 2020 18:51:15 GMT" Content-ID: <059DE7FC-C4F6-4C4E-9614-FA420D0017F8@attlocal.net> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABQAAAAFJCAYAAADE/IBAAAAAAXNSR0IArs4c6QAAAJZlWElmTU0A KgAAAAgABAEaAAUAAAABAAAAPgEbAAUAAAABAAAARgEoAAMAAAABAAIAAIdpAAQAAAABAAAATgAA AAAAAACQAAAAAQAAAJAAAAABAASShgAHAAAAEgAAAISgAQADAAAAAQABAACgAgAEAAAAAQAABQCg AwAEAAAAAQAAAUkAAAAAQVNDSUkAAABTY3JlZW5zaG90Ku47ZwAAAAlwSFlzAAAWJQAAFiUBSVIk 8AAAAqhpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6 bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDov L25zLmFkb2JlLmNvbS9leGlmLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnRpZmY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgICAgICAgPGV4aWY6VXNlckNvbW1lbnQ+U2NyZWVu c2hvdDwvZXhpZjpVc2VyQ29tbWVudD4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjEz Mzg8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhlbFlEaW1lbnNpb24+ MzQ0PC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgICAgPHRpZmY6WFJlc29sdXRpb24+MTQ0 PC90aWZmOlhSZXNvbHV0aW9uPgogICAgICAgICA8dGlmZjpSZXNvbHV0aW9uVW5pdD4yPC90aWZm OlJlc29sdXRpb25Vbml0PgogICAgICAgICA8dGlmZjpZUmVzb2x1dGlvbj4xNDQ8L3RpZmY6WVJl c29sdXRpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBt ZXRhPgoLRVxsAABAAElEQVR4AeydBbwd1fHHz7MYJCEkuAX3PxQIENylSClOcae4Q3GKu3uhlJZS pLhDgeJOcWiR4BogxHX/851kLufu273v3vfufZLMfHKz+3b32O/InvntzDl1iUioogwbNixMmjSp ijF6VI6AI+AIOAKOgCPgCDgCjoAj4Ag4Ao6AIzBVIFBXF8bce1f4cufdgpAHk4sk10JTY2bxkvHj Q6/VVgoDzjwndFtyqZCMG1f0XP1004VPVxwUxv3njRCmsBv1vXqFfkcdEvr+/iCJtykEiT8Z9lMY ceNfwrghQ0L/E08Nodd08vzk9Ov79Alfb7dNGHHrPwtxJw31YYadtgv9jj0x1M84YPL1CRPC6Hvv DMPvvivMfNFlIfSdIYT6+jDh44/CsIvPl2eS0Gen3UPTUkv/Uja5H0aPCd8fd2QYfuPNYdKYsaH7 YguG2e97ONTPIOHTlIw8P+nHoeGns84IP1z5p9DUr6+U5YjQ96DDQjJ6dCF/WSd1jY1h2GUXhdHP PRP6bLt96LnO+iHItYJIWmOefSZ8e9D+YfxHn4b6Xj3CDAcdEGY84RSJe1Thsbae1PXsGUY9dL9g up3EO6W+yEe91HOO1HfrHuZ6/tnQMMdcv2AiWIx97eXwza47h/FDvgj1PbuHvvvsGfqffDpQh6En /CEMu/pPYdLosaFxzlnCrH+7KXRf6le/hM9Jq07axJhXXw5fbrxhmDR8TOi1wvJhlmuuCfXzDAxh 4sRmoeq6dQtjHrgnfL3X78PEH38K9f37hTnuujM0LbZk9Ky0sR+GhpF33hYmjBoZ+h15bEhG5WNa 37dv+HzdtcKYx/6tzXaOm/8Reqy9jranKNLCaaPg17t378LfrTmJWkJrgnsYR8ARcAQcAUfAEXAE HAFHwBFwBBwBR8ARcATagAAk2LjxuREkQqAlGcRMVoC67t3DTGedGqbbaQ8hcyZMJoMk/rrefULv fQ74JcgU8u+XC7+cJcJT9T9ov9D3sKNCnRKFU5hFIWF6bral/vRpCEz5Nc41d+h/zoW/RDBJnofU RCjb9NOFGQ44JIx+7Mkw/uMhYew7/wsTv/4yQAJVUxIhKPvsvZ/+CvFaPrgghFr35QaFvrvuEb47 /oQwadSYMO71twX7sZPzS15rJZK3UkLKaXIX7LovsVTof9yJ4dt991Oib8Qt/wzT/3bLMOHD/4WR t92u1yD0Bsgz3RddvFQSrb9XVx/Gf/1VSCZMJge7Lzx/aFxwkVR80sZmnDFMv9teer0U+ZcK2G5/ OgHYblB7Qo6AI+AIOAKOgCPgCDgCjoAj4Ag4Ao6AI1CEgJBSDf36/UKYFd0UUkj+bhgwU6hr6j6Z TEvdT//ZtMTCode2O04m/9I3y/y7cdYBYfrtdykm/8oJC9k2YXxIxo4T40IhiyAIIdXkesMsM4c6 sXIzii357rsQFhISKSboykmjnGeIU9JOxo4RHORoeZGwWAk2zj5bIZZkzOjAL3TvURa+hYAVnGBB h6VmaGjIDcUzdeQhFrBr6hZ6rrtemOHA/cKPF14axn/xVfj+kIPChK+/1fO6xobQb999Qs8Nfi1l kDYC5lUXIfemn75gwTj6xdfChPfeDY0LLSTtsltxuWpJoraxXE4AthFAD+4IOAKOgCPgCDgCjoAj 4Ag4Ao6AI+AIOAKtQ6Bh5pnDwPffD6FHCQJKrP9wBeZXUoT46rPppkpyNXOtLRnwl5sQdL032FDc PGf85WJLZxBuYuE24dtvwviXXggjH3s0TJTzCV99HSZBwhFpo7gKD/ksYBfIn1qWKeRgS9FXen+S uDuPf/e9MPrBe8O4Lz8PE7/8Kkwc+v1kSMQNNxk5Kohj8mQyEsvKMq0rK80Hz1PW6dZZPQw476LQ tOBCYkWXYwkoWCRjwIoQkQh52TBj/9BbXMbHv/9eGH7/w2HMK69PfkDI4+nWXj303mNPeWbG/Lij 6Fp1KpZ/3RdaWFyme4VJw36Wup4YvtxphzDDNluH7ssPDo0LLyL3egZcn+t69JxM6qbL0aqEqxvI CcDq4umxOQKOgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOQLkIQPywtp1Zy5UbLus5IeIa55gz607Z16Cf GmabTUhEWTuwHJE0cV0dI6Tf0NNPDWPefFdJPoLWCdmGxZ2c6b8kcnNOIA1hA6sp4qo64ZOPwo+n nRx+vvWuQswko/kQwkwlcn8mH/yqnZVC4pxA4Aq5h1tsLgFYFKD4D8jSpvnmD30OOEjwfUuI1M/1 gcZZ+4e+hx4RGgfO2zI5XBxlRX8l4kre9KtBYbrNNw3DZZ3BScOGC86fh+/PPl8JzoYe3UKPQcuE XmusEXqutX5oWnyxyZaBnYwEdAKwomr3hx0BR8ARcAQcAUfAEXAEHAFHwBFwBBwBR6CzItAw8yxt zlrDTDMXb55RIsY6Ic/GvPBs+PbwQ8Ul9RtZZq8+NAqB2DjfPKFp7rnEMk3cm8VNFRfXn6+9IUz8 fujk2NjMBLaxWsyb5CPIRh7fH35IGPnovzXa+j69JS+zh6ZFFgiNM4sbtaxFyDqA4z/6JIy44+7J +TALQMJ3ViFvms9JoUE2bDE70AZZ17FOiGN+4qQruU9ZD1axPMnYsWGAbJbS2L9/GH6LrD34ww+y huKoMGnESNnYZVwY9dTz+mu86pow4LTTwvRbywYoNbSsbE3RnABsDWoexhFwBBwBR8ARcAQcAUfA EXAEHAFHwBFwBDodAqyz11apa5T16MohxGRNO1xrR917j5J/dUKudV9ysTDTBeeH7iuuLKSfuDWz EYmQU3XdmsLI+x4JE4wAbGsm0+HF0nDME4+G0U8+P5n8m0F2Dz7s4NB3511DPTvrQkZhkSbPjbxT djIWArATU37FpYO0/Pij8PMVV4Qxb7yj98j7mPc/DMMuuTg0zCqE67zzixWplLFWgqWqkLgzHHtS 6LPHXmHM00+FsW+/FUa//EqY+MHHYfxXsknIqNHiBj40/HDGWbIb8VKhcRHZlCTP5blW+SwRrxOA JcDxW46AI+AIOAKOgCPgCDgCjoAj4Ag4Ao6AI9CFEKiK22WZlmRCEmIJNubV15RMa+zfL/TZc/fQ fdU1QzJihLi9yu66InUNjWHif9+VtfdG6nMtxh4zc/JwgpWbxFMqXJ2QkaOeelqemrwJxnSbbBBm OOxI3ZBk0rBhZEOt/4Js+DFB8tJlRNyak6FDw8/XXROG332v7pnSfYklwqThw8P4Tz4NP9//kFhb zhv6HXKE7sLbbA3BahV0CiGMG3Nd736h16ZbhF6bbx36SXub8PabYdjfbgg/3/A3aQ8/hUk//hhG PvFY6Lfkr8KkkgRgVNFSx7WWKQ7gtU7G43cEHAFHwBFwBBwBR8ARcAQcAUfAEXAEHAFHIAMByJVy fhlBO/KSknJC8EwaOUKzUS+7GXeba55QJ+6iKlYmsf4b9fSTYdLPP7WcXSUwG0IDm6KITBo/TtxM h4dErOCaYRTHJmlNHCEbVBBezrsvsqiuTaiPWD54RgjL0c8+2/7Wf5K20l1RXpqVh3ux8Pe4sWI5 eXf4+frr9U7DzAPCTBddEPr94cjQyM7KcnXYddeFEfJMwK06HYfFF6U7OZVUWhnP2SWL8xerULEG lHph7UrWNmwQS79+shZhz5VWUJJ2kuR54g/i6i1rQOaK8H31vXHJnvzMpOGQtJPrrgiX3Agqv+EE YOWYeQhHwBFwBBwBR8ARcAQcAUfAEXAEHAFHwBGoBgJCzGC9xiYVJX9iCWZETDWSrVYcuPbWi7st 1nlY2o0TV9XJG3xIuYS0q2uQjTn+99/w041/CxN/jAjAPKJK4iHOuv4zaRZxKx3/3vtiBffdZHyI k58RWlYQIZQa2bkYnETGSZg62XSEZ8FNj7JG4KhHHgwj/vVo+xKAbIYi+UiapFyl6nlKXrUA8GJC Zo598fnw46WXhgnDRuouvNP/5reh+zKDQu8ttgnT/3az0CC7704aNS78KKTgWNmBOdMCkPJHv0Tq hA1aYhCoJ8O1gC0YI3Kc+MmQMO6N18S674fCc1xXbMXNexIWn7I7MO2A9tzQvYeea/iM/xJxV25i sxnBBBnz6kshjB03OW7ql9+U+DOCt+qSuwC3CjYP5Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Ag4Am1F ACuqn//xjxCE9MplTMQ9stvCC4Zuiy0R6rCMawd3yXLKhWtufe/eoftCC4dRz70cJn7zney+e2vo vujioWGWWdVKbMI3X4uF2rVh/PMvS76hh6aIWvrZH8VHytgw99yhvklIs/GTxGLvhfDTJZeEnquv XiCMguxS3DT/ArKxx/ST8RBCqduSSwlxJLv6Stwj7r9f1iEcHHoOGiSEYvcw8aefwugXXwjDLrtc LNeEGCxOsqZ/jf/86zD8nnvVYi+ZmO/q2jhz/9BzzXWmkHh1YcLHH4afLrskjH3/g9AgBF3PVQaH PvvsPdmVuXv30Pf3+4bxH34YRj32eBj34afhxwsvCANmn33yeoARvsnI4WHcRx8KMzeZHGWH53Hv vyfYTl4zcJK4Zo995+1Qj6u0rpU4uV4bZptT21tdU7cw6l8PhpF33Rt6LDsodF9p8GTrw+n7yJbR 9eoGPkpI1dHigg2u9bI5SbfFFiu9/h9tesEFQr2UIxHib/hd94TG+RcO3RZdNNTTxiH/hBxskrUN 66SNVUOcAKwGih6HI+AIOAKOgCPgCDgCjoAj4Ag4Ao6AI+AIVIwAVnPf7L9/yXDQZjPutlPod8zx oa5nz6JnlVLL55SKni39R0TOlX7wl7tCMtX3mzH0WH2t0PTgI7LD7/dhzDMvhO+OOjJ0X3hhsUwb rRtFjP/k89A0cO4QhsrOscOmuOn+EkvxGcRVfUPotvgSocdyy4bRr7weJn77XfjhzLNCt7tuV8JR 2KFQ37dP6H/qmbLD76JKACYTxoeeK64SmpZcPIz9z5th0tBh4fujjw7TrbZaqBeScPznn8v115X0 6r7gvEKYfTKZ7CpOvXp/TYETQmzsm2+HMW8e22LcPQctFeZcZwMhMMeHRCztht/w5zDiwUfVS7ZJ yLI+e+8duom7bSLrGCKNCy4U+uy7bxgnZUvefS+MePTx0O366yavB9i37+T0BM8J//0gDD3p+IK7 LTshTxJrTCNCx3/2aRh67jlqYYgFIcRur2WWCb332Tc0zDaHknHJyNFKxI548pnQdMtNoft88wfd cVqI6wmffhpGP4/1oVgaCqHXc9VVQg+piwSX5DwRN+Fea60Tfr7xpjDxrXeFPB4avpP66rbAfKGB vAsBWN+nbxhw4kmhUYjdaogTgNVA0eNwBBwBR8ARcAQcAUfAEXAEHAFHwBFwBByB8hBobAhBiBKT yXZZ9lfzI1xSXaM8j1UUBFlaegq10WMKMUjcFUoihFpdk8QxhVxMLI6MpIqiJi+ywUevX28UBjTU hZ+vujqMfvU/Ycw77+sPV2As13rI2nD9hcgZesYpYcyzYgmIiCtsrhmexNs073xhwNnnhxE33SiW e88ryTRuyBdq3afBe/dUIgw3Uc2mhGmYay5ZH+9i2S338jDitjvCxHETw/BHHiu4pXabZUDovfXW oUl2qP12r33EkFJCgimut9W2qsSltq4xJD3FvVsyzK8l0R2cqWIh+EbccnP48errtE6a+s0QZjzu mDDder8ukH/EhfVor3U3CP3l+P2hh4cJYuX40zV/Dk1iBTj9LnuI5WM3TXLCTz+EkS+9WpQHzdOU +p40bkIYK7sLW3VzrJf2ML1Y5iGJuPh2W3Sx0Gvt1cOYl2TXXyFXR37/yi9tUTCsb+oeui++cJh+ i63C9FtuqcRwUmIDkEQsDRsXWCTMdOHFYeStN6t15oSvvg7jP/sqjPv0S023USwVk1GsL1kOehqk 5H91YhpqZSz5YLk3hwl7P6naDafcxP05R8ARcAQcAUfAEXAEHAFHwBFwBBwBR8AR6NQITPzu2zDm 5YhAKSO3TfMODE0LiMuruLMWkYBCXo1+7mndfRWipOfKK6nlVBlRFh5hl94xr78aJnz2ucQt3OTS S4XG2WafTI4VnipxAokmhM44cSMd+4ZY7IlbKhtBNM4+Z2iYd16x/psndBf35dGvipuwkDyk0WOF 5UND//4SaQ65Q5wik34cKqTQp+LCO0x2Fh5VKHtdzx5iIThIyipuqDGtI+vPTfz8UyGqJK0hH4v1 4Lehbrpeko8FxDV2YOi+4IJKlo5++t/ioiqk4YD+Es9ySmQWxaOpt/I/qRO1hnxJ1rXDpbZMaRgg 1pQrDA5BNtgY9957YfyQT9VqD2vHnuQRkjcuK/GCk2A9+oUXZZOVydaVTXPPqe7iwr5qyhMFwzHP iYVeBdIwy0xSZ4uHul6yUYdIMvznMOHLz8O4L77S+k1kp9+JUzZ1aRgwk1gDzhyaFl88dFtoYXUB TsaPLys1SMqJ4iY+/ovPZWfjEZMtRKdwatzrsbzUcd8ZQqOUpXcbXYGdACyrSvwhR8ARcAQcAUfA EXAEHAFHwBFwBBwBR8ARqAoCQhDhKlmRiDWVWlSlCSCJROPCik2EXVmbkUR6p8R/Eqdai2GVJ6Ku mxUQVxpIiCiIxMCGED8LWSfH+ul7/0IgiTuopjGFlErYKbgc4ylxB67DIpHyTSEFJ2dSXFWJIwsP 8lEn92Vtu0mjRkl42ahESLQg5KmWjfJO2WWYPGg8GmkV/2tNHRfyMsUic0p9UMa8shawpz0ZPrSV mIBrTV6k/jUOw5f6JT8SVyKbqdDOEiEekboevUK9ELJB1gosCqN3y/iP/BE3+ZfzgkTlbpT7TgAW kPETR8ARcAQcAUfAEXAEHAFHwBFwBBwBR8ARcAQ6EAFIHCOiII+MQGrvLFke7NiReWnvstc6PcPU jlbHdqxB+tUgAIVidHEEHAFHwBFwBBwBR8ARcAQcAUfAEXAEHAFHwBFoMwKdhWgzMsqObS6YR1BA wDC1Y+FG5z6JbAs7d0Y9d46AI+AIOAKOgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCNQOQJOAFaOmYdw BBwBR8ARcAQcAUfAEXAEHAFHwBFwBBwBR8ARcAS6DAJVJwCrvKlwlwHSM+oIOAKOgCPgCDgCjoAj 4Ag4Ao6AI+AIOAKOgCPgCHRGBKpOANbZIoidsbSeJ0fAEXAEHAFHwBFwBBwBR8ARcAQcAUfAEXAE HAFHoAshUA1juzqJRLalqZ4QXZWjrF7mPCZHwBFwBBwBR8ARcAQcAUfAEXAEHAFHwBFwBBwBR6AL IYCxXVsN7qpOAHYh/DyrjoAj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Ag4Ao7AVI9A41RfQi+gI+AI OAKOgCPgCDgCZSCAB8PYsWPDxIkTQ2NjY+jevXsZofyRNALjx48P48aNC/X19YohRxdHwBFwBBwB R8ARcAQcgY5FwAnAjsXfU3cEykbA3OurYfpbdqLTwIOGK0V1JbXrVzj1CXmDNDQ0tNlMvusj4iWo BIFPPvkkXHfddeGjjz4Kq666ath7770rCe7PCgL0v4cffjjcdtttYYYZZgj77LNPWHjhhR0bR8AR cAQcAUfAEXAEOgwB5ifoCejS6AjTqtSMAOTr76RJk8rClUrgS7sr32XB5Q+lEKCd0d4qkaampi7V 3rBIGTJkSBgzZkyYbrrpwsCBA7XPVFJmfzYbgW+++SZ89913Ol7NNddcYcYZZ8x+cCq62po+Exef Mbtbt27xpU5zDnHzxRdfaH1COsw222wdljcsoJholCu8B6flCUm5ONXqOd4jd999dzjllFNCr169 wmKLLVYyKSaSEyZMKPlMfDOrfiuNI54vVbsfEx9tljTKlSwLScL37ds3/P3vf9f2/+OPP4arr766 044Z5ZbVn3MEHAFHwBFwBLoKApVwMZSpM8/tszBnfk0Z0ZFt7mKeG+go6bkMz7/++uvh559/1vnI csstN83OS2pGAL744ovhs88+y6qvomtUBpW02mqrhZlmmqnoXrX/YKI9YsQI/TpNmhAp6cZR7TSn lfhGjx6t5BT12bt37wDB1l4CgfPEE0+UXZcoOauvvnqYY4452iuLbU7n7bffDtttt13473//GxZf fPFw3333hXnmmafN8XoEIZx11lnhwgsvVCguueQStfhpz/bbEXXw/fffh3/9619l95l0Hhk/N998 8/TlTvE39XnNNddoXjg/7LDDOoRU++GHH8Jzzz2nE41y3jOMnUsvvXRYZJFFWl0vnaICunAmmBhe fvnlWoLBgweHbbfdtmRpXnvttfDxxx8XLE7zHqZuGVMgFNOk4jvvvBPef//9solE4vnVr34V5ptv vkAbe+SRR1rdXoiLfkz75L2I9SNtttyPsYTbYIMNlOyLy074ZZddNvzmN78Jt956a3jooYfCU089 FdZee+34MT93BBwBR8ARcAQcgRoh8Pzzz4cvv/yyrA/RzFP69Omjng8cO7OQ1+HDh2vZ3n333fCf //xH9WM+SM4+++w6l/6///u/MOecc4bpp5++UBTIwm222SZ88MEHoX///jrfWXDBBQv3p6WTmhGA xx9/fHj88cfLwhKLB9xF1lprrbKeb+1DdAK+SGPts9BCC4Xtt99eScDWxufhfkHggQceCJC+sPC7 7bZbWHLJJX+5WcMzBoFnn302/O53v6solX/84x86CFQUqAMfRtEyUopjOYRCB2a3SyUNliisKMCc 06amdnnjjTcq7jMxJrTBkSNHFtpkfK+jz+3rH2NRR1rT/e9//9Ox8Ntvvy0bkmOPPTacfPLJHZrv sjM7lT3IZPKOO+5QMg7rtQ033FBJtlLFvOiii8KNN95Y1pjB2HLEEUfoB4c4zj//+c/hggsuiC+V PId8P+ecc8KBBx4Y+DBU6bsvjpw8jRo1KvTo0UO/ot9///1h//33jx9p8RzSlIl2Wojz0EMPDffc c0/gI925554bVlpppdCzZ8/0o/63I+AIOAKOgCPgCFQZgRNOOEENZMqNFvLswQcfbDcdvtx8xc+h qzGnYO50+umnqy7CXCYW9LhZZ51VjTv4yGn6M88wh7JjOpzemEb+qxkBOPPMMxdZ9KGMYXKJoKAx wbavzFjiMVmstfClHgsf3MMGDRoUNttsMycAqwQ6blN/+ctfNDa+/GPl0F7Kd5wO57D6pUgc7uHe 1ZWEctFnWE8p7jtdqQydNa+MP7j98mVoWlFOGW8HDBjQjEimbwwbNqzgUo81b9bYzPVp+cVZTlvm /WbYcU6/ZRJSamyif7t0DAK4jkPmIby/mB+0JPQhJpnmBswY8tNPP2kw+ke/fv0K70HaQlb90ib4 as0ciYkpfcvmRlnp82WetoQQrpx+zBfwrLGNa3E/Zm5mQr6y8mv37WiTafvbjsQLjqyjiJUiHx2w AlxvvfXsET86Ao6AI+AIOAKOQI0QYI7AfALSDL2XuUDeHJTreMblvdNrlMWKosWTk4/rZ599thKA BGZOxFwLXY65GB81+fAOSfjmm2+GTTbZpIgArCjBqfjhX2Z7VS4kX6VXWGEFjZWGh4nmtddeq3+z JtOee+6pDZF7TELnnnvuKuegeXR0AjoDwjGe+DZ/2q9UgkDMrseEXCVxVONZBoFjjjlGB7u8+FC0 Fl100bzbnfL6LLPMEnbcccfw+eefh4Gy/h9Kokt1EFhjjTWUqGF5AFwwYyW4Oil0vlhwHz/88MOb vehZQ4O1uiBDkF//+tfqypfGBDKjI/t550O0dI4gbPbYYw+dXPHOyxKuQ5b4eykLndpeg7jDgh0X WNo6Fuzzzz9/i4luvPHGYd555y24ADM+n3/++RqOOj/ggAOUrGNizaSaj2OlhPfSlltumfthknjo e8sss4xGw5qlef34T3/6k7q58CDWjHz0TPdj8hS/u+O8MUbsu+++8aWic/JCmy21dAvzLNxtIABZ duDmm28O6667rrfxIiT9D0fAEXAEHAFHoHYIwH+sssoqOhfg3Z0lkGd8UCz1Ts8K157XmEf88Y9/ DDfddJMmi8HPrrvuGtDj8OzEk+O9994Ld911V3j66acLnE975rGrpFUzAnDTTTctwgB34JgAZNKa 9UU6DkQjtZ8pm0w4beKJosSPhp2nNNnz9qzFb+Fgk00sDuIrJZa+5c3iLpWPOD4Lb+E42jXyi9g9 K7eFt/v8bfm0MnK0cOXmhXgsbTtaWDvyTFrsWa5bmvaM5SuNrV2352pxxJLroIMOalXUhiPlIa+U 0crJ0fAopxxxuHRY/uaHlIorfo4Bea+99iqUq1Q4HiJs3B4ok12ztK2cHMsRy4/FQzj7tZQfiz8d B9cJa3mx50od0/XEs1yz6/zdUpw8a7LmmmsGfoiVx+5lHS2dOM9x+na9XExKhbV8lpOvrLzmXYM4 OOqoozJvs16XEYC//e1vK3KVN2ysnknAcLA6yUw0ddHamMXD0cIbFhzbIjY+VSu+UnlhXGI32XJI pbx40phYvg2XvHDxdasfwlq9xO2PZ+2e3Y/Dx+dx3Vg7tby0FNbisfxYXJWGt3jaeuRrsVn/8YGy XCs11rSL17Xjy3RMAB5yyCEFa71y8ogr7cEHH1y0Zk2pcHytz+vHjz32WIEAZD62ww47lIqq2b2B 8qGJ/LdFIADXkIk5loRYRrIeEWtDt8cH37bk28M6Ao6AI+AIOAJTCwLMrfj4xvyiqwpz9ldeeSXc dtttWgTmFb///e9107a4THwgxQgNzglv1HLmozYX5Whz6zT/EqcRn9v81ebo3Ct3Lmvp2rw7HZdd L6cMcZ7KOa8ZARgnTgHZvdSEv9k0oiUCkEUaWa+PSueLPJPJDz/8MHz99dfhq6++0q/ZuN+wGDYK bRogXNmwPDRFDxcUy4dNRtMuLihqpazDsJBBOWY9QZhoyoHVGT/yQX5KNRrKjgsy7sh8fecrO9Zd XEN5IF4s1IiP6+xiCcNNI0Bgts3FaKmlllJSh3Bm7gpG5IFFLTmmMbE6sCOMP+EpC/GCKx2GNA3b dHkoA5YOWEtY/OTbBMxZl8/u2fUllliiImXIwlVyJG+tEay/yLdhTxv49NNPFQ/MiIcOHaq7iYIJ bTHPaoK0yQNKDuFpq7QR6hISjw08wJg4scaYV6xHaHNpIQzh2T0xxpG4MXdeYIEFmllvWRwMILQH NgwhDfoGSi1/c530Eb70UE7uxWlYPPGRPmR4kCfaCxjQVsAEYgPLFGuncVg7J++kTzy0Nc7JK9iQ F9os5uml4mDdOcpBfdF3yT91xiL6tEFwJV9gTbmJkz4RCwvn83y6XVNGcM1yqbPwlIE1r8gH4xdt gbwwLlEe2gnX6de4v8WLz1ocdqTs5IX+RzjaCliCKe2CfGO+Tj4pD+NLrYXxjTKagC3WUaXaO89S FsZb6gAcwIR2gjCWYA1l5UpbIelD0X/UA22U8Z+veWBEvhgTsXwlPuqWdtMaifsHbY38UF/0g1oJ mNKnWyvW/xh36TtgTfsAE8gU2ks5dcSmFbwDefewkQT5YtxjvAJn6pp6Alvadt47mvcG70HGAfJC vwNL2qm9CznPG1eoA9oHYwFtnzZDHdP3CG/9MC98a3HMC0f+n3nmGb1NO1h55ZXzHi15Pa5jysjf 5q5bMuCUm+BKmFLjRjnxgCVtxoS/y+nH9jzHOHx8vdJz6hPLVtYCZD7HBwY8QFwcAUfAEXAEHAFH oH0QYB7QlYW54g033KBzGeaGGG784Q9/yC3S7rvvnnsvvsGc2ngU0+HQxfAIa8nbjjk0eo/NzZnj MBc2nR8dFNfrLL2WuR66KHoO6TDnJjzzcebE6EHEg85DXqq+dJlMUmsuMpFMZHFpTJ70J9suJwJy i+mKJVciSm8iE/JENglJrrzyykQmkomAkAiYGpdMrpNddtklEXKvWXxCQiVCoCWyqGUiCmMiICai TGs4UfoSqeBEvqAXfjyz0047NYuHC1LJiVRI8te//jURt7hEKkvzYPkgLrHwSESJSGQSnxkHF4U4 SMRCIBElKxFCLJE1CRNRyrQMlMUw4iiKnT4raycW4hM30ESU1UQUvkTMW5PzzjsvEbeiRJS/QlhR ohJhxRMhCwvh0ieUhzoQl5xk/fXXVywoi5VHGl0iayAlYrmZyKBRFFz86xNZ0DsRBU+xI5+iKBbS pxwxrpyT53//+99F8VTjD8ohC7cX0hbFsVXRyg5CiXw1SGTHoER2201effXVRL4gaL4NE+qEZ2Qj mUQIjsx0aOvyhSKhnmi3hCE87U4U7kQGr0QGLG2X9AP6RZaIcp3IZioJ5RGzZn1eyC4932KLLRIZ GLKC6TUhbRJZjzGhDmVH0eTUU09NxBokkd0aE1HGCnVMnYkipn2nVJul/mXHWMWDurYyUS4h/RLZ wTu56qqrSuaJ+MFFXOISIUEVD8LH2NCmhgwZon0tr3BCviVicaNlkx0mk7feeiu57LLLFFvyFf/E 8kTbbzouUUC1/4ArPzACW/qUbA6TiKKcDlL4WwbqhHhp00ISJOI2mMgiu4mQfQVcyQNlJF9CqhTC pk+E/Ehk04dEXhBFmDIunHjiick///nPZODAgVr3tJn2ENrO6quvXsCRdpTu/1n5EAJF87zOOusk QswWlQc8GFupL8oEhnlC/6GtirustlXC0kbkZV/AV16Sink8LsbxMfYJOaZ5oE3FbZvxgjYmlk06 5tHfxToq4V1RbaFtWH+hbQmZ26okqBPef4xHvGcME470YVnfJLnlllsSmcSUjJ92LS4gWhe8M4RI T66//vpENmYo1Ddx8qM98y5LC/jRpsW9IhH310L5rC8TVj4GJGLhnzCmZgn1IaRjctJJJyXillp4 nxMH4XlXEB68aA+1FnD529/+VsCA915rhfHJMKTuS43TlsaRRx5ZaK+8e2QCaLdafaTNME5aXuRL eIv9WIhhnWNZGJlctzr9OCDvylNOOUXzQr+kf7o4Ao6AI+AIOAKOQG0RQL9n/gzncdppp9U2sRrH Lh4EqnMyRxHDmeTSSy+tOEXmRsxviQMdHR6F+Ql6l81B7R78jHzkzk2DueMLL7yQiHee6pKEs7mw fGRPZBk85XiEHMzUa4V0VL0cXV2WaUmee+655LDDDlP9Mc4LeiBlbWmOn5vRnBtYbtRcWksAytox hQms+HirogCoKEH8aNAAzo9Je1ohlAWnVamHEANgiCk6As9DyHAdEst+xLnttttm4iHWOYm42mgc hCcfKI8oO5AqRiwuv/zyyZNPPpmruKD8yhp1mgf5yp9A5qA0U9mUh2uQixB65BXCUyztCnliUm5l FnZbw5EXSE7KGGMCZnlEFeWh0RvpSDjCQ0ZATlo8NDxIQhQ/E+I844wzlFAFO8KZwk3eKINhakew fVzIxGpLFgFIpyz1iwkByw8EAAQx+Yc0FlNprVPwgbygTqztMGjce++9FrToyGAAMUQ81CkKOhha 3UCOiOWm3uceimeWyFcBbdOkSx541gYECBBIjDxBkbvwwgs1DdoRgxDkI+e0ecgrq1/yidJJe8gS +q6sJaX9iGdp5wy8EJPEQ5zki3xCZmW1N+pIdpUqEA3gSBuBFEFJpv0SB9dRDsUaNisreo0BEtKO vIAjBCZtj3yRF7DiAwHlIz76WlogL2SxWH2W+rC+S5wM+Lwg8oQxhvrkWcLKTuKaDnkAD/C1+MAE Yoa2mBY+Juyzzz4aD3GRd8LT1jiHWF09IuIgf9pDKHucbrkEIGQR5QBz8s+YCJHDeMIYYO2NMvIi y2snkEa0LYuL+oSg5cd4Sz8AX+LN6wN5BCDt8OOPP9YPNRY/EwEI/VpImgCE9Co1LmWRXZCvfOCg /JZn+g79Jh6nGf/BNf0OjMtFXOBPPOB6opDM9AOrM9orP+qPa7LDbRxcz2m3TCKN5KVexSJZ+zL1 Td64Rn/mA16W0IchD6089H/Kw3hAeNLmHh8s3nnnnawoqnqNSRUfJkiT9sV7vrXSVgKQfg7BWqqd ZL2/0vmtFgFYKh/ci+cF6TzY3+RXNglTfMGYOQzvKBdHwBFwBBwBR8ARqB0CMQGI3t7SO72c+UXt cpsfM/mSdf8K8wiMcUoZOeXFFBOAzIN33nlnnXNm6XDMR9EPwCwtzH3uvPPOgvEJeglzYTgh9DjT azlicCBWgukoEuaLEI/Mi5gDQwIy/2Ueir6Drm3zYeK57rrrmsXRlgvt4gIshWuVCKDqniUVr7u9 CImkC2TjRing645yt99+u7oOCfGif7NovYkoFLohhFS4uiJh4on5KCaeArb6jksF2+N6FCWm6G/+ YEcZ1gc666yz9B4uUltttZW6ULHrjCii6taC2ysLibPtNotd81yWSIXqZcrFOj24UEmDCWKJoYtY Um7cAV966SU1/RRlqhAN9whP+fFvxy2QLa6FFFHXoUcffTQ88MADuhOOEJFBlK0gBGMhPCeEFcuP IIqcuoPhgirKlqZPnjFnFYsv3Qqcsh1//PFaVlG6NR7pKLruEeaooixqftgBmLQQITWDWLc1c7EU xV7v1/I/XDOFnFOXxKx0KLuQcQH3aVF2C4+AsSiu+jcmubgfsl4CJsZCYOjfYr2k5rq4i1Fe1n7C 7dVElG/dmchcyXCLZSdJ1nUSwiM88cQTgfYqnV6DGHYWPj4KkaRrNrGRDs9hEsyip5gF0wbiNhGH s3NrYzJwBfqGDHRByO0gBLW6/4lFUaCt0PZwzdpll10yF2d/+eWXdU1FcJUBSMsMJvQfzKZZj+G+ ++7TNiMWukFeNuruZfngKKRLkK8a4e2339a8sxg97Y32JKSE7g7JLtK40dIuqR/anJUhjotyU36E dnrNNdcoPkJaqbu8DJrqnku7Bee4fiweIX10XKA8pCGDuC4WKwNpZpoWzo7WTii/vBy0LbEZwEBZ Mwu3Rlzc6D+YdVPf9GshXiy4HqlLNttAaIfUDX2GuqbfC3EYxGJW7/OflblwoZOdkD/wxK1UXmjq wkmZwZ/lDegTtDnOhSjW5wYPHlzUjoUAC1dccYX2NTBmHQ/6D+M99U6/o42AD/FWggl1y5IFjHls jkC9MwYwVpNGrYX+I9a+uWufMS7RH8hT3O5xAaAvsPQD5eU+67nR1ui7vHNov/SF008/XV0IxCI3 tzjWdhmPLr74YnWfpz9Sb7xfEXAyjOOI7L3BAsy8U2mrjJG0b961vM/o64Rl3IjLYfGQ55NPPlnf LdwXYlPHDMpFfIy7jEeMK/LRQJdHYEzgXq2EsgjRqNEzH7D3XK3SKxUvLtGMhSzzkCW0Y+YcrFHY 0jsgK3wl13BFoW3lCe8W8oF7Simh3dJeyS/5Z4ykXXPNxRFwBBwBR8ARcARqiwDvXpYUKqUfMweH i7ANXGubo8piR1dknmvC0iJt5RSYj8IJoWOIh5LOY9Hr0FXQ4Zgnywd43TwFXGKBTzrwwAN1GRvm OOgzbLbGXBjXXpbbYS7LfBqdQwyHVA+O58WxPsvcDzdisGdeBReFzgPvwHya+ZZ42oWtt946d5O4 OH9lnUujqLlg2dAaF2C+hovCouwoR6yaYsFqCes5KahaAfEVv5RgkQE7y/O4LZaylojjIRwufYTD wgerIqwpYsG9EcsvaQj6HK6eMNZpwQLwuOOO02eITxqAWnfA7Ka/imPBKMRjIhPmQjSUVxqQhodt xiU5FizHVlxxRb0Pi4x7YlqwqjDWWRRpzQ9WELEI4ZRggUn+iGe//fYr+bU/tmaSBTrjqGp6Lkpp kQsw2MDq5/1g9LEsSX85wCoFKz3qhN8a4uYpZENR3qkja4+isCairBbd52uAdFoNjzUhbrHkzwQ3 SRh+S4P6K9f6CFdXLP8IK2sBFFmFWvx2pB2Jcl9IhzLLQFVkPiwEWSKDTOEZvgzh2h0L7uq4R5Im 7RpLwTQmtOfYkvTQQw8tcnulD/D1w9z26SNZroW4qJkFJu64WEtlCSbg3DcMhRhIsHRN1yf989Zb b1XLw6x44mtY/Fi/xW2XL0R5wphhFmrkgfFECPeix2lLWLxyH8ssrEJjwcWPOqRv0V6xlIrTlJeH jjGWJ+LBpbw9hHysHlkelmsBSHvClTHPlRZXSNlQRK3LKA9tJm0FSJ0J+aK4YUGI1VCWYDYvpHNR e46fiy0AWSKBNkgYLKZJmz7MGJkXfxxXW85jC0DS5Qsj/YDxNP3j6x59lLo3oS6EJC60dSxf020N 1wLcemlLpIH7QPy+sLg4gq+NTzxLmvLxKLPOsHCmr8XCe8NcJ2ibuD3E1un2LBa8jCf06VgYC3G/ 56sm6fNOxUI2LViKY4XNM+DF37UUmVQm8pFG0+PLLRaXrZW2WgAyHmCFmff+4p3BeyA9/0jnl7bT Vhdg8pJup/Hf1A9zlHIEd3PeQ1bvzJdcHAFHwBFwBBwBR6B2CJgFIO9e9KW8uQXXeb+j53VGgaNA V6Ic/NBNWyPMjWweSzxY3glRVxSVfMTW5b64jw6XnudgEYj3GXNo5t54DLKUWyzoHXiUocsQDxaL 8DOxsHQdXAL3+ZGvdFosicSckPvwT3lL68TxlnteertbSbGzCJZF++67b1F2sMwSYkqvSaUqE1v0 QOoPnhFg9CrWDEKUpJ5o/idWXVjxYL0kiqNai2CRQXjisx8MMpYN5AmBqS0nfqxkCCckRrPNCtiy W0hQ3ewgnTNpdGppl97ZD4tAWTtOH4eFxnIsLexSiJUbsotYfmGRg0WNlYUj5TjzzDP1awDxPPLI I4XNI9Lx8bc09sJlUU6qtoB4IdIyT6hfmPK8H/VGnXLME1F8wgUXXNBs0wXaINZ8CF8GsHaJhZ2J YPERGUT1Rz2ZYF15zjnnNKtnu1/qSJ2UynOpsFi8YekkA3zhMSEC9GuFuPLpNRb0x0opFqxTsVqi DLRvIcfUki1uJ1jm0C+x+kTYep1NBUz4CkL/wYoWS1MsvGT9saK2RnziSqsWuYQDQyzryhF2qaWu 2CwnFvK15ZZbqnVRfD3rnLbSGsFaSNYMVWvGODzlw6IKwZKXthILFoJYstFW+VokazSq9Zw9Q19k XCOeriK0Jyyk+QpGO2U8AFdrK3ytw8rRxkcsAtPtDTzAC6EPYlEYjyuGBV/9sPSO27Pdyzpimcw4 icU0cdJWrxerMlk7L+vxmlyjD1EmhPP0j3dLuh3SZ+hzCFaijNVYzsbC+0MIzyCTFL3M10y+OLYk pI/VHVao1FlaNtpoo2ZfgcUlWBdK5lmsDM8+++xMi0bycvTRR2vfiOPF8p6xgM1G6DtYEvLV1dqI HckP4xV9mHcolsW1FHDnSytC+2Cc6iihXqzvkK/0j3t8oW4vSbfT+G88AGw+1VJ+aN9YtSPMJ9g8 xsURcAQcAUfAEXAE2g+B9Jwi/pv3e1pfab+clU6J+SGeXQj5tPmEXmjlf8xh0A3w4IqFuTH6I4JO AmcQC56eeGrAdWDZxzxaDFOK5rLM1WQtc523ExaLQaz5SglzYjGSKXoEjzu4IIQ4iada0qldgONC Zrk1oVCheJrUYmJMxZt7EIotO5DKWkvNlDXygEJLZ0LEYqtwrhdy/sPdKK3U5TxadJmys7NeWpho x+6G6YbLhB3ywfKJUgYhSHzpyXxMYHIODqZoptPtLH/jxtaSwojLEq6iecL9NKHEs2A7UNyWZIMQ 7fhxewMfXKYMQ9yDcdVKC/HSZmlH7SWUlTKlhbrE1YxyoJRbm7DncMNDKBPPQKAwAFkZ7Tn6hSnQ mDDTpkwwOTeih8ESklS+MjWLgziNUEVBNILa4sk7sssT5EhHCPWbZSoPcQGuCNikX6jUPab2iFjb ZbYT4mbg50XTVYSy8pKmHqk/+gOKPm2G8YVyU7cIbcIwiMuHmT3jDKb5kOXECca0GbE6K/ziMKXO WQaB5Rvos4TnPYKrbHvsqBznC/KfD0eMH1lCObkHAWXCNYh5BFIqvZSDPQdhhks+7tXgDXHYkjDx wZU4a1zIC0ud2hgBGZk1vsVhGS9joT3Y5IU2wRIEuPxmtQPGEMYEfowhtRTSYGxCaKe0k44SJn9i WVlyTKPu0tjWIr+48tNX8oR648NQOcKE3fJMu7Z2VE5Yf8YRcAQcAUfAEXAEWo8A8xo+whuxlReT LQWTd7+jrjNviDkJm0+0JT8YW4g3ULMo0OGM6yDd9Jya5aUsLxwxWMniUAiLToyg89j8t1mCcoGl 1VgSh7lSLMyVzdWZ+JhHV0uKZ+jVirUG8UBipIEhGRRDkyxFwu619kjlmkUF4GNNImabudZYrPtF PiHeUPzNwiorfZ5D4TWyIOuZUtfySKxYMaPxxIJiFRMSrN+GvzuCIhQLf9PwySeNN8uaMH6+M5xj WYJi2xaBQM1qa3RwwxZcjcwgLdbmiwcJFH6eTwuDMHXeXgQghAJfKLLESBXuUZZ0/zErNe5jlYel GpJuJ1xDgQYzjpCJJoSDFELoG1jrZQ2U3Cd94iD+cgY58g+ZmoUz8dVaGLDzsOUFYmLkgv3NC8H6 JetEUt50e+PFlNe/LZ7OdGRshDCGJOZIG6A/8OMeQv1aW+A83Y7oGxC6suOxtiPWQGTM4UVMn4Fs wCoSQhAShOdbElvHg+fIB2Nf/IGkpfDVus+4gQWxvcjLiZe82lhNWxuYQx6Cj5HgYFqOdRXjAmss liv03fhjEpbQlU7ACM/abwjvVdZRpZ+k24HlycYjPi7QXypNz+Jp6Ug74j3N2nQQU/bBoqVwtbjP eIZVJO+xjhbeYViCVkOoS2vL1Lm112rE7XE4Ao6AI+AIOAKOQD4C6BiyfEib9eP8FGp7hzkrcxKE OSNGAm0V5iJ5ehZzbhPTW+xvjBzsIya6Dt5PprvaM3Zk7mr3YuMYu29HyhYbANh1wtp8EB0m5hns mdYeuwwBCABZij7g1FIgRoz4QgHBhQ3CzpRa0rbK5WjKpSkvpfJWikAoFc7SbM0kGiuRuAHR6MhH rITFmBpZgwWKkV8t5a0j78flaG0+qN8Ygzie+HqcFoOAKY6QNzEBFIcnjHXm+HqtzmmzefVGWaw8 cVksLwxytHOewdyaNpB+zsJbXCj2cbuk7xhRissm/Sfdjy0O0uUeA2beoGx54wj5ljVgxs/U8py8 5tVlXKY0ZpiUGwGYZ4EFKZFXb7UsU2vipnx8FMHcnc0qKBtjCmWgfJQDPCCAKDttysofp8fzuFRD kGJSzzOQ0EaW40ZM+8HUXtYcVUItxjmOy84hHWgj1BVtE2syWX8wnHTSSTUjlCzt+AhGpF+u8Dwf FaztMJ7kuaaCNWOOCYQZk5O8MYjnGBfK6WMWJ8Sd9WOulet+beE5xgQg/Ya6pG6sjDwT16e9SyHn 4vctz1VTrJ0y3tHmqjGxbG3+SB+c88aV1sbbmnDlzGHKjZdyQbAitFX6sosj4Ag4Ao6AI+AItA8C Rlq1T2rVTYX5LIYAJnyUbqu0VofDKMxIQeYy6DnEFUs8l+UehiB5BiOEY87HXDRL4rji+XLWs5Vc 6zIEYAxAJQVs67Oki4KFUHmsbYTbXkuVwH1jq/PygPLTWus/4mwNJqaYW57YCXJeWYesJUFhZHfW aUFagyvWaEZGMciWUljbexBuTXmoZxQ1wvKDmNlF3P5aEtp9PEhbHITDAurwww8vstrNio84YhIx 6xmuQUKkB928Z2t1vTXYMtCTb9pITMbHeQSD9m4ncfqVnGNxBqEGCUi5cHOXDZnUWo9+wTVwYsda 1juF4KN8WQLRzJqkrPH39NNP6w/SDiKPFz4kAoQgabLzeUuuvEwa9t9/f/0wI5u9KEl/vaz/h/Ub 60e2pv6y8l3ta+TLxhPitvaQN0GI8SRcS/2CeCoh8YgzTjtOr9yy8w6xMrEbOfVhbhal4iBcKTKz VNhy7hG3ub3QH20dynLC+jPlIcDHMZswMwepxvo95aXsTzkCjoAj4Ag4Ao5ANRBg7pee/zFfrfVc mrljPF9kTsF8DW+gtkhr8h3rtXhsyOYkLRoUgFmpOXdr8tGWchO2yxCAbS1oa8PTuFhfyVyXmLiW u+5NOWm2pKiVE0clz2D1EVsWofiw1o9L2xCAHDVcsZwwa8B0rHTyclz00uE64m/cU2UHTk2aftCa dkLfISxWNSjybEhiOLW1TEYstTWe9g5PHwQLrGKw1kq/TMkP5F/sSt3eeawkPfL54IMPahDajOx8 pQvZ8pKMBSKvFDFuz/I1jfXuBg0apJsjYTkG6XfTTTcF2Z1WiQTZWVldjVsiANlECZdi8CaM7Awd ZNdX3cBCdmJukUC0PHXEEQs5xgvaB+2BcSPLag9iNLbOY0yPybq8vFfy7sEaDzLXhHbbEvb2rB35 2EU8WDaSNu7QlcZhcVXzSDtl0x7aFm0NK1aX6iHAOBdvDMWHUdq2iyPgCDgCjoAj4Ah0HQRYC9qW 8yDXzFEx+mjJ4KmtJYQARJ+0OTEfalkjfY011mhr1BWHHyjL8fAhk7kNugVL4lQyn644wRoFKLZZ rFEinSXauIJQqLIU73ReIS+obISNEHATKiecBuiE/2F9FLPQdGYacVuFTmmCqWtXxsjKUckR5Ta2 WmOR0Fgpt7hoQ2DeFYQNaiASqEt2wS6HvEmXi75DH0LY3KESN8h0XFPL36zzZRZNrCmaJbxgZbv3 rFud6hptYsiQIQXrHtoML+Q0+WdtqBL3SsYpsGLdks022yywC+1hhx2m5WfMYoOM9PqKaXD4WAOh iBvpSWKlSHzkhXUKTzzxxEK+0+E6w99gaEQJXzrziCneSeZeyThcat3Z1paL9hpbbbGLs1l0lRsn Y6R9waXuLM/lhq/Vc4xPthA07YqFmlsz1tUqf109Xtruyy+/rMUAa/ozk2YXR8ARcAQcAUfAEeg6 CGDtxkYi9tt6663DzTffXPMCMLflg7EtDcO894EHHuiQuRofr82bhY+blc6Faw5WmQl0GAEYE0Zl 5rXNj6HAmDsvFn3lrHEDqWPsLkr5Y489phYkeZlBcYDkqAaplpdGW6+jFJuCftVVVxXt2pqOG2WZ xt1SA2d9KovT1qBKxzU1/w25jHWbYcB23+AQC23jrrvuKvp6Et8vdd4R/QU3PcpFvp966ind2Zr2 kCeQ6mlChu3UjRiFACSeUv2OfkP/mZoVcDaxsHGIL1jgEuPKOVZqbNDT2YW8xkQ3hHFWW6U8WJNC BpSSvLonXl78RtQQRzkfGqz98jyuyeedd56+uGlnWHxBKnbWsZq8227kWP/deeedzfoO+D/yyCO6 ViJlhOA0wp2/qym8B80KECvPUhaq1E36ncEXYtZvRNgciHdpqQ8CjBPcLzVeVKN84MwyGLYuHRaK tu5kNeKvNI6s/lNpHJ3peerw+eef1ywxT+C94uIIOAKOgCPgCDgCXQsBlvBhDTz7xR+ga10SLAB3 3XVX1TGYY7JRYFp/sjwwN0bfSOukdr8tR7yHzJONj5sYcpTSWdGN83SbtuSjrWFrRgBSWAgzflRC PImnYgDE7uMuWQq8thbSwuMaZQoMm2E8+eSTmjcjuDimlUGUqQ033FC3ZybfrGOFEmkNi+f5EZZy 0BiPPPJIVW7iMlseOsNx3333LSiWTMzZmRVrDCs/5aHTUEY6N+VlrcBSgmWHKZ633XZbAF+IgRhb 8Ku1kIa1q1LHWgwK22yzTUHBhdgBVxR3+gJYYBXIBgQttQvrH+TRfnEY7tNf7J4dq40tRBVtH0HZ x5WSwT/dTigbuxuxq+cNN9yglrKWF76UsEYCbYN8Hn/88WoNAiaMAZTLBkfq64477tBnsBCqhaRx I+24XWZhG2NfjTyx/hxEFsQDONAfrb+AJRunHHfccdqOq5FeLeOAmIN0oiwI9YZ1HXVtdYvV35ln nqnXY6zT+WK8wUrv1Vdf1bGUOBiLLB7GKCMSCIt1qX2FS8eV9Td5XHvtyotWHgAAQABJREFUtcPB Bx+slq3ki12L2Sm4VL6y4mqPa0ww9tprL8WWPsfXTkgz63/gA7HKxwbKAnG03XbbFa3BWc187rff fgEXb4Q2esghh+jSGJYfew8yVkAQXnrppUXJYwHIeAIJxLPcv+eeewrvUqtn4uNdSl1j8fnaa68V xVOLP/g4uPHGG2vU9EXaRDliebV3DeWKhTLZPcpEnZUS2mE8N7Kw8ZF4SLerCGQvYwICib/eeut1 lax7Ph0BR8ARcAQcgakCAfSfeC6Rdc78gnlLnthc3+7nffS3+9U84sGIPmmbaaArMJ9nHozuxPyK uRG6BB9xWbv+sssu07+rmQ8+ZDNfxJCD9NgbAi+5LL2WZWVuueWWcOqppyppWs18tDWumvlhoOjj JoQwqY2tBXBlQhHAWooJMxZC55xzjq7D09YClQpPOqxjxmL1pLvnnnuGDTbYIOC2Zmwu51tttVUh GpQqXFZoZCxsT4e54oorlBhba621VAnlGm5wWDcx0UUZIx06G52jswnWDrvIhg6nn356+O6779QK BiZ90003VaKTfOMGBWGFdQkNnAXzSwlkEZ2SeqZT8vwqq6yiLl82QLAeF2RBLYWBgM0mSin0DBQo 1jvuuGNVd1vEsnLddddVF18GIKwr+TIANrj+gjH5w50OJS9PIA1RQLEgZLDlBxFrW4hjoXK9bGSA eyB1hfAMO6NWs71BrkBYYrlFm3744YfDmmuuGajHRRZZRDew4SsQa7tBpkMK0K5w1zQhPxDilIf2 BEG+0UYbaRx8RYGUh1RkTIDcgEBiPQmIjGoLbQJzbdarM+KIuqC92gvPCBbu8zz4kk/acrWwJU3G EwgO6pqPCowlK6+8sn6gYPML8LCXS7VxqHZ8uNjS9mkH5JvdgPlhvUZ94h5APwBP2qm12XQ+eHli kXfNNdco5vQlCCfaOaQMFnBmFQlhwzhWqbUUbsUQruSH8fqDDz4IZ511lhL3fF3sTIKbJIQl69PR RnnHMG5tv/32Actaswp86aWXFFvWB2RyBNFWCyH+vffeO/zxj3/U98btt9+u/RlXEKyfeacyCXr0 0Ue1n5HXWKirVVddNawhLuJ33323jhe77767TqRo+wOF0OX9QZuhH/Kepq0wXtRaaE+4svz973/X cZbxqpzx9MILL1RLUhs/4p3pWKOGSSIfP7jPx8cddtghUOY8eeihh8Imm2xSGJ+ynmMcYrxgQ53O LrwHsXrnfcfknXczRxdHwBFwBBwBR8ARaB8EmJ9deeWV+iE5Tz9mvoXuAx+D3trZhDkkuicfn084 4QQl/Z544gmdIw4ePFjnoRBub731lm4gyBwM3aTawtyc9JmnokPA+zC3YW4OX4ROxIdP9F30fvT3 NLdU7Ty1Jr6aEYAUPLbWiDMHwxx/1YeYo9LSUqly19Lz3MeigLW1WIeNfGBxhFKKcGTx+ZgA5DqV jZKDwnX++ecrmYPlAhYZhDGigA5GGij4pcgCy6cdSaNWkpUG17DmQOHGsg9CiQXyUTIt3ygs/Cgb RIQRJnn5XG655VT5pMNRlxAtYGzpE++yyy5bEwLQ0iBvkHso9y0JHdKUtvSzcXx597KeoYwMChCm WMNBDDMw0N7seXaQxgIGK0mu2fU4HcgOSIl44XTqwUhDMD7jjDOKwpI2hGZa+c+KP06rpXO+dFwv ZOMRRxyhBMSHH36oeaPdEzcvDGsr9BPykU4T5ZoXz6GHHqrWfyj5/G3PUjaLg2vEY32ypfxVcp/+ CbnGLrOxcN0EYsJIJrsGmYXFHnlLS7qsdj/vut1fQ0gQyC5eZFi28RKhTRKOsvOygEiFpEdais/i rcax0rQghk477bSw7bbb6pgCEUh7AS+rV9wrGUMhXylnntAWIMt5qVNX1kZoZ7R/7kOkYG3LCz9L 4vzH5/YsRB/9hw8etEXIa77O8aWQsbuakpV+JfHjNstYAPEG2Q4JyOQMXAwT0uDjC4QQZHWpNEvd aylfhCUfjGu0XT4eMdFinLe+QX3TnyB5st4Z4MtHBdo470/ewXwdhUzkGvVLuYiDv5kbcKy1UDYm ivRzPlzy9Zj3CMR/KeFDGdbeNjbHz/I1mo8eJhCBEKClhLGA93ApAWtbB6fUc/G9ttR7HE+l58wF 2HgHYZyAZHVxBBwBR8ARcAQcgfZFAN0SI5RSwryNeUiedNRcwvKDsRb8BXolnlIYyvCxmI/PzI1i fZL5ZtacvhplYM6NBxE6HDoPejnzYvJA/Mxj+TEn5hr5yJrLWl7saOWMj3aPo53H91t7XjMCkIXI qaByBGUhq5KIA+sPlAFzL03HB7C2UHo5i5/DzkK+QNDA3lJpKCE0GionTaBYeiiwWDKtttpqqjxC mJEvKpcKIR/8iB/rRiwLITLSwrMoNeSZtDivRGCWCUtebR2xdHg6sGGSVx7wRknHygbSCkIWQpDy IMTNMyy6iUVCbNWVTo+/KTuWIRBcN954oypQZpZr9219vKzwbblGvFbecuMB97gjUV7ioMOCcZaA ubVJnjF38vhZBqdzzz1XLXSwfID8wwoCV9iVVlpJtwtnwEBIPystsKTe8uouTs/OqSsrT9zG6Dfx pi/2PEfyTx/FaoX2TbppoczUP+QtmyZA4NBOaPtgRVsjHPFgHbjbbrsV1tKK44IgJizkBVY2EC/W fwjPjzqh/Wy++eb6lScOb+fUk/UB0iR/5Qq40FYqwZW4GZ8MW/6mnWARSfpZ4xbPgLm1yax2T3kh zFCKsXhjHQksPLGIZIxBUcaiEiHtvDrUB6r4H/myNk60tJ+47FlJUQd8/YLIOemkk9SCi7q18JAV kFPslA0hAoEENum6Iy36BoQcBIy1MdoZOHOf8Wj//ffXNkJes8Swh4jPsjaiPLRnSEAmEAjjOf0V krJaQp5pI/T/Um2lVHqUEWuv+++/PxxzzDGKjfUbykH5sBCkbzK+pDFNxw3uvO9amx/KZO8NrPx5 b4CzvTdo6+APjjvvvHM6ef2bjwqMAUyesJLGApgy8SP/lJl0+ALN2JNH9GZG3oaL9EWs8yD0IDWx XIUQzHqPWzLWV1py7eV5xlvzNLDwHBn3IHoZV8sR8tPSXAccGdPjMailfsx9+piFIXxbhPrEapy+ zLhNO8ZS1MURcAQcAUfAEXAEao8ABie805lHlyO8q/nlielfdp/5SKU8hoVt7ZG5FO69Cy20kOrb eMEwr7V5KHNI5sYYdPGhP62DMf8FE45ZH6rJF2nYXCgd3vKN5woeLxgQ2FI85IGf6cbM1dYQgw/0 Wgw7YuEZm6eBa95cE3zJC/PHrDlkHGcl53VCfNV+YbZKctRFnoXAYGKLuxINBTYYlzQqqSUlrDMW Ecs5rJBw4aNJoAzx62xucZ0Ru1J5Qjk2IoJ2wcCAUgnhw+CDlQnkYFcRLF2w4MLyBRIMwgqXXX55 g2RW2SC3ULIh4OkzhMc9vJqDW1a6nfUaL2fGFNoEAmnEGpIQVBAqrL941FFHddbsF/JFW2dcxFKU MvGChPirRAiHVTJx8HUPYgSCZKC4iNJOSk1OKkmnKz4LWY91/RCxBKRdsNQE43RHCe8NxgL6MuMb BC0/8lauYElIm8HCkYkO68kSBxOnlkirctMo9znygIs4hCvYXn755S1a7ZUb97T2HB4TkH5YiUL8 YVld6yVApjWMvbyOgCPgCDgCjsC0jAD6EnNI+Av0UIwOIAcrmYe2FT/0Ftx+yQNzH/Qe9BU4FD6s dkZxArAz1ornqcsigNUDBCpMflp55TqKO256uEahDNmA1WUL7BlvNQKQJ5BZWR8MIEghItipFoLn 7LPPrsm6iK3OvAd0BKZSBCD/sGTGqg+XZyxFXSpDgMkwYxc79vFRB6tdPChcHAFHwBFwBBwBR8AR cAQ6FoHmPqodmx9P3RHo0ghgDQPJB/PPFwCUH9zZsJxjbTNcYCH/MFHG3bUSq7kuDYxnvhkCuMzi vokFJJZPmINjIYqLLJsQoEAjWL4NGjSoWXi/4Ag4AtVHAKtV3JOxBrRdj6ufytQfI+Ma5Cljm+2w PPWX2kvoCDgCjoAj4Ag4Ao5A50bALQA7d/147roYAn/96191t2hMftmRk906cQ/Hzc12McXiC+s/ FsFnp1SXaRMB1qjAYpQds3ELhzRmHQs2v7j66qvVghSXYNboxILGxRFwBBwBR8ARcAQcAUfAEXAE HAFHwBFoLQJOALYWOQ/nCGQgAMl39NFH6zp5uEEhuP7iDswP12A2isG1DDczl2kXAdaoYM0I2glt JG4nRhKzGQjtaVpdG3HabR1eckfAEXAEHAFHwBFwBBwBR8ARcASqi4C7AFcXT49tGkeAHS632GIL 3e2UBftZnBT3XzaKYUFSNs04+OCDdR3AaRyqab74rI/FZjAsGMtGF7QTCGJ2Kcbyb6utttK2NM0D 5QA4Ao6AI+AIOAKOgCPgCDgCjoAj4Ai0GQG3AGwzhB6BI9AcAdZyw7pr6NCh6tbJekjsBoTbp4sj ECPw+eefq4s4a0OyXhZr/s0444zxI37uCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgCLQJAScA2wSfB3YE HAFHwBFwBBwBR8ARcAQcAUfAEXAEHAFHwBFwBDo3AvWdO3ueO0fAEXAEHAFHwBFwBBwBR8ARcAQc AUfAEXAEHAFHwBFoCwJOALYFPQ/rCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Ah0cgR8E5BO XkGevckIsEOqCbvpujgCjoAj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4AiUh0BNCEDImkmTJjXLAcSN /Zrd9AuOQITA2LFjdQfdCRMm6A6pHGlXPXr0CLPMMktoaGiInp42Ttkllh841NfX646xTU1N00bh vZRdDgHa6bhx4wJ9l3GfNtutWzc9tlQY2jkb6fBD2B2ZX6X9nrSJg2Nb4iEs8Vi+KAt5oTwujoAj 4Ag4Ao6AI+AIOAKOQGdFwObTWfkzboZjZxTLu+kS5eQRHgo9BKlUdygn/q7+TE0IwG+//TbwM+AN JCqub9++oWfPnqrMcYTQcelYBFBqjbBFoe3oAQDS4JFHHgn33Xdf+Oyzz8Lo0aMLRMA888wTzj// /NC/f/+OBa2dUoe4GD58uO4k/PHHH4f//e9/Soz269cvzDbbbGHJJZcMvXr1CtNNN1075ciTiREw Uog+0xqCKo5rajlnPGFH459++im8/vrr4csvv1Rs2Al78cUX13bLbseQaLHQ1unrY8aMCe+99174 5ptvdHdk3iO0dfr+QNkhmZ20WyLerN/QX9hl+euvv9ZxjXjmmmuuMN988+mOy9RZS0L/I1/s6v3f //5X89SnTx/9ELH00kvrO837X0so+n1HwBFwBBwBR8ARcAQcgfZGgHk189csYY6NMcmss84aZpxx xqxHOvQaBkHvvPNOwYhg9tln13l3qUwNGzYsfPHFFwWjmUUXXTR07969VJBp7l7L2k8rILnlllvC jTfeWCCVLAqUZBQ3lCeUsHXXXTestdZaZStiFo8fq4vAiy++qIQtJOB6662n9VHdFMqPjTw899xz 4YgjjggffvihksgxKfnVV18FBoNpQSAxXnrppfDnP/85vP/++0qo/PDDD2rNBHkO6TD33HOHDTfc MOyzzz5KskwLuHSWMlI/EExvvvmmkrC8YOaff/7Okr0OyQeTjGeffTZcccUVSvzxIWjEiBH69Y2P PZCAa665Zjj88MObTTTAEdL/6aefDvTzkSNHKvHG5ATSj/fGIossEnbdddew4oor5pLeEJAvv/xy uPbaa8Nrr72mZCRx8f6hz/ARarnllgu77757WGqppXTikwUW6TKJuPzyy8O///3v8P3334cff/xR CXjGJOKCUNxpp53CLrvskhWFX3MEHAFHwBFwBBwBR8ARcAQ6DAHIvz322CM3febYe+65Z9huu+1y n+moG9999104+OCDVR9Aj9h6663D73//+1yrPniEG264Idx6661qUECYm2++WefrHVWGzphuTQjA jz76KLzwwgtaXqw8jHVFoUJp5ocChZUXBOABBxwQ/u///q8z4jNN5AkF1+oLEmOxxRbrsHJjqfPX v/5VLYBoN7QLrNwYnOjUc845p553WAbbKWFIjP/85z9KhELQ0mfAgx9EBqQK1pFvvfVW+OCDD5TM KMeaqZ2yP00kAxF9//33h8suu0xJJcaxaZkAhPy76667wimnnBLefvttbacQ1XxZZOyHPOPdwHN7 7bVXMwIQy14IQJ7DXJ+2TpumvWNNiBUefQJSj5d/FulNOhCQRx99dHjllVf06x/WhsSFYM1npC2k +oknnhhWW201TSNutMTD18Mzzzwz3HTTTQHinbxYnkaNGqWWgFgqDhSrRCcAY/T83BFwBBwBR8AR cAQcAUegMyDAx+w33nijKCvMc9E1OfJB+9e//nXR/c7yB/o/H///9Kc/KQ9Antdff/2w4IILZmZx yJAhSgBiCID+gNEA5XMpRqAmBCCKEgochA2mmmuvvba6cKIwo1RBWNAYUQb5G7n00ksLSlpxFv2v WiPwySefqLUd6aBkd6TgrocFIIKl0B/+8IewwAILFKzbaFsMBlOzMBhDdPDFAzKDvoSl3yqrrBJ+ 9atfqQs97ojPPPOMEoBDhw5t5m4/NePTWcrG+MaXKVyzaZPUw7QquEI/9NBD4cgjj1RXWfop1nFY FNN/adO8lPnoE1v0xnjxXoDYxgUBF13If9x+cXHHlRiyFXIQVwA+WvBe4YNFLLxXTjvttPD888/r ZVwa9t57b7X0Iw9Y1DKJwJoPqz5IxyWWWKLZkgIQjpCD//jHP9Tij/rFWpAfecPFmS+qjz/+eDNX 5jg/fu4IOAKOgCPgCDgCjoAj4Ah0FALMhfEWgxBDOOIZg4EJ82rm5czbO6PgtbPffvup/oC+hT6A hd8JJ5zQzIMHYxm85tATEIyGDjvssA71bOyMmJKnmtY21n8ocWeccYaSgShgWH9A/F1yySXhwQcf VHfOO+64Qy2YcOtyaR0CYGsdu9IYsNAhLHGk1+WqNK62Po9iDQmIQHjRJhiYOpO0BetyygH5gOmy kX+sm3byySeHQYMGqaUZhCBELVZJDzzwQLjzzjtbXffl5Kfaz+Thl3e92ulXKz76jPUX++jR1ri7 GgZWXlx9IdYgpsECF9vjjz8+LLPMMkrg8RxtFqs9nmUNy7RgqYc13s477xxWWGEFdfmF/ANjiD3I xGOOOUbHB8g3XIX5KhiPexB/TA4QxjUIPiY9TCCQ1VdfXb8akg+zssX6Of3lE7KRH5Z+5GvfffdV V19cmLFqZJJhVrisWeriCDgCjoAj4Ag4Ao6AI+AIdDYEMCK56KKLiubLGGAdeOCB+mG8s+U3zg9z /IUXXjjsv//+6t2DLnHPPfeETTbZJCy//PLxozr/xxOJuTs6AOXDMyvWE4oCdOI/aq0P1pQABFcU OCxBYqEy8MlGWcQkFcsZSMFSBCDEIZWOsoXihlC5uGShoEGKtCS2ppQpbBBLtpYaCiZWLCibKItx Y+E6xBQWP4TBGiS+b+nyjOUNBdfIAbsfH1EeKRPP80Np5kfcYNaS0DBscXryR9nAFBzAhXLxS+NC GQhHmlYGlFkT8pS2ZKIcrL+VjsvCtOVIndr6XMRDPYANQprk1YQygxHX87C1+CgTP54jDO0EE2DO WxLyYJhYPVK3DChcp/2ArbU98K6WUEa+XGB5hDBo//GPf1QSIyZCSR9LKdYxYxAkL3lCvvlR59bG rY2AibWDdHgIRvJDuhyt/9DfqAOuQ1bSZgwT8hRjDJaky7PUBXHwI13ioa2DrcUdX0/nx/4mPp4n TeqDvyk/ZSLOGCcLw9H6MUeeoa+Rd8OGuIiDfpQeAyyeuI/Tl6ydgA/5ifsO1+gz5CnGxOLiyDOl +jF5AaOW+h4Y0G/IkwnhaCe1FtLEFf1f//qXJoVV3rnnnqvjeZxv2gw7eINZfN3yB1lnz6TbM3W1 xRZbqPsuLsbUIW7GtL+YTMRyljpFsOyD2DPyj2tsHsTasywr8Oqrr2rbI+8xAUh4SHWsO+kbuBtj jcsX1FhmmGEG/bpIvbs4Ao6AI+AIOAKOgCPgCDgCnQ0B5tTok7Ggk7WHjhCn2dpz8v+b3/xGlxl6 8sknw7vvvhuuv/569coxfQEvUwwRWN4HwRBhyy23bKYTmo6PHpLHJzCvN/4hT69E74JzQGcwXRR9 CEzRJckXukueoMegtxEPOiK6Cumik1IW9Fz0OPRV9I0svSkv7nKut8yGlBNLiWdQcNOCUoVV06qr rlrwSYcMpOBZyjtK3sMPP6w/Kj3e0RGXSBZhJ768hkyFoMyxltMTTzyhSiTXWOtujTXW0PCnnnqq WlRRWVgsAroJa62dd955uisl6aEQUhlpufDCC9UtjMqEaU8rjDxPhWMBA8Hz1FNPqfsgpALlxl16 2223VUIHS5O8yiZ+8oSZ66OPPqqkA9fozBAGdHIsXVBq02srQuqgnLMOFg2OMBBOVk9Y7cQ77IIT 5WBNrTnmmCNd5Db9TQOnXq+77jrNN3mhHZAmQvnAyAgqsMP9DrfgWOnnWfJPO0FxZx0xzIT5mzKC 67LLLqsEAgMCHbOUnHXWWeoSTZ1wTse+5pprNF4GDtKifRAnBBxWS9US2gKWR2YFucEGG4SVV145 s1+QJvkYKGuQZQk44ur4z3/+U61twZb4KT9umbSRbbbZRvFJE1SUmTqnvLQh2heWugxWfImhD2Dd Rb9hMGYAJB+0LZ63tgupg0UWhAuDKF9t+OpkmycwONO3sGQkLa7vtttuYfvtt9c2kS4XAzIWW/fe e6+OHcRFXiEeWQ+CsQC8SCstPEt+2V2WdkA6YE0bpA9QBgZgLE8hfCgPbdKEdCgPz9ImwQQSCmHA /vvf/65ltfbLkX6M+XnW2oDERz++Xl5i9GPGqLgfs1ESdbTRRhs168eWJztiEccyCrR56y+bb765 vvzsmVodqTfGM16EtC3GdT7mWBtIp5tua3Yfwq6U0NZpcya0Z8objwW0dyPk6Pc2MbAwHHlP4BYA AcgYRByx4NYLkch4M/PMM4etttoqcyy3MFnvLLvnR0fAEXAEHAFHwBFwBBwBR6AzIcAc13T/zpSv vLygk+EKzFI+6BsYHfCzD/gs68Pf6ADM8w899FCd65tORLyU+ZxzzglDZEkidAeW+hkwYECzJNFb 0WfR4w455JCw0korFT0DOYeXHvoCnkfwUugTCPGiY2OduOOOO6p+mqUPoYvCFbGWON5MbI6IZxP6 MPoJfA1GMejP6ONwVnn6U1Hmyv1DKr/qIoVIpLD6E6uNzPiFSEjEfxt2UH9SuEQUyWbPClmWyOL6 iViOJKLMJVL4RABJpHITUc71KKAksnFEIg2iWXguyNpSiShxiTC9iSioGgfhRXHTa7LjbCLKosYv BEQiVjxF8UhFJFznebEeSb788sui+/aHNBCNg+eEqLTLhaMo/Ik0FI2DvFAWykR5hLjT8gixmPzu d7/T8NJQC2HjEyFcEiFhEiErFTvKIoSHxkPa4EL8QtLEwfRc1vtLRDnX9EShTvhJ5yjUA/mx6xyJ WxpmIlYyzeJq6wXagCyyX5QX8m9tgrqK8wJGQrolskNos6S5JjscJdLxiuqY8oAH8QjBkICdDA7N wscXxNVW6xpMxZQ4ERKmgDV1xo88ErcQtklePcVxlnsuXy4SIVA0fvItOxe1Kn7yJCRvIgRfIqSW 5pl8U5/km/5JGxGCMRFCLaFtxkJfos9RH+DAs7RT8kRYIbSSTTfdVHHlOnFzT4i7RMjXQlRgRz3S VskHzxKeNidEcyK7Oek1rvMc1xdaaKFESNxCHHYi61Qkp59+eiIksJaDeKx9kD55Jc9C8iW0rbTI 5hGJkNmaVyH5ErGs1PZCuwIX4qNeOSffQjAVRSGDeyLrUhbS5DlrC4RLt1fuzzvvvImssVEUj/0h L4+EsSuvH5MfsJeduSxI7lHW1kuEoFcMwIGfkPm5z1fzBmMK4xEYUDdCZmqbpQ6E1NSfkGy543Ml eZEd5jUd0hKyNxFStyi4fITRdsZ9xjkhvIvu84eQ63qPZ4Q4TmQ5iqJnZA3BQp0wplAG6p73E+8j IRk1Xq65OAKOgCPgCDgCjoAj4Ag4Al0JAebupm+iO19wwQWdPvvwL0Kqqa6I/oUOLoYTiRhhqL5r Ohm6qJByzcrDvF3W8lY9WNYYV36o2UNyQZbhUj0KvU6MO5o9IgZKiRCSBb0YnQt9FH0OHZu/0Zs3 3njjRMjEZjo2EcKrwGmQZzFuSISMVN2aeNAfSRs9hbjEyE119WYZacOFmlsASuYzBUserF9MsJQR EsD+1CMMKxZWLByPdQ6sKouwY+3H3zCkmHpiFXjSSSepNRRWL7FgnYLFGD7hsMLEgaWJKOZqBYf7 F+sRSqNQJtyOcRwwwFwnPBY6gnd8u3DOfZ7LEsLA8rJ9NZZIMNJYl7CuG6w27DHlwRX6tttu0/tC djQz2SV+fNoptxAEGpadlLF2Aa8PP/ywsDEEVklpkYYV1hCrRyxgCC8NT63DzHUR66eYDSffuO1h GVVtIW3cBbFykw6j+WFDEja3QLAkg0U3oR6oN6wcY6EtYLnI7sHUgXRADUvc1D+4Yi2EtRZt4eKL Ly6yJIrj4pw6Jh4stHC/xRqIOLHIoq7AzSwMheRIB2/T39Qh7QOhfZCeEGsVx0l9Uta7775by0P9 0XewkuMelpV8XcDyjC8pV111lVr2xQmBgf34koFVF5Z3tFF+WCkKWadWanwBYdfVxx57TLEh3whY 2o9nqWu+cLCTK/nAYpNy0m9ZDoAvOLQBrPLsqw7xkEcWfMVaFIyEGNOvIVjk0nbefPNNtb7ji8rZ Z5+t9UU/oZ/FYvXKwrfUK7jwZYc80D4YD+g35JGyYiVI/Aj1sLpY5DFWES/lIgx9kbbMFxzaLO0G oe/Ql7BOTAv9mF2DsSYkXqx22dQCK1vSpx9TJjCifbck9A2rK3vW8mF/1+oIDtZmKS/jM3mnjTF2 01/ox9QV1oFYFINXpUK9m8UlYUkntlbmGhsHMZ5bv2dDIerXxgzaEXVPW6UOGQexGI2FsZi0ENYi BEe+KtI2abfUP/2IPjF48OBMa/A4Pj93BBwBR8ARcAQcAUfAEXAEHIHWIwAfAS/EpoN4U6KroTuy iSDcAfN19AK81JirZwm6EjoYvzw+B0tBnkM4Twu6P95D6IfwL3jGsWkhf8Nt4RmHRxJ7XbDJCror OnAs6G3klx86ExwR4eGF8BpDr8LjjXTQM/FAu/HGG1WniuNp9bkUvuqSZQEoBU34CaBqSSHuhGoB JBlXdhNLq1h49oorrig8Iwp6Ir7dGhamVxS0REBOZDH3guUQ1nlYacQiO8UkouQpi4o1jeweqRYd hMc6RDZXUAaXfPDDKgkLj1hkK+lCPoQ8a2Z1Ys9iOWbxpC0AyZc0Wr0vCnGCtaC4I6ulEuXBWkaU 0kRMPZXZhvnFqlEahkWvR1FEC9YpsNeiECsWQhKohY0Qq4mQM4m4VSbiElgUlj/AFesu0uMHDlhD iTKseZPOVLhnz5C/alq5xZmiPVg65AWLN8NQiLrCPXuGvFOGWLDswoqLcDDuxx57rNYt8RFOSIBE iBstI9gLQZSAV54svfTSBTx4Hssq6XgJVky0GX60PawXaevVxAb8Yf8pC1Z2rbG8JD9CoBW+Hggp o3kl34aJuDQntB/SoYxCABZZRoIz1lHcxzpPBibFMq4fIUQTIcn0ywv9ly8ftCO+jJjQzomDn7j/ 6rNY1PJ1g2vUG/2aNkY9YiXIdSHDiuqZrzHgwT36MdbDWHIRjh9lE3NtvcczQqg1s+Ajfvo39/kx LoATfQZchBBNZLt4/XrDffKO9Vcscd8RslHrn2ex3MU60fC19prXd4RMKpSV9iWDv4a1fkz4j8WS ki9yWLW1JPIyTBgjrWwchQBuKVhV7jMG2fghhJiOW+BsFpJC9immtGvZyCORl7R+saskcfo846MQ clpGxkcht5tFwXhJ25AXv+aJNkq7YKwVcjqR9QPVmhtrVaxF+Ts9xmKBbTjST2TdEW1X8mLWvkLa nDPWyOYguRbhzTLnFxwBR8ARcAQcAUfAEXAEHIEORqArWgACGXwK1nLMxdE9xNhDvbM4R9/A+ynN BRnUQvqp5xVzfDw78ZTLElnWqKAHwMWk5S9/+UuChytHPIPQI9H30BE5x8MLPod00BXQNdIixKVa I5q+gQ599dVXqxcquiTxoP9RJp5BV4TfqZbAflZdYgIQhU+sWRJhL1XJRVFFQUMxo0AoUuuss44q 83FGxPJFTSOpUAgKyMAs0gY3PbHg0LhQ6IRlLUQDEYKLoSmn4sfdTKGHgBJLo8IztSAAUV5Req0S ITIgetLEEc9BeqG8gg3YDRkypFAeTiBqIE0ok+xu2SwOe1iscspWso0cI02U7I4UsQjTspOXK6+8 ssWsgOHee++tYcCEtkSdxgKuwsInEGHEi6ktJrl5EhOAEFKQXuCZFtJhMKmmyJp0hfIzeHwsJFCl AlEpFnUaD0THdttt1wwTynPkkUcq+Q4mEDfxwBITgLRXMEQYLK0/gZMRZLQbzKqJC7LUnjcCEDLI 4ucefZVnwdcGYPnaoaQb12P3TfJKeUiX8pBvSzfGhufMNJxx5UR5QcQSE4D0RVlLoln/wUUfN1by AAGa5+5PvJCOkGw8CwEI0VSuQHoa0cuHizQJZfFQpnR7tnvxESKTZQwol/0gwttDHn/8ccUAHHjR ibWftiteVrhz4wYNPtQdP67R/6yNlJNHPspQ74SnHdA+0i7aFg94yTquhXEU83naAz8mDOQTV3Da aRpb8iSb6hTKI5Z+Sv6Rf7Fq1bxDLlvdEScEIS9+F0fAEXAEHAFHwBFwBBwBR6CzI9BVCUBwhTwT Lxydq6PzoBswtxdPo5KGM9UiANHN4KTydDfSwQCNPPHDFTgtaQJQ1ixUQ5T4OYhAlmEjDvgpdL1q SeV+WJKLckXIGXUBi80eJeOF4Ljj4rKVtcEE7mOifKt5JiafQiToIvlxeCKSSlBXQUw/MZPEFNQE 9zncCQkjil8QQq3IvZXnuC4WH+pyKBVpQat6JF7MVTkKmalur7j8WfnixNicgHtCcKhJqLDY8W11 fRQFWMuEa6sQROqiKwRLwVWU+9IhisJNrX9QtyzEieCmy6YW1Gks4IG7ILt/shEMbpeY5rYkhGPT ATYB4Dwt6XTS91vzN23YBLdFfpWKDDzq5kg4XFt/+9vfNsOE9iEEsroIY3aMO2y6rVm6uGxa+Skz rvpioaZ5w+UTESKk4CYuA5aaTnPNBFNsa5PEhVss7rqcs/EHQt8wd1nGDtLA1Rdzaja5oK6FYFK3 SyEoi5YQIDxxybqEuhkHfQ1XzzwR68ew/vrrF/qMPSekpqbB37hIM77UQiiHvLA0aiEm1eUXM/LW 9mNwwyWVdm3xsmFOrQWcMcM3EVJU656+dtxxx6kpO+2BTXRY7Ba3ceqSfog7P/XbklDXbEAj1pC6 IC/vAzaJwSU/S+SrmW4WhEs2dSiknrZV2g99gzaMuf5AcVPnWWtzxCWEoLqbW7xCTqsbgXzU0g1m aMe4CLM8g3z5U1dhIUB1fN9ss80smB8dAUfAEXAEHAFHwBFwBBwBR6DKCKDTiweoLguEjoHIh3ld Io35fa0FfZYf+oXpPegP6EQmQtjZqeoaQhjm6vTor2yKCS8WixgwqB6Fnk7c6B/VkpqzRCj1KLUI 4KBQo4hRKHa3lAXXm61zx7NiLVRQxFAw2fkFxY2wJnaOfzWCckc4EwgEfggKvxENdt+OrEtFRcYV Z/eqcYTMQOlFOIewksXlC1hYGlYeSD1ENrZotkMl6xeKNYquC4ayzw4z7HzK+lo0HMgZyAWORgRY /FPjkTqDIEIgnCCKswQijJ10IB7ohHlkVxyWNiEmvgXyK75Xq/OYVKSt8KtU6Ge0HYS2wnoCWcKa gODCwALJYn0l/SyDqgltiv7Ms3H7Aiv6NMJgTL3EBCBxMMCZ2JjA30Zyct/OKYPlB1LUiFEIG9Zl hLSJsbG+wxjAgMzfrA2aJ6z9B9GeFvIc59teLOnn2vo3Ly/yQPyQVPRhfhDOlK3SfsyO1JBk7S3U mdU7afM37Q2yTyxHNTuMR+yELFZyuj4j9XrttdcG2dykRQKQvspOzcccc4yOl8S18847B7H6zSwq 7YO02b2L9CALwZq80C4Yh1lLw9bzI1/s8BUTkbyzTGjXEJnk1dqsWDaGyy67TNcVZZ1I6pAdmJ0A NNT86Ag4Ao6AI+AIOAKOgCPgCFQfAfRPDMgw5Lj99ts1AYy82BOBeXutBR0TIzPW6WMt/SFDhqje jfEWuim6UKw/on+UIgDRB2NjhDj/6DEIcaAvVktqjhLKEkQfxB8WP5BbkBMAh8JKwdisIGZKKRzP QUogAImFEsc8ATwqJH4GVtZIBMgxIxfScWDVUUshXyxQaYJiyuL0eUIZKA+NiAYTCyQWpJT4p+vC kmy+YHFhaQkRSKdgMw+U3rwyx3F25XPq2Mg8Or11lHSZICliZh1SOd1e4jDcgwgYKFZC7Sm0RdKl 7hk8aCuVCngYOQahmO5bFh9kipEaXKN/ZmESE2K0TSN8YgKQcyMv6euWvqVFHPHzFgfxGeESx8FA Z9Z3MQHIM5A4cVyWhh0pF+UgPxCRWS8Dyg05miWWH+7V6qMA27ljrcrGNQzobGvPYq8IG0xgiciL jI8Tnbkfg5VZgZJ3cGX8MfKPayaMW7KLr260wkvS+q3dTx8hgZ944omA9R3PQ9Jhrc37wtpaOozs Hq2bgNBv6O/iBq5fCe29AEHMJkBY8NGuZGkJ3aCEeBHaadwn6P9MKuJrluZee+2lG8XQ1tm0hWPc duw5PzoCjoAj4Ag4Ao6AI+AIOAKOQHUQwIiDTfyMAJTlzHINvaqT4i+x4MGJIYAs51TwvELX5Gf6 KXqsCTppKTHdP/1MrHMTh+nF6eda83dNCUCUIXZRBCQTXHJlkwC9hgWb+EirK5gspl5E3qEcmvKN OSeKcEvKFcBgIWcCeYbChxjhYPfiIyQZ99NkW/xMW85pBGalSFqQcxAAcePIih8CFAI1LexyClPM 7jIoxli9QIShhEKOyJp1uuPrWWedpW6v1hjT8UwNf6PE00GMuIqt1dLli8lQMINgiMmt9PP8nYV/ 1nPVumbEFAQ59V8pARi3NfJE3eManSX0p5gco8/Rh9J9Jd1+jEyxI3FzHv+dTi99Lx2nPZ91nT5s HwMY8BnkKVNLAypEYDrdOJ08EsmeqfUREgqiHws3CGnrx1gx43oqG5/oeHbOOecoCZWFTa3zWE78 8VcrzvlIkSWQgrGlHZa7WKFmlYt2yIcNyD++rGERKWvtKaGXR9ySJjttmbUoO0tD0sVtgP6O9SA7 bkG+Yk4Pzttuu20hHzHZR/5oR1nCjs8mvDsYi3GXd3EEHAFHwBFwBBwBR8ARcAQ6KwJpHSqeK5fK c2vDlYqzGvfS+WpLnKXiYr6P96ps2KE8DkY2LGkEXwCRh76CoBOway9CfGnDGL0x5T/00SxdKH6m 2uc1JQDJbLrAuOIefPDBagEoO/IqQLhlYoERW2ihSEFEoPhD/kEilts4DSQUOSN9zDXQ7sVHSBYj CuPr8bmlTSXmNYx0WS08YXE/hqAjPzvssIO6sdn9So+US3YvDgcccECQXYF13UMUWtbXQllGAZZF 9vUZCNH2JrEqLU9bnqfjQWRBfPHDmiqrvNyDYDGBqEgTXXbPjtSbtR+7VusjdctacBCAkLocKxEG kNiiFRKd9hD3LYuPe5CgJlhydTQpZnmJj5B9EEeUA3IJ4mxqIFogo2RDpLD//vsX+jFrmNKPsYCm vLILtJJelDurXRtOjEm08Xhsoi20xwuFNsMP0o4jpGaWUN64z/EBiDYYXyMc12RTmXDUUUfp+h70 Ccz8cf0uVe+8lMHOMGDtSxu34/wYmQgBiGD5CtZGZMZ9BbIxJsnjeGIikjQpT6n8xWH93BFwBBwB R8ARcAQcAUfAEegIBJi3mg6IrtCSkRV5ZK7MHD0W5tTM07uKmF5E+U1fSOc9Xcb4PnrZbbfdpvwW egBcDOsRsqRWLDxnBGB8vbOcT16Fvp1zA2C77rprGDjFvRKlV3bFLaoIFrC3BoUyDBlSqWC5YdZP WHqYFVE6Hny4SwmdwpRUGkWWpSCuxnkkIuFtUUo6W7xOYal0W7oHYYMbIUz03XffrZaVLI5vCizp yI4xLUVTpCRDInQlgWwwRZy6sfUA02WgzmzxTEgBSLIsciAdLm9wSD9Xrb+pO9s0h4EWIjevXeWl CR5GXBopkvUsrvhGioIF5EU5mGTFVctrcR1D8FRKitYyb4YX7aS1fQfiiY1mZJv4cNddd+nmEqzt af0YUh9r31LC+MM4ysZAbCrCz9aBLBWuGvcg9uacc06NChIwz7WXsc8mGzzM+JWecPARhZcm6+7h Ek3cuBSDDV/YSgkEXPwRhn5g9ROHI83Yqo/+Fa+rwdhg7x4st/MmAmbVTdxMKPJc7eO0/dwRcAQc AUfAEXAEHAFHwBGoJQLxfDgrHebrNvdlrm26dNazdo3lxzDIsh+GXC+//LLd7hJHyoqgt2V52aHL Yb2XJ4888kiBB8Ij7fjjj29G/hGH7f2QF09HX+8QApBCs87VbrvtpgogJMQ999xTtDMrJIi5c6IQ Zu2YG4MH2ChqMWGD1ZBZo6AMf/rpp5lKOjsOl1LesWqxjoGindUwsMAzMiXOF+coh1jioYyiAKOk t0RoUpaszks+s66TDu5qWAauuOKK/KmEZ7xDp17M+C/eoCFPec8I1mku2W6nkF1PPvlkZl1C8kKm IZDC1i46TSGmZIQvCOzOa23/gQceUMvRuF3HeaYtpAlpCA4sbRHqk01n0uH5m3ZopCh9xdKM4+8M 5xArRq4METIMYjuvD5BfypYeC2pRDnA2ooj0bL3RctIq1Y8ZK+jHtqENHy6yxpw4HcZINrPYfffd dVxlbG2vTUH4+jd48GDNDuMaY2HWeMrL0MZIxkLcuWMCkDBs0MG6fVg289EF628s/1gyoSWhXzNW mxBXVj6Y9GCNbQJZHo8HrKNqlnxskJNHOEOymtAO8jaZsmf86Ag4Ao6AI+AIOAKOgCPgCNQaAebc 6A9p/c/SRWfhwzmC/pe2YLPn4iNLEp100kmFH/P1cgyN4jg6+ty8fdDbsoyGmPOjP+QJpClhkeWW Wy5TH0UXQo/pzNJhBCCEA4urD5xiBQgBiMWHNVSU4EUWWUTJM6x+rr/+elWCUd5Q6ngOEoBKgADB ShC3MVMwAf3/2TsPOKmq8/2/wMLCsvTelyYgxYKIIipiFCX2FjVqNJYYTYxJjDXF+P+pKRo1lsTY o7EXVGyINAtIEaQ36b2XZYFdduf/fs9yhrt378wuy+yy4PvyGWbm3nvac95zd85zn/ccVB7kzyST a1HJQXjw2afH+V966aV4Z0Z1FpM7v7kE6SmHcqkHebFZw8svv5xwokgIGev+kQfp2LiDxeoZmD4f Xx8IQhyHySVt4nzQwALHpEyw8G3x6RnQfhJMuz3THcwj/JnQQh/mxrpbKGIo178oo7IaRMIPfvAD R67C5LPJABh5XKk7/gHJi8oUY5dSP8GvbO2C9DjhhBPiO/dSb0IVIcDxDdpFm+h72jVz5kzn1xz3 BqGBagpsuJGxQCrpg5hwHIKI4xgLqXqS2+dTWd4h/1hvDWyoN5JqNtUBD+//jEXah+8yRrmX+D9s 5dUOxgzh2hh9wbp9flxSF16Jxk5J4xhfDo5jr0BO1BbuGSgAIQL9izIqwrjPst4e9xvqwY8B+sff q/0YxA99nRh/XuHo68j6sIR3c58GW8YpIdL8LaBfwy/6n/ueN/zX36c59tZbbzlf8H6Pj1AnHgSh tMQYIyj+gmHzEK/87cEYXzzt475KO/w9H2KdvxsYD3j89e6A/WcIGAKGgCFgCBgChoAhYAjsBwT4 vYqQgD0BEMDw+9lzBv43Oco9H8nCA/Rkywz5JoSFIvxWL2l+4tNWhnd+87dp08ZVBQ4G0RBzCX7b 8+IzmzImI++Yk3rOBD6G+R9pPQ/D9y+//NJt1loZ2pyoDmmJTlTEcVSALL5+//33u4kaEz82DfET MhZrZzLLhJ7dGiGzWAuK0DGckMk2hABqjpEjRzonf/DBB+OL0DOBPuOMM2SU7iTJAGBCSCguCis6 kBBLSJAohVSw/ahDunfv7spgvShIpiOPPNLVk4kh6ZncRklJyQeHg8C44oor5KGHHnLExP/93/+5 +pMPE1cmz+QFG42ChgkquyezOUpQncKGATgmslMmxmDFBJxJKCohJqtggcHmowosycgHZ8bxmdSi vuRG4NVN4N6pU6dSkYkllZXq82D7k5/8RJ555hnnJ0zY2fyEEErIAG56kKlPPfWUU8PRposuuiiu kEt1fVKRH8oofAU/4EkDPsMNBcKcNuHXEBCQKRDPkIT4ir8hMTZIj5+Sfvz48fLwww+7djN28NMh Q4Y4ooY+99eX5ulPKtq3t3ngf6ybSTtmzZrlxho+z66yhJ7yGXw8JuAxevRo4UkVRGh5Gf2A0pI/ fuDIfYANjtjB1/+R5BwKVf/d1+WTTz4RXpC93BuC4xjikjHu/wCVZhwzDjxh6MvgnlARRrncx7hH QILit9zfUCPyh5Y/soxB1nrlnsu9jv4ME4APPPBAfL0M8gQXrh86dGixZvCHlvSUG8zntNNOc+EI EJHcK/m7wdjwvs3fEu6tPqSaeyt9EDT6AkIcP+KeTKgDKkf+NuFr+Nnw4cPdQxzScezKK68MZmGf DQFDwBAwBAwBQ8AQMAQMgQpHgN/I8AFwEz//+c9lwIAB7ncwfAPzFeZSTz75pKsXv8mZ9zP3PNiN eRGqPeZqzIXBhzkAfBSYwSexuQcCrETGvIM5nY9eZW7O/IB5AnOWGTNmyCOPPOLmConyqAzHy4UA BERvwc/+mH/HEQEOhROqDAjAc845R5jE0UkXXHCBm4RBcgAq60AxaWaiSVoIL1QjU6ZMcWobdplE 7RG0U045xeXH5JNJIevlwcxmqTIQAgUihEkgzHiiukIWUk/ygFCBMf7Nb37jBgx1gHBjks/EEFIy yiACbrzxRscso05i8LH4P44HiQHJweSUtizSMEfIHB8CGMwPAhLSkgUo2RgAp0VNw4SZyfeIESPc 4MYRTz75ZOfowfRRn8GbraxhspEMX3PNNY7wZGILJkyemdCDWXlbsA+CnxOVC/FBv0M2/POf/3T4 syYBaihuaAxQFJcQq2CEWhBcwDuR+XL9e6Lryus4dcPf8BGITfwWAo8+JxSS8yj3uMlAfEFYgIM3 xg6k7iWXXOJucvglNyOeaoAV3wkthpiBEKX/CbUMP8XhiQYWxsF/9+++XP/dvwfT+rzC1yY6HsyD NAMHDnQky2OPPebaDqHLOKSdkKK0CUwgmvhMX4NN2Hy+/j18nu/JzgWvB3MeKKDuRV3KPey3v/2t qxP3DAxyiqdwYYUY9w3uPTyUoA2MY0JIqTfqOcYx5DXjGBLz6KOPDhZd7DN1Dtc7/L1YohQegFj+ 1a9+5ch37qs8SCDkvnfv3q4/uEfypBEf69atm+tL7i9BY0d4b/xAYXfeRAvo8gSThzL8gAkSgBBx 3N9RIdL/3O8pG3wxQnq5/zJGUMoOHjzYkZG+XP/O3yEePvE3iR8CbEgCKci9lodJ/B2i//34gYw2 MwQMAUPAEDAEDAFDwBAwBPY3Avw+ZT7E3Jjf13AniBZ4sM0cmaXRIP/gIFiHnMjMkixqXhF1rKR8 9td52svvfkROzBkh/K699lo3x2RegSoSnoW5sl/DL9w+CETmNog0wPemm25yQgPmfXANRFLCWTHX IQ/mM+E8fPv9cf/ujwff/Tne/efg+bJ+LhcCEPLKb0IA2MkMQoPwMSb0OCXEBGvY+RhtFoNnYoya yatLmFgCAhMwJnJMmmGumYj7dL5MOgT2G4KPyRyTaiZvGHVjEsruLY8++mhC8o5r6XBUZZCRkEqs nwZZRx6oXJjks1aV3+AjSMiQHuM6FIoQVDDzKH0gDnA6zLcHchNCkQlumJTJUhIO0gGyAaIA5/IO ARa8uAZSB/VgaQY0RBnrhyEVhnTCcVHxeKM+wdBqf7w83qk/pAfG59IY1zEA6WNIMohUBjGKMY8p OBBSeOedd7qBnSxf+pQ6kDaqH5OlTdU5bsgsLApBhpIJUgW1K8q2oO9DzrL+Wnic0V7IKMyvrwnx wY2JNnE9xCGKWshsH8rq6++vAQevLPTn+M7xYJnB64PHfX+G8+Aa8mDsBs0fJ10Y++uuu86NV8Yg 448bLQ8AwIhreZEO7LivJGsT5XBtlPk6cC5ch/D1kI/41D/+8Q9HyPKAILh2BH+AGVth415AHSGX +APEvS08jvlDDRHMg4KSxrFvD5h641hFGfVDdcofOkhr2kWbINx8v3ANDzV4EMIf17CBlceAcxDU yYyHLeEHPvj07bff7khB/jgzZvAVv0gxfc6TO+/7PDjw6sBgWdx7yQf/5F7N/Q9S1vsaeRAyceaZ Z7pd7RP5UjBP+2wIGAKGgCFgCBgChoAhYAiUJwL8JmX+4AUwcB/M6yH+/G9y5gv8Fr/00ksdZ1Ca +gTnR/76ipxr+DL9O+308x4+lzRnIx3kH/MyiFH2SUCcAHfAPBXOhU1qmT8ifMLCv+/hmX73u9+5 cwhREBsgWKBssCAfIk3PPfdcVw7no+rmr6f+pEtUd485eaQS63IhACHimAhiJYWgohxBqeQnfllK XgUndX5Ch9oNZQfKGSZ1SDeZhDGp5BrC7mBkmViHjeN33323I86YlEIQYXQwjDjk0QsvvJCUAISE ZEIIucAAgrxjAkgekIOoFWHTmcxjYSKSY3QuC8xDAkK2MRhhjyHcwIv8ULO0190uuQ7Ciklx0FBC 4Vyov1CiQJoyUSZvyEzKJR1hb+BSWsPhaQdhjGBMnXw/kOfe5FXaMqOu42aEAhEjBLC0xiQehShK K9ZoZEDTBgYzPsaAZ0Ai0y3J2EkZcgmcvZKrpDTlcZ7+hACnzpDe3KjoG3yFGwbKVZ4woBALE2nU Bz9iTTXGDr7GuEFNiIIQ4goimV2kozYv4CZDCD4kS7AfGG9sMAHRxdjxRl3OPvts98cENaFXWPJU Cb9iXOLf3gjDZlz6GzfH8XUISfyNcRXGHjwgAakPCi+e3tDPjCHK8+MH8oYxADZBww9oE2QOdef+ EWW+bpwL1yF8PbijKOW+wB8C/IZ7kx87kOdR+NJn+BcqMz+OSefHMfcB2sASBqUZezwA4SlWkKhH sVaRRl/yMAXikvsI90iepDEGwREcuNdDfEaZ75uoc1HHyC9qLU8eIKH446ER92r8gxfY4qf4F/dX HjzRP4mMv10scIyf8rCFsUc++CH9w/jhvpksj0R523FDwBAwBAwBQ8AQMAQMAUMg1QhAFiFMQviB GIbf4vAFzDOYL/FbmN/lAzQ0+Kyzzip18Szfw5zFG3PFkiKU/LWpfveciucM+F0fJuuiymTu5YUV EKTMjeGgmE8giCICiHm254rCEVzkCW5gCPGHIIu5KPNB5tZZu0VY8BnM8SBfEXV5YZyvk+e/wJP5 DHOLsNFGhBPM7eg35iOpsira6D3xuqnKtRzzobpMwjwByCQ+rJJLVjwTcyZyGKSRZ1MBn85mQKDg STbxxzHobE9AJiuvpHPkRXtQAZJflAMkyoO04ODZZSbgQUIlUbrvw3FIUcguBiSTdQbRwWDcqPBh yDLIuL1pF2QefwAYL2ByMBg3RdpEP8iipXgAAEAASURBVOP7YcL8QGgjylXGMT7LH6+DZRxzT4ME 3N9jEGzxEYwxU1YfIQ/8jf7Zm/v0geCDVkdDwBAwBAwBQ8AQMAQMgYMPAc8XMM9gDshv4b3hTg4+ RApbRFQPfA7vpRFbROEABwPfALGIwOBAsQOOACwvYPeGACyvOli+hoAhYAgYAoaAIWAIGAKGgCFg CBgChoAhYAgYAoZAqhGIXgQr1aVYfoaAIWAIGAKGgCFgCBgChoAhYAgYAoaAIWAIGAKGgCGwXxAw AnA37Mg/Mf+++7C9GQKGgCFgCBgChoAhYAgYAoaAIWAIGAKGgCFgCBgCBzQCRgDu7j4WV2RdNBZp 3Jt11Q7o3rfKGwKGgCFgCBgChoAhYAgYAoaAIWAIGAKGgCFgCBz0CJTLLsAHImr33XevbN2yVWrW qmkbaRyIHWh1NgQMAUPAEDAEDAFDwBAwBAwBQ8AQMAQMAUPAEIhEIOWbgOzMF91OObKsSn0wP3en 1psw4CqSll6zUtfVKmcIRCHAPsfpRulHQWPHDAFDwBAwBAwBQ8AQMAQMAUPAEDAEDIHvNQIppwsm LhXJVRLwgLMq6XuqfAASmHsqb5++rwhUrSZyYtb3tfXWbkPAEDAEDAFDwBAwBAwBQ8AQMAQMAUPA EEiEQMoJwJxdIjv1ZWYIGAIVi0C1A5F4r1iIrDRDwBAwBAwBQ8AQMAQMAUPAEDAEDAFD4HuJQMoJ QMIQeZkZAoZAxSJg465i8bbSDAFDwBAwBAwBQ8AQMAQMAUPAEDAEDIEDBYGUE4AHSsPD9czfhWxR Y3+rVJFqaQqLhQGHIbLvhoAhYAgYAoaAIWAIGAKGgCFgCBgChkC5IRDTDQV4YVV0bs7LzBAwBFKD QLkQgPn5+bJrV66rYTVdmCytRo3ihJqO41hBTPLycvW9QKpW0+vSqkuVqpxITeNKlYsWV6Dk34xJ Y9yNplZGpnQ9rK+wHYjZgY8AfzwKcrU3d//dqFq9alIfc9drDHv+rgKJ5etL01dNqyZV0qqqH6cV pk0AS4FLA4mc4IKIw/w9q1pDF+8rwecZK7ycaaKq1faikIhy7ZAhYAgYAoaAIWAIGAKGgCFgCBgC qUDAzaF0Tp+bmyvbtm0T+IA0FdVUr15dMjIypJrO9UtD5JHPmjVrZOnSpS59y5YtpWnTpqmo4vcy D/DcpVzHjh07XN/wmb6gb2ooR1OzZk0jWb9nnlEuBOCKRXNl0ZxvHafRsHFL6dX3hGKEWlUFetPm DTJ7yljJyd4sDZq0kM49jpLMzLrFri3PPoFG2bRhrfzpusGSpzsBt2jbSf47ep7s3FF+pULj5O7I kR05OUrkVNWBlyHVdfCVRAKVX40OwpzpWCXMspdvkrWzV0jVqupxeqxZrzZSu3FmUR/T4/m5u2Tn lp2yc1OOrJu7Srat3SI5a7OVPMyTjCZ1pU6r+tKgQxOp26qBVK+tN0oc2JN2lKWf18xcJtvXbNVz nCydVc+sKW2ObS8FwfX7dudHDgV5Wq+tOyR75WbJzVZSXS9Mb1BbGnZsWirisHS1sKsMAUPAEDAE DAFDwBAwBAwBQ8AQ2HsEIP0g7VasWCGzZ8+WcePGyebNm6VRo0bSunVrOeaYY6RDhw7SokULRz4l KwHy8N///rfcfffdUrduXbnjjjvk9ttvT5bEziVAABKWfpk1a5ZMmzZNFixYIKtWrXK40hedOnWS Xr16SZMmTdwLQrCyG4RmjnIo27dvdyRmnTp1SvSpyt6miq5fyglAuI8xH78urzx2t2vL4ccMlCOP /0yUWyti1aqLLF88V56450ZZt3KJdO99gtx497+kbrdDlfQocunB9UXJnV07d8r0iZ/L5C8/kYza deWIfqdKz779ZNfB3O4K7kU4tOx122Tyi1/K3PenOrIMtd3J956nZF5nKQgQvFV1FKz8ZrnM+3ia LP1qgRJtOwqfhFBnTaP3GacETG+QIYeefbh0GtRDMlvUL1T66TnKytuZJ9NeGieLv/hO0tJV0ZfQ qihXWMgccgNroERe+5PaS+62QAI9jZpw55YcJS9XyYLhM2TZ2IV6zU6J7YpJy96t5cQ/nS21m9Zx dQuktI+GgCFgCBgChoAhYAgYAoaAIWAIVAgCEHbjx4+Xv/zlLzJs2LBiarICVQVigwYNkmeffVZQ 9O2NlUY1uDf5fV+uhfz75ptv5LHHHpMXX3yxMKotIFJhHsoLBeDZZ58tv//976VHjx6VHh6UjJ9+ +qmMGTNGsrKy5Pzzz5dWrVpV+npXpgqmnACkcaitCOnFqapoCHAi04j+OGOLEu77MMAdWaRs6JQv h8uQ5x+SWhl1pFZmHTn8OCMAE/nJXh9XkPO258nCkbPku09mSlpNZZvVIACjfAwy+rtPZ8iiEXO4 SjIa1Zaa9TOkBko/Df3dlbNTtqiSMHfTDpny/FhZPXWZ9PvNqVK3bUMNE3ZZu8xrN68nDds3kqrV kw2rmGxeukkT6dhQn2/UqYns/rtYmJHWcfv6bFk+fpEs+3qBEorzJJaXr/WoJtU0BLlAdrl0u0u1 N0PAEDAEDAFDwBAwBAwBQ8AQMAQqHIGNGzfKc889J4888ogsWbLEkUkQfG3atHGhv5CDKM54jRgx QrZu3VpiHeERGjRoIG3btpX69eu7V4mJ7IIiCMDBQJBdeumlDnuUfZBk7dq1k1q1arlwYBSaa9eu ldWrV8vEiRNl4cKFBwQBuGXLFhk6dKg888wz0q1bN+nbt68RgEV6v+QvyZiKklOX9xWwZQlM/doR OvHThaKq+NdiH4J5cW3we7GLExwIp4nKJ1E9dqflDRKqmhI6GBuOVKmiayLwJZw/xxLll+h6jntL ltZfEyqzGK5cV4Z8XPalSefrkap3bU8sPybrZq+UOUMmuzX70tKrS96OvKL+EixP6wm5VruZhvq2 qCdNe7SQ+u0bS2bTulI9o6Zkr9ksi8fMkyWfz5PtG7fLmhkrZJbm3feXJ2mfVXUqvGpKFHYY2EWa aVoXbhzMP/B5x9adMv6JURpzLJp3DVX/dVOCb/cFWne6Y9W3y+SLv32oKkC9ppbWS4lGdIPbNLy4 IHd/gBpogH00BAwBQ8AQMAQMAUPAEDAEDIHvNQJ5eXkyatQopxwjHLN27dpy3HHHyZlnniknnHCC +w7xhwpt5MiRLgQ12RzJg8magf36qTBG16ojvPOoo47yp+y9lAhkZ2fLH/7wB0f+sd4fIdgXXHCB nHTSSY5chURbvHixfPvtt44oJIQ7PT29lLnv38vwIdYvxHgvjU/t3xpXvtIrLwGoTEi+2yAkX6mP mD5FqKVLuhUoKZKrN4Q82amOWqtWTe30NCXRahSuu5aIG4FV0fXgduXnqtpKF8HM2aEOU03zrCFp epOJZt4CnaXpIcZi+bt0CbY8zSNf1wvM040idkn1dM1jN4mXlqYDJ2ITE6qVn6cx0Cz0pnnl6QKD tAGDoS/QeuXmbtfQ4EADlFhK2i7Np4D6aD4FKkPbuSPXEYvpNcEiTeukMfxI3gJZugKD/3Fa5Wf5 u3bG27RLb+YOFyXEqkJM6sYsYKyXJjbqounA1ht9lqZ9FqW489eUy7u2d/vGbJn70beyecl6aaBE XlrtdFk3ayXS1Mgi6ZbGnZtJPV3nr9UxHaRhh8buOnU3Zw07NlJir7VUUR+a9e4UydtWoCrA5ZK9 NkdJwkynAmTdv1a9s7SMwjSR/ytOS75YIFW0jjH9TAhvqyPaOKLPX4+f5eWon+bmS2bL+tK4W3Np 3TdL1wDcInOHTi9cB9BfbO+GgCFgCBgChoAhYAgYAoaAIWAIVDAC69atk+eff96txQZ5dOyxxzrS qX///vGadOzY0ZGChJi+8847CdV8kIkQft66d+8uvJhHerLHn0v2TrjxTl1qi/BX8uSF+o08IMIg F0ubn68TeUGQMWcnL/LxeZamLrSLl28L5YNXec6Rp06dKpMnT3bVa968udx3332uH3x9UQOinjvt tNPkRz/6kVMAorgMmseRY9SXdiczQnPBn3Z5nMLXgwNYBjGlT8gbXPznYDpwpy4+bz57X/HnIKD5 7A1SsCSMvX94XyGN9w/SRplvo/ch6kJ7CKMmDcc5xov8g8ej8uOYb4P3E/Lz+JGfxyVR+rIcr7QE IAK5mZMmyIa1K3TdswLpdewA2bxhnSxfOFs2rFsl2Vs2Sf1GzXTzkObSrlMPadaqtRJe2pw9fV+I B8yVMjnr162WJfOmyfrVy2TjujXaSbWkXqMm0qpdZ6nbsEli7DQ9JFn25k2yevkCWbtyqWzZuE43 LtmiRN52ycisJ7XrNtBXfck6pIc0atZKiTslFQP1iCnDNHPSl67+cHI7d2yXlYvnuzLzlcBbOHe6 fDVsqDrK7kT6VrNmLel2ZH+poxLogD/H25Snm4gsnj9LVq9YJFs3rpfsrRuVsKsqdRs00Tq0lHad eyk2jXUQRmCiubCJBcTfWl2sdcHsqbJlwxpdUHOL7FCpNiHJNWvV1rwaSfPWHaR1h25SI8kmJdwP 5k+f6urCTrW0sUBvlkedMNjlFcQiMdApOKPl5usOviu+XigLPp2tir560u6krpKv6r8103QjkATe rvyrHHLGYRq6q92mZKByvEVNj6XVqiEdT+8pM96eLNV0J+Fdmmf28o1Sp3khAUgCbbL+VzRp8Bt+ NHcom+PE1EeqSZtj2kuNujWU+N191e7ur9mwlrQ8ur20PKqddD6th9RrV0dmvjFd+wwdoJkhYAgY AoaAIWAIGAKGgCFgCBgC+wcByA3CRj/55BNXAXbpveGGGyRI/gVrBrn0q1/9Kngo/hlih41D5s+f X0zNBfnRpUsXt1lFPEGCD5Az7BwM+bV+/XpB5cZmEfXq1XNhr2x0ASFJfokIHrKGkCF0ecYMXYN9 mfIGGua8YcMGR1oRmsyra9eurk6oHqMMEoe6oH4kPeG2kDpsasLGKEceeaRAzNG+8jDWZPSEGEQq ysxElpWVJbzCRh5s6kL/QO4SPpyItARnVJ4oDzMzM1372GQkaJybO3euzJkzRzZt2uRe5E3/QJQR Ou77J5iOfh09erTDEJIOPBctWuQuIR/OrVy5Mt5eTlAH1I6EO0cZvkH/0kfeVyD/GjZs6ELPUZ2i Pg239/PPP3e+gL9DWuK3EOHU/fDDD3f1//LLL50vE+5OHx9xxBEutDqqr/ET6o4Sk1BsMCId9eeF r7Vv314OPfRQt5N2VFvKcqx8vK4sNQmlqa6b4n786pPy7defObXcVbf8TaZNGCVTx45QAlDVXMqE 5KsCro2SU31OHCyDLrxKP3eVAlWtxVkSJYSq6Kppq5cvlJHvvyJjhw+RhUp2xZQQRLGVoTsOdzui n5x4xqWO5AtVwX3VLGR7TraMGzlExo94T77T9GuWLVQCh9Bdwj95GpAuDZu3kqNPOF36D75EOnY9 XNVve3bR2aVqwSEvPCTzpk10N7Z8dfacbVtc/juVyBs3/B2ZNm6kqxcHOd+4aUu5+b7npH7jBqL8 5x7TCmVv2iBTx42QkUNflvkzJsq6VctcfSDfcMa2nbpLn5PPkhNOu0DaduiiarMQCUijdC25WZPH yZefvCXjRw6VVdom1JC0icGIurBx89bSVfG5+Gd3SYduPQsJrj01iX+iqWM+eFXGfPRaYRuUAYTY 7Ni9t2KsG1XEryzfDxClqP5mvDlRGciYND+8tXQ6tYfMfHOCFpy8FqSFCExkEKaE7FZLc+A5gpOd gwu/JUoVOK4Xbl2xWVZqeC9VSatdQ7IGKDm552FX/OLGnZtL35sGqiqxKdy1qxckspkhYAgYAoaA IWAIGAKGgCFgCBgC+xMBFFfvv/++UzpBkkCIEfZbFkOBhTqQtQSD4ZzMsSFhbrzxxhIJQNRTX3zx hbz99ttufTiIHQg36sa8lvNZWVly4oknym233ebqG1VX6gIh89lnn8kbb7zhwpbJy5M35NO4cWMZ OHCgXH755fLDH/6wWDaovyZNmiSvvPKKqw8kmk9P+yBDzz33XKe8O+yww+LnimW0DwdY288TgF6N BsG1N/baa6/JW2+95ZRst9xyi9x0000JSSgIuVtvvdWRYews/Pjjj7sdn315EKgffPCBDBkyREZp 2DjEHZjQP2AOrp6ofOKJJ4qoDUl7//33O+IQnoPrIVQx+urhhx92hK5vL/1NX4MtSsew0R8ff/yx 698pU6a4XZKpC+nAiHTXXXednH766dKsWTNXR58HG91Mnz7dEX3411dffRVX+p111llyxhlnyIMP PigzZ8509STfiy++WP74xz+6ND4f3mnzhAkTnI8wlubNm+fKx0eoC+2EQDz66KOdshbSOFVWaQlA Imm3bFwr69escG398NV/qcpsolO4te/SS0EpUOJrqSxVReDKJfOVUMuWS268Q5q0aKfkTCE85LFR lX8fvfqUfKDpUe3VrlNfGilZh8Ju/eqV8s3nH8smvQago0z7QLYq4TZ66GsybfxIVcZlSENV+TVo 1FzS9TOhvWtWLJHVSxfKO88/rETaYrno+julY7cj9CZWKJWFPKpVq47UqdfASe9QxxHenLs9R79X kfSataW2st8+5BSCsqbuDlytWpoO3kCttD27cnfIZ0P+K+//7zFZtfQ73UQkU5q37ehwydMw4vWr lquicKos+W6mbFy1Qs6/9hZplaW73gb4I3BZrYTfa/++T775YpiSWtWdkrJpq/Y6gGpqiHS2bNm8 QVWB6/T8J9L/1AulU4/EBCAYbVZVJP0RtF3axoq0vOydupPvdLdzboMOTVQ911NqN0ahFwSxDDVS vNiVN4c1+PS9qioA03WDkExdL9D3WUm5gtGi0bMlP0flhdrn9TXMuGEnJfgC/eLzIDQ4s1mduBJR 3cDMEDAEDAFDwBAwBAwBQ8AQMAQMgf2OAAo5yBMM9RbkBMq2shgkEOQN754QgvRBpZWRkeE2qigp X8iTe+65R1BoQcy0bt3aKdYgdFBVodJC6QXxw66xEJZRhuLv6aeflqeeesopslBhsaEJRBDEDPlQ N4gx6hwmAOETwOXPf/6z2xEZbEiPYgzVJOTTggUL5O9//7vbdOPee++VQw45JKoq+3QsSHwRCozC jDZTH09GllRAr169HIlJeyEz2VAkHCZMHqjYUP9BeoERijeUfN7A6aOPPpK77rrLKe5QTXbu3DlO rqF4g8hjExmIRHYthujzhk9ABKPOI3+IM0hNlIFcRx8FlZj0AddzbdhQD0Iw0r+QpCgywR+lHT5N /6BsZe1Kvv/4xz9253w+1HPNmjXuBRGMUpD+RL33+uuvy7hx45zfcnz58uWuTe+++6706dNHfvGL X/hs3DvtfeCBBxwpSp/gY1lZWa4tlI2/4m+obM877zw3xopksA9fKjW1gErP29yp46Vlu0PkB+df qao2VU5pnOa8qd/IiPde0DDhVUrQ/U/adDxULrjmRiXzCp2malpMJn0+XIa9/exu8q+eHH/6RdLr 6P4udHfV8kUy8t2XZe60CTqIowlAymdH44Yaatyh62FySM+jpXXHTo5ohNTLzdsuyxfMls8/elvV eJNUZajrG2ho8tW3PqAknsqClXuqptvMDrropxoCvEZvbFVl5/Yd8sWwt2TCqKGOcDui/yDpd+pg VXoV1oGBkl5LZZ9Nm+8hiJSEgribNXmsvPL4nzXkd5OSmfXk6AFnyOHHDlACr6Xk7szRcN4Z8tWn 78jiudNk9IevOLLzop/dpiRfelwEV10/fjXsA5cX7WuruA046xJpf0hPLbe25GzdrMTpSm3Pt0pu LpbMukp0lcShBfqKPDF2ea4oK1DF36qpS2T+R9MkvW6GtNYQ2tbHZEnO+u0pqULeNr1pT1qkakr1 SW1WrcZ1dM1AxSWCwCtWoF6fty1XNxKZ7/yMHa87DuzqwrCj3I5jJcFdrAw7YAgYAoaAIWAIGAKG gCFgCBgChkA5IwAJA1mCQbYQVltWg+BhLTpIOz6TN2qx9957z5FVQTIoURko/whZxSCuLrnkEqco g/CCwIK48WovSJ8og8iCxGFHY0gpSKFTTz3Vhc/68FfymTVrlgwfPty1O5wPZb3wwguO/KPebL7B pijt27d3pBXqMcg0dtx98803pWfPnk45Rz1TaRCykGKQZBCgKOggPgklJVwVkpQyk5VLn6DK/Prr r11Y9bRp05yiLtwf5I9aEANblHP4hDfUoi+//LIj/0gLphCnYApJB2ZsSEL/QJrhA0EjRJjwclSD XA8x/OqrrzrSEWL12muvlQ4dOjhClnTwKNSDdEFDUTds2DCHBdegrkO1Rx9BvpEvRClqVEJ7H330 UbdOIqHEnkwMtv2qq65ySlB2t4bQxfCPK664wmGNug+CF3wgFSkz2DaIPcKXMUhIfJYwYuqOwhES knB2QqbLSq67zCP+q9QEYLC+hNSefflNcublN+rNoPBM7+MHa4BvgQx57h+qWtumIbpD5AdnX6Tr 5ilxpgwKRNt4JdlYsw/A+ww4Sy698Y+qmFM5qJIscDlNW2bJI3dd68i5YHn+M2RMrdp1lKA7R3mf c6R7nwHSuJmuywdJo2Xgo1WrniXN26jc9c+/kI1rV8o4rcclv/ijqvNqOyIHArF3/x+4aykze0uu LF80zxGA1WvUVFLxKDn1vB+J8ndFTB8UEMkat+05WzWU+GEXPoxqr/+gi+TiG27XkN8OSogWEoTH DDzLrUP4v0f/KBvWrJSvR7wvffVY5x6Hx8NNwW/u9PGSq+HH2HGDLpQLr7lNQ4C1TeCye9xt3rjF hRjTtpKIriqAsb9M65uzZouukzdJcnWX3caHtpCu5/TSNf92N2Rf6kUWqiDcMH+1KvjmKkZVpGb9 WtLiyDa6LmA1Uf63RIMbXTF9hWxeut7hW6sRBKXeqCLCf0vMzC4wBAwBQ8AQMAQMAUPAEDAEDAFD YD8hgAILBRUGmQRZVlaDVOnbt697kQcEICorCMDSGsor0mGXXXZZ5HqDEE2QTJBFUcaacBBZkH+0 ic0xfvvb3xYLP2a9Owi2cPQgBA+EDeGcGOQUobNBlSC4sf4gYaKQPM8//7xT1hE2m0qDWIS4QnmH mgyCFCVg7969HVkLCUiZEIL169d3Krpw+aj9IMcgxSDxCN8lzDtI7oEBazdCdmGQuITBBg3VHcQY Rlm//OUvXd2C1/DZ70rsyTZ/HiJz8ODB/mucqEN1CDEGvoTtlmT41EMPPeT6jTZA1N18882OCPRp yYt+Ywdl1iukzZByYQIO4pTQdEhMyiYMGYUnKkXISvwDFeSzzz7r2kX7IZiDa0+yPiS+hrFJzh13 3FFE+chxfA3fhkBOpR0wBGBW5x5y8rk/cQSK4ucso3amDLrgGlXfvaabWSyRFYu/k1lTvpFjVE0H wbdq2RpZMn96IRPcoLGcqurBpi1aSd6OPQqr/oPO0pDaF1U197bmrYlCBgGXqWHDx59+riPG8nYW yKb1W9wGGqgQSQOp1+2IY6S+bsABAbhRFYlbNukOtI1bIBZzBpmHQa7laRgv6xdi3CzYTThXN4Lw 7XInQv/pvVEWzPxWpk8c7Ry3Xv3GTg2ZkVlTw3kLn8CQpJqqHg/tfbx0UaXi2M/e1TDh+TL161HS TZ03uN5czratWgcvXytQFeUaqVu/gW5wsWd9gNp16soRxw104cMacZ3QgI2watYejJu2q7qujVgR UjZ2zV3wyXRZNXmxZDSurev+HSoNdf28Ypt5xCtX+g8QopsWr5OZb38jW5ZtlBp1akorVRe2P6mz bjhSiny0v9ml+btPZyjhp3jr95Z9VN6rIb7BsOxS5GSXGAKGgCFgCBgChoAhYAgYAoaAIbBfEUAt BaGBQWrsCwEYbgiqNU/mhc8l+o46zM9rIaUInYRsCoa7Qs4M1LX7EhmEI2orDALt17/+dTHyj3OE JbP+H+RM0MADko0wYoRHkECsORg0sLrmmmuEsFAIIJSAvEPwBNVlwTRl+UxYLOQlRCbKSK+yozyM /mLNPepIyO6AAQOcui+8TiChpxCa3333nSMTIcwgDb2SDdKLcGj6DFKsX79+RcJ/KYtrfH9C7qGI o79Q6Pl8uA4yjVdJFvQP+hpStTQ2duxYp2akTMhNQppJ75Ws5AEvAxYQpBCArAX505/+tBgBSPiv V5JCDtIWfA78CG/G+JyVleUIQOoI2RckAPke9FnCiMmXPvOGryXzWX/d3r4fMATgMaecK2lKKCkf V8TqKrHX/YjjZJQSgOxiu2ThTOlfVZWBeuHm9atlq65lh3U4pJfuFNxeQziLclKQYv11s4yvPxui m21Es1ykyd1eINu2rlZCbYXuvjvdkXzZWzYocVfodDVqVnPr4PnKsVGHYythB1NgOl6U/Ptc1wDc zX4qMzVu+LsaypvvlIh7itA9ZtV5t2/f5g7lZG91Oye7L9oOAKSZ7H48RfHMU+bxkzefdszkoUf0 111/W7i1DaunZ+q6hRriKrrRSTQs8SIhVE859wrpc8KgwgL0fxy6YdMWxfornihFH/CHFRMWyjRV /1WtUV1a9u0gXc7uJQV0y75Cr3hlL98gk5/7QsN3dWHOjHRpcXgbOezyYyWzab0ihGqi5tBv6+au l5XfLClcPzC9unQ98zAj/xIBZscNAUPAEDAEDAFDwBAwBAwBQ6DSIgCp4w1CJUwc+XMV9Q4pRagq 9WKNNwgndq5FzQWJAiEGYRNWl/n6QQShAIScwiD4SiKjyDdokKKeQGT3Wcg1yg0bu+OyJhwhtZ40 ZFOQVBKAlIl6j/UHUZARaso7ajzaSF3ZNIUXpBOqPdSKkIJBIw/UmaxXR3ju0KFDHcHlSSpUdf/9 739dErAmLDZskGPswIyhGiXEmvBW8OEcOKLICyoLw3mk4vuoUaPi2aCKJBQ76MechEPBF/xxiE+I vbD59Qj9cU8AQjj7dtCfvv/JD9zB2htEIaQp6sqXXnrJjSHIR9Zv9D5Lvqn2C8ovFwIwyOb6Ru7r e7OWbD1dlNHRPlJmv7o0btnGZZ+n7PPmdWv1OuWzVDG3fXu27NAOxho0ay01FGTSBA0yrFnL9pqg aN7xazQvYjWXLZwjo97/nyPhWHOQjTJyke0pxcVad9QtZ1vhjjSkjcXVdXzbd0MBuHLpAqcWJLet mzfKMIi7kNE8qswuvCjwUCiy+QnVcU3Rc7uUQ+w36DyZqpuaLJ6rm2asWCIf/O9xGatrB9bXzU2a t22v6yx2k0N66XqH7dtLRp3GSUlA1IGt23fWtQQLGW9XJS0sT+EJwe1Opew/LWPH2q0y/Y2Jkrtt h9Rr00AOveAIqaE77KL+o0ur6Hp7+IM31pXEN9xm0RCbiSqoabetyZZpr46XZWMX6DqQVaRRl6bS 67K+0qB9o1KRf5RJOYtHz9HQZGVJ1ZpoHvXbF94E3QH7zxAwBAwBQ8AQMAQMAUPAEDAEDIEDBAGI Ccg0yBJILBRd+9MI1x0zZoxTbRGSCsnEen6s7eZDXdmYISsry4VphusKIRZsA2uyBdVa4eujvqNM 86GuEICsMZfIUKBBooEdikFwLA+DTGLtP3aShcCjfqxhyJp0rEdI2RBchD6jemPzkqBqEmKX8NRP P/3UkXfsjHz11Vc7Ios6Q6pB5uEL3bp1c+Gy4XZAvA4YMMARnhCA9BMbZ4APZGh75RoIo/X9A3ap Nog9yDyMz2DBRiB8jjJIOfqfNvow3eB1Yd8If+daiDtPjENIh5WKhBuDKwpQ6vPkk086ghWfJUwd H4R8JZQYcjWVVi4EYDVYj700SMNkxGGG7oobJHJ89hA66TULGfg83XUWxZ/j8lTZl7djuw6swkXa aujutm5X3oh+rqWOGVm2EkdsvLFiyWJ5/cm/yoQxH8i2LZt0x91GUr9xc7fGX0aGLiSqdUhLqyaz p+jOLxr6ixUQ30lZAfLJnSjjf7SJ0GJ/g2jSOktatu6QMDfXHgUMIrBt5+6O+PQ+roek62F95MJr 75APXn5c1uruvdt044/F86bLdzO/kZq6s3Cdug00rLe1rg94vpx+0VVSK7NhUhJw97ILCetTHieA duGYubJ+9kpVh6ZJk0NbSs06NVzILuXhL9s358tO3cDD9+/2DfrUY9k6VeNV1bX8dKdlTRcmAcF6 x+YcmfXWRFn42Syn3KvfvrEq//pJs56tS0/+afm5W3bKsvELlZAsVGpmDehaWGZ5AGJ5GgKGgCFg CBgChoAhYAgYAoaAIVCOCKBQIsSW0FKIDd73pxF6yhpq//rXvxwhBZnH2nUor1BkEfIK6XbxxRe7 nV2pe9CoP6SPN6/i8t9L8w6Zh8IOgxAK7kwbTh9Udvm1FMPXpPI7SkBeGGHJlIniEbxYS4+2s7EJ O9VCygVt0KBBTg0JUYhqEeKQPGgvm3FgtPWcc86J3FQEIuwnP/mJCxMm9Jm+IS/W/IOAgyBEGZeV lSU33XSTW+8vSEIG67Ivnz05S30ghcEjEQHolaL4dlC158sPq/LC37kO7sEfp5xwWSggb7vtNnn8 8cddKDhrQrKTMutUMr7wWfoCXH/2s59F1sPXZ2/fy4cAdOvIQc/AgEUwbrtr6Qip3axUtWpaFdi2 BJdD7rm4XiVnggaYu3YvbkdnVXc7WRReUTWthgJfXQmbXRpyuTtUlmqFLH9nbrFO4RIuzd25QyZ/ NVy+Gv6WbpqxXXf/baM75l4mx5x0hu7ym+nyp4Nr1hb5v59fFicAdzcrVFLZvxLSXFM3FfFEVu9+ g+TsK24sZLmSZMvuuLUz6ymJteciIE7TXYH7nnymrtvXVb6bMUXmzZjodjNet2aFbFUSE1KQ1wZd 07CWkq9nXnathgtrwgT949R2IWzdw4wE1++pzb59Wj8XUlRh0P9WT10mY+77ZA9RqfUpyM2X7NVb pGp1SOkqMv31iTLvY931qG4tOeraE6VeByU2A9jQjjxVE859VzH5cJrk5eRJZqv60uvHfXXjjnYu j9LWuKoup7h8zGLJXrXF+Vd63XTdmbhTaZPbdYaAIWAIGAKGgCFgCBgChoAhYAhUKgQgaCAnPAG4 dOnS/Vo/QikvuOACt3YfiipeKN1YVw2yiRBWXnyH3GMDiKChOvNkDccht/bWSO+VYCyF5cNIo/KB WPKinvJQvEWV6Y8RvsoLEgyFGoQeKj4IMvAJE4CQlaeccorDk9BZVIAQruCJmg9DtYZSMJFBvkLu sQOwVx/SP5CBlI06jxfld+3a1anfEuVV1uOekEV5ia+wBmCYlAvnTR954jR8bl+/Uw82NyEUGLIa n4UARJXJuGJtQpSBvEOSsnlKqqxcCMAaurMtXBAkWD7xoSFiaE/lC+Os+V5dFXqQgIn4oo3rlejR 60L8nxJ7ebJ1Q2FsNiG+9Zs0dzwhZbMLby1lpHN3blfl3noNfd3p0pNP3LRuG9at0nKLlwwZtFnX 8pvy1ae6o3COZGTWkRMGXyIXXH2z1KnXpFBpSDLX2FwdyMXziJcT/rAbE1LgfAkh8um00i3a6AKh esNlAxG40raddRFOfz7Je2E/FL0A0iw9vZZ06NpLWmYdIkf0P0XDpbcKOE8bP0ZGvPeSrh04R9Ys XyQj33tRBl98lZYV3T/Kfzp8c3cU7mRDSeBZt0EbV98IaItWZh++UXa1tEKvyNGQXcJ2g+awBV8A U9uyZIMShEqKNlW/2JHrVIK+1+jvXTt2yryPpsusIZNVBbhDr6srPS/uK1kndtY8qjmfDuaf8LMr rkAWafjvru1KMCvgrXq3l1qNlCk2MwQMAUPAEDAEDAFDwBAwBAwBQ+AARACiC+ICFRkhkpAXqMgq mswKQodqig0tIJBOP/10t84dpBYbOaBUg2AiPJjQYMifoMoMlRdElzdIF0i8ICnozyV6h4T0Yb9s ELJ+fWFUYNT1kF5+Ywx2zvUCn6hry+sYbevVq5db94/6sEZdVLgr5UOYvfjii25HYVR87JLLDrmk gchid+AwcRiuNyQhL3bVRe1GWZCI5McuxRC1kJF8vv3228PJI78zzy+JxPMJCaVlzUOMOuMn+9sY Rz169HCE58knn+wwAQfqydqK4IEvspswKkDqnQorFwKwdj3dCryKo7Zke87WQpIKQsQzLfoRsiVf JWU7lFjDamnYaZoq9hLZgpmTlUTRsNrgsoWaZ66q95bMn+WS1UjPkIZNdOMJJbcgvWpl1lXVXB3Z rAThct0hmDBXqaryV7LZber7qoCbVLgzhj+4+50q52r9Vi1b6I7Ua9hMeh49QHf3bSIqDIznU12r PXfarPiGI7uTJ3xjkKepMhGLKZkX39gjYYrC6rXK6qLRxoVdtnDuVMU2R2hzENd4Flp5yDEMLMIG /hhrA0LYNtYNO6RKC0cGtu3UQ5WBPeS+m87XtAUaerxCXxukQZOmWt/CdMH/af/Y4UN1fcQxWlE9 o+Xu0jjjq3/3N03TPLJ6wfRl/Uy7GnZqpuvrsRZjhOFjqgDctGiDUwECR5OuGrqtOwXXqFtT0msH dil21+bJguFzZMZrE2XbOiV8G2ZI9wt6S6dB3dzuyFE4RpTqDqkYVTZ8t0HWzlntwn9ZIzLrZA3/ 1TUJzQwBQ8AQMAQMAUPAEDAEDAFDwBA4EBFgcwNCQ9kUAiILIpDQRTbe2N8GCcmLNe0geSBYunTp 4lR/kEWoqiCg2L3VG0o4yCm/ruHnn3/u1Fko5UprlAmZh0EAsuMuCjIfTurzQRmI+s2rDNu3b1/s Gn9tWd89uRgkOaPy8ipEziUj08CQdfogVCGkPvjggyLhv5dccklU9pHHIFo92Ur/QAjCjTzzzDNO NYlCMJmBp29XUEmZLA35e8IP/P0GLKki1JKVXZpz1APymBfEOpvagDfrBNKXELQQg/h0KizlBCDK shbtOqpCrZrkK1u0buVS3UBjoe4u294p86g0xFTu9h1uY42crYWx8o2btpLadepGklWkmfT5x7Jh zXLdoKIDXwuNQbxwlsybPt59z6xbX9p06uZCQqlH/YaNpUGjZrJaCbwVi+fId7Mmq2pOSTTINyWP IMGyVRk4bsS7CdV7OAyqO6xA27NLd9BwQr/d5JqKwnQAb5HPhjyvROMad13S/7TcanqTqaPrCGJs JALBBrlZVdnIIMnkPu8m7+A+O/fsLZn16itpmi0LZk6RKWNHyNHHnyZVdteP68HWMa7aflSPebk5 klmnqa47FyC79JrNG1bqJiG1VNVYuAYCvJ3f7be+3uw6HnqkVEVtqCRtLAZppSq63XXRL0WM4mfp +oejP3hlz3GtzI+uv9MRgHsOpv5Tp0HdVZ3XJTJj+nfHxu0yXTfymLdso1RNryZdzjlC2vRrJwV5 VSS9bq3C0GjFI5a3S5Z+Pl+m/m+cqgi3SkaDDOl2nj5FOruX7v5bw/XL7i4vLEuxCPZPkQrohVUU kyW6c/DOTTkO13pt60vT7q0Kw9yLXJzgC3kAuxpkouvXwq+uf1E0uvO7K+X7zl9i74aAIWAIGAKG gCFgCBgChoAhYAikGgEIi5NOOsmRKqiUFi1a5BRihHqy8UTYUMNBvLGxAUq5ZAbBw/zbW/CzPxZ+ J29CewmVDBs70EIyeXKP/ILEl7+eNdneeecdR7SgQmPzDNroN3Lw1/HOGnooHmmvNxSIkDdgA7kH IQphFsZj6tSpLtQThSHXQvaESUKfZ1nfKRe1IzsZE8Ia1QaIpblz57q6UI4PDY4qk3pedNFFAjHK hil//etfXZ+DJRtWHHfccVHJ3DGwINSXvgn3PSpElIPsPkwdIec8MZooQ/Lw5C1+Vdr1J9nRGB9B tTh27FgXigxhHeVfnnRDoUdZqe4f2gapR/6s9Rc2CNLevXs7vKhvIp8Npyvt95QTgBTcRneQbdGu syrzVBasm3K8+Mif5NJf3KYLGtZ35Fte3jYl7abLh6896eS1bNCR1aWXEoB1IhVm5LlRw3TffeER OfuqX+oGFbpum0rN1q1cLe+/9Jiq8ba78OGsLodJ18OPUtIKsk6kcfMm0uWwYxzxl6dE27A3n3JE ZLtDOmtH1tBdarfI8HffcDvhonQLGwRPzVqZ0qptZ5k7dbxsXL1SJo7+ULr07K7EWTPJ14X1cnds lAmjRuoage9oPQrVjOF8gt/h0FinsGmLttqZVd0mHbO/HSeTx43VEN/Wrl5cDxmYUbuhIwshK1Hq tevcVfqfeoEM1Y072OH49Sfvl3Ql8bK6HKJkXm1HVObpmgK5udlKKm6SyWM/lWxdz+/0H10vLXRn X09c6n4l8uErzyiZ2EB6HNVPd/5t5NJXVyUgROT6LRvl68+UFNUbAw5XT8nKxs0aC5uHRJreowmv Zo3EoBFqW96WXqeWEnnRpUCQQfam1YLAK6xLer2aktmsjobl7ibwNCmiyiXjFss3z38lW1du1jbr WgaHt5JWR3eUnA0a1rxuT2hzYUmal/5xSq+bITW0fKd6DFUhd6vu6jRhka4huNNhmnV8F6mRoSRs SaZlU9W8rdtlxyYd8Er0qavK9o05jqTm+64du1w983N3FJK2en1Gk/pSrWa5DOeSamznDQFDwBAw BAwBQ8AQMAQMAUPge4IA80PIr6uuukruuusuR4axkywquCuvvNKRSai02BkXtR27nRJ6+9JLLzmS LAgT57nOEzGoulhrDmP+hpoOws3P5SDvIE0gT7yxmQVkF7vdQmSx3hvnIXIgid5//31H+lEGhGCU so/NFj788EP56KOPHAl4//33uzqhHoQ4Ii11YaMPwlap8z333OOr4AgsdrKF0IP8Q2UGkXjmmWe6 DVMg/GgHOxSzzhsG6UiaVBNMKAzZ0INdZFHntVeVIQQl/UM7wJedeP/5z3/KmjWFAqasrKxiZGW8 cfqBdoAJobuQi/QHxCBEKfkmMtb1o99R4PGC3KIuEH6QfZzHPzzxB37JjLIgDcEM3xk2bJhQd/rI KwN5J6w7iGufPn2coo5wcAhS2oLvQpBSH8hI+hTCbZES2u+9955Tj7LDNHmn2sAEDAif9j5L2/Bv fIx2+Y1pICF9eHkq6lEujEHt2nXl3Ktukf/c90vZvi1bvhr2lqxRFV6nHkcqcdZQVi2eL3NmTJBV S+a7NmR1PUyJqP6ukyC6ogxyathbT+t6fSvlkMP6Ksmn8s3xI2X6+NFOHtVMFYYDz7zUMaXKRRVa rJoce8o5Mmvyl7rJxSSnUnvmb7dI7/6DJFNJrcVzp8s4Je78DSVcLpxgbXXSQ486XsaNfE/bslU+ //gN2Za9SXr3O0125GTL3OkTZcq4z1Rpt0PSa9XWY9ywCsmmcH7+OzsGs+5ec13Tb+WS72TB7G/l sT/+TDr36CN166MMjEmmkpwnn3eVNGvZypF/pK0iuhX3lTfLjG++kAVzpso8JSUf/sPV0ufEH2pe HdR56+oafitlpYY7z9dNPdatWi5tOnaVAWdcVqgW0/Yov+Q+Qw4u1jwaN28jXY84VprpjsKNNHw6 d2eOzJk6Qb4e8Z7iUqCkbD05SvOvqnWOJSIAXeXIueLN8XpJ4HbErrtod930Wvo1eKiaEmys+bdF VYL+j8+mxetl/OPDi1znWxfL1xue7jbc6bSe0vmUbrIrxB0rvytLv9TNP5RMRLmZVqO6tO1/yO6N SHwu0e+gCPG6dOwCmfX2JFVuVhc21WZtw126OUlVDSHerOsYTnhihFNokgvrC/a75TRplFWoKo3O 2Y4aAoaAIWAIGAKGgCFgCBgChoAhsO8IoMRi4wc2guCFEuupp55y65ehrILoIVyUDQ7mzZvnyDNI sKAxB//444/jKjTmYRCA48aNc5fxmbwhdCDzMPJgDb8gUURIKrvKQgKiRuOdkF6v9iJUGYMUYiOK qLX9uJ7dasmHkGbWYbvhhhuEtdm8So81677++mvXJgixsKFwZIMR8oDEgWSaNGmSU3NBHo4YMUK+ +uor10bqcuONNzpyMJzPvn4HNzZmob7s7ksIb3slAVEjgjHkH7iinATPpk2bupBnH5obVT6kK2sr ktaTdVx/4YUXRl0eP4ZikPUDIT8Ja2WdRshjdmIGI0hXlIX0L8TeWWedFU8b9YG+QzEIcQfOrI+H j0EuQvziU7Tn+uuvL4ItJN+tt97q+oP1ICHYIDJPO+00hw3+DDGIKpK+J+SWdfeSbeYSVb/SHvO+ QJ8wXtiUhfaDLWtqssYifUObzjjjjDi5Wdr8k11XLgSgepaccPoFSlR9LtPGjZQ1KxfLzCljlSyb tJvky1M1WZ4jzNq26SinnPMTad6urarhElf1sL4nORJvnBJTk8Z85DoXVR+bTUB+nXrh1XLUgMGq RNuTB/eJHr37yWkXXy95L/5Tli2Y7Xa7XTRvmquHq0PNDDlKw2i/UsVb4RqDe9LDK6Vr6CyE4Wyt P+q/zRvXKqH5jn6mDgVOwVdTibdBWj6bZ8ybNt51ViHVtiev4Cfla9yGHuf85Nfy3kuPyiZVNy5f OFfJwPlKzinbo1ZfQ5f7nHC6KhZb6Z2uMDWCuiYt2spPb31A3nz6rzJf8Vy3Qgf2W886BSQ7g8R0 05V8lUDiMJl1G0gDXbewRs09T0g8N5lRu467BpXmikXzlFhKc6pDlJWsSZivcj/IQdY8PPuKX0oe ax7upe0fSjBUyVAlNHA2dIH2lB7Ky1Zf0huGJwC3LNXQ9ATEIv2HkrBlHyV76a4gMap5kc+SL+ep ak/P68UtjmgrdVrrwrLFiy5WFw7ECvQJ09qtsmbqClUvFg5RVxX9zysA1+vagt6oD+SgmSFgCBgC hoAhYAgYAoaAIWAIGALljQBzpqysLHnwwQfl0UcfdYQFBApruKF+4zzzUQgUlGKsj8d70JgzvfXW W25NueBxT7rwDmE2YcIEN7/y16CcCxKAEFFcCxE0e/ZsR5ZAFKGmggzjHVIQsgdSJ8qoL6Qeqqv/ /Oc/rg0QRKj1vLKM9kDQQIZFKbIgmVDEsf4fKkEIOBRntBFDYUYehM1CnLHGm887qk5lPQYeEEoQ sCjsIN8g2XxZkG3gQn2pC6Tb1VdfXUQxF1U2asLnnnvOYYC6DuKqvRKLyQyVG+WgHBw1apTrT/qG F1iACfUifJo6oIgsydi85Oc//7k88cQTTuFJSC/ErJ/H42s//vGPixCAnIM4JHwZn2XH3Tlz5jgS kbp4fwUb2oYqD+Ud57zhr3tjvj6kCX7mOyHR5IdaE0ISDHxZ+Bj9w5p/YPy73/2OJCmz8iEAtXrp Gjr7s9sf0vX1huj6eC/qWnsbXYhsvoJKyG+6Em/tDukhp5z3U+nS6yhVPe0BN6p1Z1xxs3yna/19 88Uwlxdr57FxSP1GTXVn3otl4NkXK7A1CsNcgxlUqS6nnneZ1GvYVD575zlZo4QZSj52HM7QTUK6 Hn6sDL7keheqjBM2atHaKcR8FgWxKtKsVVsNYb5bmrRsq+V/omvwbXMKRBR/maqQ637UCQKZV0Vj SckXy1RWW/0s0nCdmpp24NlXaN7tZaKub8g6hWyYgpoLq1O/oYaMZhapizuhLFL3I/tLm//rIh++ /qSSjqOcynLnjm3KnOeplDTd4ZtZv4F06dFXDut3siMNNVrZGWWjSvvBuT/RsN42slQJwBzFAzKV 9GkqX2NHZso/7pTz5bhB52socr3iuBZm5/4nvzbtu0j33scHjurmIrUyEpJoRS4sry/aWBRzdVs3 kGa9Wku19DS3+QcKwKDxvWHnZtp/uxfdC56M+qyDtUZmutRuUjxknS7P3ZrniNzGh+iO1CoP7DCo p1SvWfQPXlS27hh11mrUblpHmvZq6RSACa/1J7Q+aWxoYmYIGAKGgCFgCBgChoAhYAgYAoZABSAA YQGBRCglpAxKPEhAQjM98UdYY5YShYMHD3bKrHC1IH5Y72xvLBzCe+211zoCCTIF1R8ECuVDPlE+ ijB2sj333HOFDUwSmV/rjvqgZkS9R36EzELWoBIjHJS1ARNtfAH59Kc//Ul69uwpL7zwglM+kh6s UHNB/EB0Qf5FrVmYqG57cxyC9C9/+Ysj3CBPId8glMAFcot28AL7yy+/XI4//vikYby+bBSOnsTl /bLLLouTVv6a8LtXVo4ePdqpEiFYqQekLHlQD0hECDvUmT7/cD7B7xCcELn4AWo91tPz4bJcBzkb DBH3ackbkpe++fe//+1IQ5SZvOCBSMMLn2bNQPoo6C/4BWVCJHqyDmKP4ygag6Qw+UBSgy3qREjQ oOE/EMn4LCpJiFB8FiIQTGgjYemsvRj292A+ZflcRZ0ZTihlNny+yM6Akq9AwWRtODbwWLNqqZJc 2dKwcQslpVpL3QaNC3fDjSBeVKAmt176Q5kw5kNXt/v/O0q6KVlHXssWzNJQ1zW6rl0naa4EWpp2 JmvmJbOY1mOXSgzXr1omSxfOlnQl19p3OlRJwHq6dh6LThbGDeuKay6/YnkpTLt0Q4zNG9e5XYG3 ZW/WsrN0Lb92TmHHWnP5bBCym8CDSPNqvmJ5BQ6gOgQjuoF/3lCqkYdjg/zB0DsqvV26ecXGtctl 9fJFGpq8VYnORrr5STPdDVkdXwk41hmMqkdhmfmODCVUeJNuYJKTvUXxqOP6p2Gzlkr81XXKwFCx kV+pSwFMYMCqsz0wC/GVk5XWden7Ag3b1cpoX2t9VCkZtoJd2gchYjB8TfA7OVSppr2kBGOUFeQV 9innICETXReVlmMoOQv0RZ1LY9WqV5Vq2q7Tu5bu+tLkadcYAoaAIWAIGAKGgCFgCBgChoAhUBIC ECiopyCbUADyDimCionQRkgNT5oE8/JkUPBYSZ8h9oJ5UTYviBQUeyjefPmQMoRZQuQE0yQrgzkm ZAx1I79FuiYcbSMvQk8hZMgruMZcOD/qQx0IxSVUlfZ37NjRhSZDDpW2LuF8S/vdYwIxhhKQkFbC tMGO/oCYox1hLJPlTyg14de0C4UhoaolrY8Hlr4urDcIQUxdICT92naQpmXBxOfreBQtxxukHGRf WHXnzwf7lzBolJqQtIRle3/xuATz8L5Kv3Pen/PH+U47MF8G3FD4es77ukMw0z9gw2Yp4EnfgAkE sVdtkiZVVu4EYJGKBjomoTxud4IoArCHrsUHoaWIFl6lIJfJ9nf6MlW6hES+TVxWFlz2NX0J1Uv5 aXWDlROXqMJOSccS3SB4wZ6bQ9E6Ba8peib5t9Lml+i6RLnvbX1UBahE48VnNJeMuqYGTISqHTcE DAFDwBAwBAwBQ8AQMAQMgfJDAPLDmydJ/Pfyfg+WTVmpKD+YZ1ny8+nLkjZVePk6+PxKUxefhndI v5/+9KducwzIqzvuuEPuvfden12p332ePkFp6uGvLa/3YJ32V30qsg7lFgIc2UFlIaaiMtrXfPZ3 +qg27euxg7FNSTBB8PnFXz6Unbp2n1khAtXTq8oJh14onQ5vbpAYAoaAIWAIGAKGgCFgCBgChoAh UOEI7C8ShYaWR9n7mue+pk9FB5alDigpUcahHGSNvc8++8wpIVHKXXzxxWWqVlnqUaaC9iJRZahT RdahYgnAveiI4pfueZJQ/Jwd+d4hoNGx7QZ0ll07gjtwfO9QKNLgtOrVdHfrmkWO2RdDwBAwBAwB Q8AQMAQMAUPAEDAEDAFDYG8QeOONN9wadYR0szMzYdGsYwj5xzp4ZgcmApWXAFS+jw01qusuvFjV KsnX+Dsw4bdalxUBVR7LsTefXNbkB2U6liNs3u6gbJo1yhAwBAwBQ8AQMAQMAUPAEDAEDAFDoIIQ eOedd9wmG6jTWIuONQMHDBggd955Z9L1DyuoelZMGREoFwIwFVo9lnbr1KOPxNThCnR3hkzdlRZL Rd5lxMqSVTIEdM8VsyACSgCaGQKGgCFgCBgChoAhYAgYAoaAIWAIGAL7gsBxxx3nFH8QgOxKy+64 1111hZ9/AABAAElEQVR3ndtEZF/ytbT7F4GUbwIy4juRXCXv9tVY0m7r5o2StzPH7S5bv3FLpwjc 13wtvSFwsCLA5sandj5YW2ftMgQMAUPAEDAEDAFDwBAwBAwBQ8AQqAgEWPsvJyfHqf3Yzdns4EAg 5QTgnLUieSkgAIFXd1iO7/CqIsD45r8HB/TWCkMgtQgwXg5tmto8LTdDwBAwBAwBQ8AQMAQMAUPA EDAEDAFDwBA48BFIOQF44ENiLTAEDAFDwBAwBAwBQ8AQMAQMAUPAEDAEDAFDwBAwBA4eBGzVsIOn L60lhoAhYAgYAoaAIWAIGAKGgCFgCBgChoAhYAgYAoZAMQSMACwGiR0wBAwBQ8AQMAQMAUPAEDAE DAFDwBAwBAwBQ8AQMAQOHgTKZRfgZPDk5eUJr4KCAt3Uo5pUr17dbSudLI2dMwQqGgH8c9euXe7l fRV/rVGjRkVXpdKXx+Kwa9ascQvENmnSRGrVqlXp65ysgqtWrZKdO3fGF7yl3yuTxWIxXQ+17Puh s5MXr4PVNm3aJFu2bHEYNWrUSDIzMw/Wplq7DAFDwBAwBAwBQ8AQMAQqKQLMIRPZwf57PFG79/U4 mMIl5efnu9/6zNPS0tLKxCcxn8rNzXW81PeJk6oQAhBgly5dKtu3b5e1a9fKunXr3ASbiVn9+vWl WbNmws4ydevWLdeJKY5CHXinkyEqDuaJ8L4OsO9jem4oK1askNWrVws7H0EmQATWrl1b6tSpI02b NnWEQsOGDZ3vJsMIX8P3ubmQtrIRScnqvjfnvv32W3nhhRccYXbNNdfIkUceuTfJK9W1/FF59tln 3f2qqu6qcu+995bYzxXdgIULF7r7aFnLxRcPPfTQsiav9Ok++ugj+fLLL919/oILLpCBAwfafb7S 95pV0BAwBAwBQ8AQMAQMgYMDAeZ+K1eudPOJRC2qV6+edOrUqUzEVaI8D9bjzMU3btzo5uXMz/m8 efNmN0cHR17wSc2bN3d8Ukk47NixQ5YsWeJ2OEb4wXdEA7waNGggLVq0KCmL+Pn169e7eRl5wCsh FjrkkEP2at5P+xDTwDvARWBwDW3atImXk8oP5U4AZmdny4QJE+Rf//qXLF++3DWMDqNxEHBMRgH5 +uuvl9NPP71c1UM4zOjRo53TtG7dWk466SSpWbNmKvG0vA5gBLZt2yaTJ0+W//73v/LNN9/I1q1b Bf9lUOInGRkZ7qbQrl07OfPMM+XSSy9N2tqvv/5aIGtIf9ZZZ7kbU9IEB+jJGTNmyJNPPulqf8IJ JxzwBOD//vc/mTlzpmvP7bffXukIwP/85z/y6aeflonU4gdJ9+7dnY8foO5WYrVHjhwpTz/9tCPe 27dvLwMGDNirP8IlFmAXGAKGgCFgCBgChoAhYAgYAgkQgOcYOnSomx9FiY34PX744YfLQw89VCrC KkEx34vDYAVZ99prrwlza0RlzNGJQEPUxfwcoU5WVpbw4P+0004TItKicAcwiDr4oCeeeEIg/yAT EewgRIN069evn/z2t791ZGAygCH+IO0+/vhjGTZsmMuHMiEh4RLguEoy/IQ84Avwl3HjxjmRHOlO OeUUueeee0rKokzny5UAJAzrgw8+kH/84x8yadIkV0GApaN4oZCi0dOnT5fOnTvL8ccfX64EIM7z z3/+0zlOnz59pG/fvkYAlsltDr5EKL8YvH//+99lypQpzjcbN27sbiiQf9wsuEnMmTNHxo8f7244 JRGAr776qiNqyBvSBfVgopvRgYxoUNkY/Hygtik9PT1e9crYX8uWLZN58+YV8yX+QEJY845xj0US HzTOHewPPWgzT98I4z4Y/DHYf/bZEDAEDAFDwBAwBAwBQ6ByI8Dcj3lj8Pc6cwrmk/w+xfit6tVe lbs1+7d2YPTFF184DgdMidCCXENIRkQnwjIItGnTpjkBx+LFi+WGG26IJPAgDEeMGCF//OMfHTfF PIH5PvmQjjymTp3qCMQrr7zSCX/CrYffYi5GxBGv2bNnO5Gbv65Vq1aOUPTfE70TcQiv8N5778lX X30lc+fOdUI5f315qf/Iv+js0JeYgncmmoACwPPnz3fAduvWTU4++WTp2LGjI1YAmvDBiRMnOha3 vAcBCi/KhAhEdYgyy8wQAAF84sEHH5SxY8e6Gwshkqj8IKYhhAgJ/u6779yTBwY9N5uSjIG9YMEC dxlPKRgTlZFQKqkddr5yIYDKkj9YQXLL/6gYMmSIu5dSY5RvyOGDxg+SLl26BA/ZZ0PAEDAEDAFD wBAwBAwBQ8AQSBECPIxmSaRzzjkn/jCe3+1EmkEyoTiDdLJ5YcmAM3dhCTnm4kRwwuEcccQR0rZt W6fag9shMgoyjbn6Y4895pY6IvoOjIPGHP6uu+5yYh/6g3x++MMfOuUffYOaD5IRTgAi77zzzov3 n8+HZYY4T7QYYd70NYpD6ojBG5TUr3ACzzzzjLz11luOvIRUhNRkeTzEHFi47u5giv4rNwKQhjz8 8MOO/ANgFHfIGFFC0TjAgpBDPvnZZ5+5SSvHSmNlJVIA0oNJnUpbXmnqVNZrytqWspa3t+kYdDDt B7u9+OKLLuyXdkKQcPPAVxmM+ApqVQYksmNUrTxBKMnwL24A9DF57ItVJj9JVV1SlU8Q133Ns6Qb drCs8OeKGivnn3++DBo0qNgfF0hmwl95px0/+9nPXHhBuJ5BhWP4XKLv+4pronz35nhlqMPe1Neu NQQMAUPAEDAEDAFDwBD4/iHAvI/Ixp49e8Z/r/PbnCWTUAVCAJqVDgF4CNbmO+qoo9zyWwgcUO0R 6YSKkvn5D37wA7nzzjudsIzoUkJwTzzxRHedL4V52ocffujIP/JkmSC4qaOPPtrlAxHI+n+EZbNs HaIKwoEhHYNGVOuYMWPc/B4SEmEbRCIRr6U1+h8lIkI4eDHWDKQsBEnkXd4itdIxbqVtTeA6APZh v6hQ7r//funfv38RMolQNDqUDUAgAwE9bBAvfqFHZLMQL7yQffIiXjuscvF5kBZmlusZdDC6XmWI /BYWGALSG9cQQ55s4UecB8eiTtSHDsL5qAv1YBHKkowFHmGxmahTH9KyGQrsMTHtkKc4JvVIFq5H /XF62kkbITfJCxzJqzQGPmBPu1jbzqvdaCPOCU7kCRFGfcCH45yn/tSPdicjFcCJujKB54bYoUOH yKr5/qIuGO+w75RZ3oa02EuyWY/Sq6x8ufQxfUt9UAX6a/15/IA+BUv8iBefvYEXTyWCBhbkF4Ud WPhFTvERMKQO3tfwF25+UQbO+BD1oQy/YQnfUS76elEu5ZNXSYafMX5IS13wCfDAzyijJKM9fhyD HXgFxzH+xZoJJRlpaYevA/UnH9SW5M95iFfGAvcWfDOK6PcLtuLD4MUfEXDiRd+VxugXygVT2kMb GQ/gQXvIC4xSTaDTLl5ho/xgWdxX+cNUGmNMgyt4gAVpMdqHH4IruIAr7eJe4B+m+PzpE9/HfKZf MH9f8v5SWnzB1N+fyC/Yt34sRvWtr0+yd/yZtlEXMAPP0oyDZHnaOUPAEDAEDAFDwBAwBAwBQ4Df l/xW5RU05m7B3+rBc/4z81/mzfw2Z67Gb/KouRZzS+Z7zGOYD/H7PWj8zuV3PcZ8gOv4rU8a/7ue OTbzr3A9g/n4z3AUzJ/8XJDj1A8Ci3lB1HzWp92Xd9rOun6QbHAIzLGCRvmsl8eeE4QCw7OwXBf1 Dc6VmUu88sorLinztYsuusgRh34+w5yCOY431gkkLBdsg3MXcCQ8N0vXHCSPAUpIMv/ZGwKQPJhL IzpCJHfhhRc6xSjkIwpD5kDlaeVCADIxZtMP3gHz2GOPleOOOy6hw9NxvMLGbsGwoIRlsikD0ko6 D8NRcWZUWpdccoljXyFHggbhAvGI8zPYGCjkiRGWfMcddxRxVq7BuZCGRhkOz4YH77//vqsTk1Pa SN1hh9nEZPDgwa5eQUcJ5sVghFEmPBrJKpN2nJNykZmSP+3FGX//+99HhuuBwaxZs+T5559377DU 1INBDIkHk40j4ZjeqYN1CH5+7rnnnByZ9H/5y1/cKdau++STT9zEn5sQg4Twbda8Q8qMk6OYo54M iptuusmdD+Yb/EwsPVJZCAFuYqzDGGW+v6gL+HFzoi8YGOVt9IsnHmlrsptzFPkCCYTP01Z8npsV nxng2COPPOLIqKBfcAMjRJ4nB0Hj5spTARY65QUBwx8B6sSNCcx5CoISjLThuoIzi4iiYoQgxyeP OeYYt7st44inC7QVcowbF/kkW5+QcYe/vvvuu+7Gyg0VsuSwww5zm5vQT8mMMQfBir/wUIBxiA+D DeMYn2UcX3zxxW43rPA4DubNH0Taxfjlqdovf/lLJ/l++eWX3c2eMQrGtJsnP9ddd12RMQQ2jDvG 4PDhw+Mh2oxfntQxbrwfBMsNf6a/6Zs333zTjR8wIW/6gvFCCDn3PfLjj2JFGOUHLfw9eC78mXsI /st9pWvXrnLjjTc68o0NUeg3fiyAK/cY2gWuLF7sDUIN+T1+h4SeHxjc2zAeSIAv/sI9jqdcyfqY NPg84+f11193Pud/xDCu8JlevXrJlbo2B/fN8A8e0icz+o7+R3ZPf+F/P/7xj919M1k6O2cIGAKG gCFgCBgChoAhYAiUFYHS/DbnNzXzZngGfj/DBwSJKV82v5EhqSCLmE/ymzhoTz31lAs3Zl6K0g1y jN++hK4yF+M4Kjjm9iVtVsn8i7npqFGjnIKRuSHzODgM5g3MJdlbIWqOHKxTWT7z2x+SMplQhGuY GzC3hgCkfuH5KctyQQxicDfBEGH6hfkLmHpD+MK8GWUecztvhHaDG+2F12BuBH+zNwb2zIloE/3m BSvlRaIWq5t2XspNwyRjOimD+YgpwDEllMpUhrK0MWVGY9qZMZ2ouTzVsWJKVsR0gh/TSWRMJ4Mx lX3GNPQtph1dpBwlD2PK0LprdBLq6qKTWFcv8iOtEhnxF9fo7jFF8vBfdAIcU5IhppNfl047zqVT x48pgxvju6qhYtdcc01MyYmYkgg+qXvnuw7k2K233uqu43pelEk9wEkJiJgSOzHt/Jg6Wuzzzz8v kgdf1EFjSkDGlORzadTh3bveGFwaJfxcnjqYYzoZL1aPcIZnnHGGw5F0SijGlGF39aHvwJd6+M9K cLrkOoGOKTHn6q9OH1MSMaYEVTjr+HclaRxG5AU+iUwJGdcWyuVFnd55551El6fsOH2jhI1rJ239 05/+FFMScq/yV1LNYYdf4lP0B31DfrwYD0Ff47MStDElxIqVo+sPxJQ0cn7v+xff4gXeYEP+5557 bkzXz3Q+EcxEybXY448/7voH38KnlSxxY4axxDHGAS/y1D8KMb1ZBrOIf1ayN3bffffF9AblyqU+ 3mdpk5JALn/fTr1xxtP6D2+88UZM/zi48pON44EDB8b0j0uxcezz4V1v3DG9wbu2MRb1SUlMiaX4 /YaxiN9QHzDSP6Dx5IwdXR8idvXVV8f7hzb4sQMu4KR/bOP9xr0sbOD773//211HetrEfQmMuB9w jDHMZ13eIJy83L4rCRlTctjVnb5l/JfW8CPuKdyTeH/ggQfcvY77ElgydvE7PnNMf2gUyVr/QMb0 j6DrY3zE44p/cT19gs+feuqpJfaxkoeu3zp16uT83Y8B8CQP6kg/q0o3ptL5IvXgy89//nOHP3Wl HfrDKH4N/szY0D+0Lh/+PuD/YGdmCBgChoAhYAgYAoaAIWAIlBcC/C7ltyy/UZn3q+ijWFFKXsU0 2sz97laxQyxqLkIifXjtruH3ue4gWywf3XfBnWfuqJtcurkY80DK97/v+U2tgqrYX//614TzL1XB xZjL85uZ39/McZj3MH/i9z3H9OF+TMUuMX5n7y+Db2IuAra0WYVFRaqiuwi7c5xnXhrkjeBorr32 Wjd3Z97B3I7rOMa8JGgqNompyCF4KKbrOsbzVpViZL8GE8A9wC2F+Ybbb789PodR4VUwSUo/l4sC EIUNKi4MJvOkk05yn/f2P1QnqM104ic9evRwbCvqJ51cuvAtFDjsvAIbzbXE1QdVKaialCRxCkB1 cLd+G0w5zDoMNXJSndjGq6Ud7pRI8QO7P9AW1C1sCQ1jro7u2GDKoi6LFi1yjDLtRjGjA9EpD1Eh eSMPVEpsOU35Oviciot2wVDTFphnPnvsop4SwF7/5je/ceGkOsl36iYUfzoInbIJpnqhMvyEYJMP mIBZIuOpAeoyDGUeOzKTF2y+Tt4dPijGYMHBWL3PseYoyvTm4Vh2sCH2nqcUYYOFpy6ogcCK7bkT GXmjDAvKXnWAJLo8ZcfBEYxQP1EHJazcZjWw+/gJ/V2SgYUSWE7tha/xYq1AsMNQo1EGZWGUw1MK 8g8bKjZUc8iLUSdlqZITFZnejJyv0cesH0H+qAVRodFXQcN3wJE+4zr8XAkVNz5oD4o8FkvlCcmz zz7r1pRDaenr5/NC7crOyIxD2sjTDpR3+ClPUXiKRD7JDMUVfoBfoYwDV3wFf8CvUI0xjhmbKOnw 2fBTLJ8//oC/0jZUYX/729+c2oy2kT+YgR/5cp78vNEG8mYc4o88bcFvwZaxyw5M9D0+mMwY73ff fbcrQ//AOHUz44HywZvzLPCLCs6P5WT5VYZz+CN1BVfUgEjQqT/+hzoTXMEFXHkKyD0saPQJ13Md cnaUqfg7vsa6mSg/UW3qgxrncy+99JJTDYf9jTLoI2T0+AxjhPssPsdTMsrF98mLJ6P0dWmN/ke5 /Oc//9n5M0/t9A+7UzDj22aGgCFgCBgChoAhYAgYAobA/kTAz4f5bc18K9FcmPO8sKhr+F3vr1Ex h4tOY77C73R+PxPhQ4grc1UV3DheBBVd0IjI+cMf/uDmkvwGJ/qSiB6i5cgf5Rv8BfmgWuR3+1VX XRXMokI+g9mUKVPim3QyjwzP35nfYPA9zG/gazAwIiqM+SG8FW3kWuaQ8D4+jNpdrP8xf91XY/4D VvvLyoUAZALsHVGZ4SLx13vTUAg8Vag58gRyhck2xAqgMVFlIggZBpmBAzJ5DxKATEL/3//7f45s oVyIBq7DgSEMVOlVrG7kHzYINWS0TDipA6G+DCTqBynDACBkFvktYayE5iKFHaAx4ZzHmDgzsaVs HJJwWsJbmXjitNSL+uCAiQxMVXnkCAY+MzEnHJI248yQGvoEwA1UyA8fokiYpK9HVN7gSR1YiJIJ PJsHXH755fGBg+MTAgreGHlBXNInb7/9tpvUMyGPIgD9bjqkY+28ksjgMCFAuoowwmRZOwDSAULr Sg0v5BjrVkJYQdjS37xHmarHRJVH8XXPuAbigxfY+nUFg+3jM/4UNghvVUq50HZ2zYa8836J30Om 0KeQZqwTwA2chUvxgbBRNmQg7UD+TVswdt7WpwzunRs/eeJH/mbINZBZENYQJ5SPRJwwcW5Y5MvN njB6NvFJZpCTHkvaQ3o/jqkbY+bXv/61C/dnHBCCnogApByPIUQU9YAApx68U3+OQWwi4+YGjzFe wIu1HxgnkHX0F+Hr1IUxzIKxtC8ZqQT+3G8Yz4wDSFPGO/nxnbLJCzKZewIk04FiHlfaBl74gyqW 3XqY/kEJZC4Y0t6g0afcDwjjZowzTnwfgxn9+rvf/c6RxoT2qrrZkYT8ofUGduD26KOPunHIH1hC qG+55ZY4sY6/8GNolD704d7j6+XzSPQOUU7/Qv7xB50/7jfccIN7GfmXCDU7bggYAoaAIWAIGAKG gCFQ0Qj43+T+Par8ZOe4nvO8+H3N3Ach069+9av4XAnhwy9+8QsnHGKOxEP6IAFIOrgVQn/hL+AI mG8RugqXwXl+UzNXZKkr5rxPP/2040l4aF+RhpCD+Zkn65iThAk25jcYmHgBjp97sAwSGLEHAKHB qoh0bWMOzLzjoDNteMrt3nvvjYc/IgktqyngLjSL9yhTxjam6icnudTOdKHAOnGNutQdI6QWWaZ2 YkwJkRgS25JMJ/MxdWYncaUM5LrKdBcLraWOhJKps7n8lUCLqRO67MmDMFklCFzYpZIbMSUvihSt k2TXFmS11I+XTnKLXKMsdEwJDXdOiY7YCy+8UCS8jYuREutaAe4a6ktIb7J2cp7rKI+yleiM1ztY OO3TwR8/RH11wLt+pl2EiSpxEj/PB64hTFWJANd2JVeKnA9/IVxSJ/0Oa9qnhFaFhABTDyW7Yko2 ODmzxx88COnVG15MbwYu3FRJ1Rj9UBojDNtjS9uS+WYwP7AmzDqR34PrbbfdFg97vfnmm4uEYKuK KqZqTtentIVQSspX8iReDHkosRIP61QivZhsm1Bk+oM8kFSr+jSeng/kwTWEznrMokKAaYf+gUjY HsaHrsnm8gCvAQMGJMSKsFZ96hQvT0l+F0ZNHkEDa8af3szdYcpX8sf1B/5K6HtYds+1up6o81ff Hv1jFsw2Bra6y5QrHx9FGh5lYEP5vFeU0UZV3cVx3JsQYCW/Y7qmRRxX7jPcf6J8kHb5e5tvG+1U 8jzyeq7hPOEFSgy6Mi677LJi+NOHSry784x9JRJdnlHjhnu//rGPDN0NhwDrH/yYKkVduAN9j88Q phBug2+LvRsChoAhYAgYAoaAIWAIGAKpRqA0IcDMMwnLZS7CUmj83o0yXcc9/rv9vffeK3bJiSee 6OY9zK00gqvYPF3JLbc0GeXwu1vJwSJ5UA94D347E+rLb2fmy2EjRFaFKK4uSqw5fiB8TXl+Zz7H nFYf6Ls6qNglkqvxcwzmbyoCcFUCA+bUtF+FPrH//Oc/bnkhH0qsgqfI5YbC7dnbEOBwev/9gA4B Rn2jDXEMq64Xpn5VNtMOciy1TgBdSCTMLCFiSDXJH0NlgvEdFprzYcmnuyDiP59HxKn4IaSvqFV0 curKYvcZVI2EPoYNSSxqEuqB+k4nve4SVCuoD2kHihXUWGFlkDqeU9XpxNspq8J5853wXBQ4GAoc GGrSBQ282QmHEDqd4DqlEgorVGUlGYpCNoWIws/3hc+DctmIAnUXjDqhooRbEzrsDTYedRo4UN9k 4b+kIS8Un/Sv3qwcEx/Gyeed6neeEjz88MMu9BEVJm1CNURfooRDUYmii3BRXcfQKTj1BlPqauBr vGhXSeaxBjfGEoo0MMEHvc+iOPS+j0wZ30pkWVlZTkWrN/D4JfQf8m38hdBNXkr2xM/zAZ+lXNKx 8QP5BI08kJHjz4QZJzLfHuoOpvhlqsYxalV8zmPh6wDOQT+mHwmdpg6MUdoTVrExNlH38qQLPKIM LLwKlP4gT56a4Rfky3nKBptg+VF5VeZjV1xxRTFFqK9vVLtoLz7JvQ4VLXjjT7y8z5LOK/bwWXwr aPg7YwwDS8YZeUYZ92CeRJY0nvTHi+gfc6fs5O8HKmWUiIQn4JdmhoAhYAgYAoaAIWAIGAKGwMGK AL/RmaOHQ1dZqgzuAuP3O5xH0IiMI0qMOSZzHzbx85Ftwev4/c68irmgn28Fz5fnZ5SJqBSJ+uIz fAfRS9Q1OEdgLsL8BOM4WNAuIumI0GQeCX/CpoAst8Y8A/PzGfflIPqveLxrChpHWCMTYZyJiX5Z jc6CeCEEl/XBcEImdJAInvBgUueNY0w4oyao/pq9fYesoHwMB4ccwvlpmzfqiTP5yS/HId1oO8QS 5wmLxqgb4Y1Bp3Qn9D9CTCHBCK2MMtpPHTBCcKMmx+RLPoTbEtILeeUlr1F5Bo9BKEaFpAavCX6m DOpB/qwHR5gfx7jRYAxGyseQ4maFCCR3IvAfebE2WNB8XsFj5fUZspEQUMJj2X3ah3pyQ4SI4yZA P7KzND7BtaUhVve2vvgRBBTEkvd7yof89b7Gd+/7/j2qHPBjLbYoHCH//Fihbd63fD4QuJTHWIbs jfJZSDTWZ0tGAJIH4fPcUGkP44dxzDqHfhwH7xOlHce0iZt1+A+ar3/wnfwJGcaQfbMWYZQR9sof xGQEINcwrsGMBwHI6SGu8X3yZlyCOfWKwiyq3Mp0DFwZr1H3l0T1pM/wSXyWcHLC6OlfjuHP+BDj yP/xhfzDL4LGOfwCgwBkjdZkVhps9Ymo8zvKo12ENrC8gZF/yZC1c4aAIWAIGAKGgCFgCBgCBwMC /F5G9BE2fpsHxRDh+SRzXUg1jDno3Xff7eaNwd/v/rMXKPF7m/leRRjzVoQDLB3E3JJ5CwIGlmGL mht6Uo+6UU/4C/Y/oO7s7MtyXaQjX98u0kTNoSuifeVZRrkQgKyvhwEeEzreSzNZCzaUNJAFdKqG ornOoROYePPySpKgaok0nlAI5rUvn1Ffsb4d5h0HUpKyooy1pTDqgXP5z55EhGFOFBeP00U5rMtE /2NAeZImar09fx3YUAYEICQF5EtpLOrmkCwdTwNY2w0VFJN7NkBhkwjqRr/79daoD2s1cqNJZviI xzjZdeV5jkFOG3hRZ24O9B2EBsowDVV1ijzWH8PPWUcvlYbf8MQFcpGnEpAirJMGIfL/2bsLONmO Ov3/zQqysLjrxd3dLx5cgltCIDiLL7KwG2SzeAgWFg0WXAKB4AR3dw/ubrvssvub9/nvd/51657u 6Z47c+/czlOv18zpPn1OnapP+XO+VSXfEy5wki8rr9dxLByuJyqPOawrTVrrwrqW2Mlv19kwY8wR EKf95nrlhJhqrUprS4gP//pyXGWlntEK7HWuP5bVXX9+7Lt6QuPAyY9tg9der9zgPc3JH1e84hUn K9OAh81T+ClfeDGgbGPBMo3If8Mb3nBYS6JE1ml+brXz8ku7gdFa4ZPGhFBrTKqzCX/ynbqMyIyn PKsTUenaNq7lv/X/6nf5fVoa1fXzHAmSFRYvc1i12ghkZSfonaxG5/Ev14RACIRACIRACIRACITA 3kLAWI9x0JhrZ1D140m6Ax2B0y831q9x45hfZoXxY9q4c+ye9Z4zrjP2MqvHON34zXqGZoaNGecY h7QajXH9ynTsydvf/vbh/Mo04GFGm/AwGjFm4Izr9rZx3BDwNf5tigC4bcXSC2jOwJ7F3lhizAqb RReJf6aWGhSyurFjpymyMmEN0glNFvLnNkMAbP00mGUaanDv/CynAJQFjWurgOEy7d5p5+s5a/1e 1zlWAXVPX6Db69rP0qjua8/P+myzipVttYcpzyzmajMQYg9xxPNZjzExrjwxy7+t9BuxhyWXP6IP UVCF89rXvnbYGIOYIH4bGS9ircVUjzzyyOGNw8r6DcP0XZUp0awEUhaXpjYSVWalr7CJx3pcxc1x Wr7g/6z4K8fPfOYzJyyxiD4ssFjtVTkuIV8dca973WsIpuf5W8sRiKpcrXVt79+0ME873/pP2Lrr Xe86CH12viJcsc71YoD4ZXqrqe8EeJsQWVB2Gr/W363yWT1HNJvXeXNm8Vwm+OKpA2Aq9baVdsBL gvLLzsjyLKvAsTzbp9G8z591nXbCYsXqNhsoVbvCWnN7s0nTLD/yWwiEQAiEQAiEQAiEQAjsKgH9 3+rvzjPmmPW88mfWNfXbvOOlut6xDSsdZr/99ls1wGqvaz+7Z7MFQNqS5dlW1vcexD99/AMOOGB4 uT9LbyoRVBhtSGjXYGNr06MZNJUjANbMNGPNCIBFZo0jhZXowKpIItllxvTSRRyBwyCaH9ZaY2ll B9HeKsQgez1u3kJDoDA1lCWYwSQxy86UiziDYiISKxnx4deYY3pbivPY7yyeSswhNExzmNfvxIra 6Wba9XW+xKX6Ps/RHHs7oUoHA/tjVqw1fbedOHFK5bay4P+qYDvLT0Jva34sjYS/4jzr3s3+TTxY SK5sEjEIgJ7Hms0U5xJ6Z4Vh3vxGQCWWcUQKlmbWVcChdZ67nsq89WOtz+36i+I65lSQRJVpznRq 5V+eVC94w0LI7yto08cXdfLrvMKasqvi98JAGaw3Wv0zvd0S1rWcesjLAAK4KftEP+XaOp3KgHQk iJsGb23NzW4M1wrvIr/LV/Ny5S+mXgJwrH/tMmZKdG8Zys8SA4eLu3/yh3KmrKgH1B9e9uyKI/Ip Qywa7WLuTZ/0OuSQQwYR2k7xcSEQAiEQAiEQAiEQAiGw2QT0bwlQnLHdNBGwxr76xDU7pg0bP+YZ r7T3LPqZ7iCMXvQbx3ihPs+Yd9HnLHK9MZxxpeW4zDBjtGDar+m702ZYlv81rsWTwY1xyRWucIVh zfFaAg1vRik1w9R4tYxVyp9lOM6ek7nOGMow1nPjCAQsQ2rq6rxesqwxzZGzyYABZS/+8XMRAVBh qoImA83jZAgbf3BEF2am84o55b/n1oYRCj6RYMwR0GS6ac7UwhJ9rDFYmbO/XkGt6Y4G0GsViP7+ Rb4TYa5zneusbmpiLThTIk0LxlheIJLMIyiwoDr88MMnKzsRD38W5Tx2ZRrq7nBjlWv/XOnYiqkq 31n5etH8Jl9hIP04b1sIGL34V28u6u1EH86N+k6QkW6ex1R6zBFp5MVpztsV13BVjnvxD3vWYZvp CE9EeE45ZrE35gh3s0T4/h4NIutQm+ewRLbw7MrOUqsbhZjOTSBbVld5tuotovWtb33rncQ/13kB gv00p56qqcfSQB2yq44FLQFW3WmagLpcvUSkVc9ME4J39bm5PwRCIARCIARCIARC4LhDwHhmrbGZ /nIJd16UGyv2ztirBCnjzLG+M3/Gzvd+7cp3feZ6EW+sV+PTXfFzV+7FgoEY8Y/WwLiDkZGpv/r5 azmbRrbGTsb0Bx544Kpm5X46jZldxgo0I4YCNTZZy/+96fdNEQCZStplkVgFIDNNCebzmCMQsLxp xRSFg/DAEf5KuGvvt1C/tdjmdVTrEtCIbWsVUv4yDTVtUQElSJr2WeLa2HOFmbVU67eCzCqOH+Jl bbfakKD8UGkQBlkSTXMG12WGaoMGTHsn47K6Ej9O5i7ho792o75f7nKXGzZVEE+WXHbTrXUHTQWk uI+lX/98Yp/5+HYw9vfkJz956oYo/b27+l24iUIlOo/5J58SpsupEKpirHPt0fTHym/SdS3hWN4p sYw/3jiMNQzWZLDLdDUg7TM38jMRX/iFy9sWZbR30kxYpjllvi3H8kjv5FUvCTbTaUhrh2oNprKj rLQOT1PXZ1k0ut59/b3lj3Uhrf1XLys0lpudTvXsPXGUp/s8q0HunbLFonuWuOo+i/ByhDkbAk0T 6DxXPTutTann81P+U/9c+cpXHsRZZVaY+c9SedqLlPIjxxAIgRAIgRAIgRAIgRCYRcBY761vfesw jhgb8+lvMiQqvcP4vMaJrb/GfjVzSL/ZDJbeMTBgNLKZzriJ0YY+tLGnZ84a04ifvnnFbyPDxk+G AY9//OMn73jHOwY9xIaFjC/KyGqt55m1aONKTpy2rSxVdP3rX3+H24xr6TScNGCMU9rLDhd2X/rx ev+9u3zq11YvaT9PvWGdP+w8Gl+nR/1t5lOzvOCIQRKMiGCwbwBOaCEoAE3E89cq2ayParoYgUGB UQgM+BxleqIBBXhex8KkFHXiITGPdY5BuoGmv35gL9FZkcg0Mp842OzCdD9xUBCIfe7lp8z5whe+ cLBoKqsymYAflHSDUcqytbAMijGg4ts506YZ0wa84kjdJiQSUYTTWnEKpHAodOLBnyOOOGIwFxb2 S17ykqvWefNyWvQ6lcPVrna1wSxYuGwEIEzSj2XUWOU29gwciavEUX8YzxIMxvxY7zlp+qhHPWrY 5ENeM4VafvT8Slvxch0nbvLEmNhRYbDOXb1psEsR0Za4xF9/RIgSx9yjoBOOSiQTDuUDF/kMU348 73nPG6yp2nvrmRt5ZLFnSqdGjAXgK17xiiGvCg8uwqfczrIAlGfLdFo5ll/dW+VY3WCarIVcN9Mp 98qgo7KicjcdVNr6Lj3qHM7TnDrA1N6jjz56SBvpWfERJ/5oqEsUM+14noZj2vO2+nl51kuGauh0 fsp6u9JYmX7xi188vJioOnEsXvywhgeLV2nCmljeUK9WHad+wZxgryzOehnjGW0HTFm87W1vO0xh 8Fnesz6lfNleNxa2nAuBEAiBEAiBEAiBEAiBaQT0/23iaM1pRj00BuMMfVh9V+NIm9PpC+vz9hZp 5a9xM82AM7YnKvJLH9iYo8ZOa/WBy7/1HglrxvfGMcJhZl4ZhAiHsakj0U9YaDJergvfRjrjXWyt +feWt7xl6LMzuLAmoXGd5/V/xiPGEq1jAHDzm9989ZQxmxlowm/cRnuwDBcthbP2/wUucIFhfL56 0/99wINOUc9tZ3tJX7/V7zWO6f0QL3pD+eH6Gj+6ttK6fqehbdTYf1M2ARFoUz/Nxz744IOHTGHA LOOyFiPuyUwiJEFZhtgkgrVYuRKuCGQGlCzD9tlnn2GwCbLEqbXSFKJZA8vyk8WWhDRtGFRbP0t4 YS2xUdhsUlCO39RfA0cWaRLx+c9//pBA/DL4lcEkoLgo2MLrWe5zv0EyMYgfrONkGn6IB9NSA2WD UJaSxBICy5gzMLZ7Jesl4cCUVaNNBsyBJygqGGUZaM26m9zkJjtNIR3ze1fPSTuFXgVXaUEALgbz +I8TXm3mdm53OMJtTV0WZpWefMGKTwVBuFLpVaUgbiy9ZjnrRRL0VPz8ZrIsz7Aq5aS1PF1TYgl/ nitPyEvyJpHXFFNpL49pPGyMg5PrW1azwrKe3+RZFeWhhx465HHlRSUp7ip9AroNUWalkQ1zWICq tJQ7ZUheEWfnlBUbnhBgxKnyznrCO+se5VudoiFTbgip6hRMmeB7oSAuxEzxmSYIEQA1xERA5Ute 8QZP+eNMIT7qqKMGf4nDRNR+LbxZ4dzbfsNK/LHQ2VFOnvjEJ05ufOMbD/HGV7mRZ9WTOjUYjjn5 2SK8lhTAWEMovxCftQ/KkrqxrJ/VtSwGq5M05md/zts8bwv5qc61CLCOGqFa2YsLgRAIgRAIgRAI gRAIgUUJEG/0LfVTjSvN3KvZewQpL7ZrBiAjEuMSY5/eGT8Y27/oRS8atBN9YkZMxlT60MZTx6ws ZTOtP937t97vxDUzOln+iZdn6qvbk2Hb/230Z1yov+7FfC31Y+36eabkzhsufX/6Rm0M6z7njC/K Wq/3i7ZiSSaz2Wqc6mh88oIXvGAYrzGyMTY39jDGEAdjUuNT41TX0gLGnDSht9Q43D3lMDGT0djd eBJH2tL27dvrkuFIH5DG8ot8IHziU+lqXEX05PhDczKG2Yh1GDdNABTYfffddxj0WWvJwJrJpgE/ qxgDcpZvRDCJZHpWWUu5V4EBHkSFhVUbQYSwRmQy0ATW2oCmcREOCpj7x5zBp/WpJLDwgGwgaPDu N+Avc5nL7CAA8sczbf5AJJABCW1UcJlbIgg/UU84FX7X9wWa/xapJHpW5pIBFWjhdh+zVPFVgCqz 9vFg7mrzAdaPZVkjAxKViILi5dlEmjvc4Q7DpiW9H+33ltk00aO9ftpnSjzrRGEvxX3RxUI9vwpS PWdXwlR+zHMkUhH7CAIqVkKBygBXYrHKTX719oAw5q0DMXuWw8OGF6z/3KuQE0vkW04ZML28BEDn iBDyiR2wlQ1rIhKbiIXyGL7yjHUVNSRE9TYN+cEVR3mzPv9/v/z//7Gte6cJb/vvv/9QXlT6ygqL KfHnrzKokfIGS5ni+mfJF8oxIV9+ZeWqQlNu5PXyg5iqHE+LT4V6njDXtf2REGf3XuVEOnvxoC5R /glVyo6GQjyl+ZhTLoXR2obKHUFW+inznAaeP/KN9Lf5Uf025t9Gn6v05O+iZafureO8YRN/XDWi yokXMwRs5UeerTpW4+clB9bT8psyaBMR+Uj6sJbGlMiHo7pF+slL0kr+6517y/8+P+q4qGftOK3B FV6NuPbm/ve//+rajb2f+R4CIRACIRACIRACIRAC0wgY3+kTG/O95jWvGcYXxn3Ge/q+Jf4Zcxqj G/Ppl/aOZkAXoUkQ3/SDDzvssIkxlX6t/ivrNLoJwwNurM9ffeE69s/p7xvr/xunWmNPmIyPjWn1 zWk5taROjfHoD4TNXgMZe+4i5/T9vfRnfFLO+JG+NBZv1xinMrKhh5Sm4qi/b01wAh12ZqAZsxi3 0XmkkzGq8a9xS81iq+fWkaZlA8Ri2443GA4Z8+MgfIzeiHe9AEj7MbuOviUfCJ+4lp/Gk/SmcsRI hmBbXgAkolCOZRIRJJwxhS0rMQWCiCZClG4ZqRxY4BvgEQYqc4FDSZWAEoZwYFdHA3aDxFZELL/a I/h2IpWBDUzBl0kqA9WxvcdnhfS+973vIHaw8Dl2RTUWJoKeMImL+LJUMTDtLd8kbPlBiDC4NZCV 0Aa9LGhYvsgwRB7xH4uLDHqPe9xjsKqS8bCkOsu0MqnKYduKKk+wJD5hNcu51rPFu+U/656x34RV 3D1PnGRO8RmLw9j9znm+sFTGd058d4cjVhIYVG5EAZUM8UIai4PfpJt0tV6AfCSNZjmNgLcPLPpq url8WvGTb3pHjNIoYEiYkEdUcipeDQvxgiUpP4kgKhlp2Prls2dj6T6C4ZgTJ/lFmimHru3dec97 3qG8EHMIXt5WCI+8Vtayyq9KmOsrJYwImsqH6cJ4agA1Zp7r+URtSwaogJVH5XgsLPx3j7j7XXma dp1re6cuMQ3YW6OXvOQlQ/kXHmUIW9Z6d7nLXSaHr4iuwqjM9v47Z8co5V99JrzKns9+8wx1k+ew nuzrgT5MG/ldQ4OntOKwmtdJTzzVhfhKr3kddqb6Ky/ezhGulSF/yi+BWPrqRMg/8q1njXUQMNSp sZkKS00vXLQZOlPqWr8LK7/wHXsz55x8qzFWJ/dO3Lw4IlqXFbkXU/J1rUHY35PvIRACIRACIRAC IRACITCNgP6zpWxY/+nrGm8QlIyx9T2Nb2giDCMYJOnPjjnjOCIhocpMMEIQ4wN+GivrVz/gAQ8Y RMYaZ4+Nl40P9Z/1naeNWWvsLRzTrPZoLcaVZkoZzxr76JMbMxgniZuxjzGIWWtEz410xguWpDKu XcQZn/S6Dl4MqfhpeSLjbGMTRwyFnfBq/G6cO80ZXzCIaYW/addK53587FrsjFk8fx4n7/Tj0nnu G7vmeCtg/nfsh408J4PYmAJcg22Da4UCDJGRyQ28qKOtkCEMBtfulendL+EAlxFNp5RQBDnPIJ4Y eK81eCXuEA2FgyDTKt4Sguo+zRFcFGzhEh4FW5jERZiILcLnb8w6hb8KDfFRoRQW98rYMhNx55gV ayv3Ez6Z+445HJm+EjCERbjcT6TCxPRTGX8txyJHeDhCzFgarOVH/W4NPYq6sBhgEzNLjKhrZh3x FJ62MG1GRTIWBhWr/EDYIVzgS9BQKKWPePhTuRPhqsId86s/J17eMuDCv4qffCq/yre9k6amG7tP HlNByxPCQoCSZ6U/oVCeda4EFf4TM+RT57yNEebeSXfCh4qcH/LMtAaCxZw3Pu4RHvlcQ+HNinzG SpETDnm5d+5TjgllVY7dL88qxz4Tj5Rjgvj2FYF1rBzL74RILKWH582Tz9vwqHuw9QZNo6rOwVa5 YdVJnFc2nZePWyaqS/lDujgSuyqfyBPCpE4j/GkMK03a52/WZ3millrwDC8AhGceJ79LH0f8cSAQ L+K8iJA2uOLCKS/yN2tI6anjQNBTz0i7lm3/LCKxPOx6+Ufaa0TlGflVm6Ht6BnL09JVOah06NsV 6SicwssJmzIivHEhEAIhEAIhEAIhEAIhsAgB/XDjN2Mw/Vb94hIA9a3pBMbpBKZ5+ufGeMYkDCT4 S8gj6ukDM5xitGI9do4Rgz5x6+gJ+uPuMyYQht753XWc8Zu++TRnHEg/MYOrxsrGCvr54uZ+4TNG 7Pvd0/yc5zytxEt7HBZxNARMxsJC/zET1HjPeMBYuMalxs3Gt7OcMRP288hoxofGuowTWmc8Svcw 9prHMeww/XqacDyPH3XNbhEA62GOBvgGchJTRKit84gpEsag32BPJusHfe0zdtdnA39hosYSIcRF IZvmDEjFY9rAmgmotwIyFOtGa1N5WzDL8VPGkZH5SyDaE07BtOajiorwaY1DVnVjIs6eCN8iz2Sh hyexTj4lUhDgZokVi/i/yLXyGAFEYd8VcXaRZ866tsKjEcFkUYcpP5QT5Xij3mQsGo66XgOmYVhv naI8yysaaXHBxN9YY1PPXPajNFYvahR1AmbVifOyUMfxF2N13J4oi/OGNdeFQAiEQAiEQAiEQAgc twkYv1V/mOZhnL4e/YJQRHTjvARfjx8bmRKETmM5/XLjU3Hzt7c6IiDGxtkbIa7tDRx2uwC4N0DZ rDASPm2UwYSVsKcQG8jKdNRn6xxa9N7A+aCDDhrm3E8TCzcrjPP6SyRTsYkTyznTkU2rdI4FpR06 KelxIRACIRACIRACIRACIRACIRACIRACIRACe5bAzot+7dnwLPXTWbEccsghg4ms6ZamHbIapKAz 47WgJIszu+dYP289Fla7CyChzzqKdgWyZqGpeqyhTH+0hh2LqrgQCIEQCIEQCIEQCIEQCIEQCIEQ CIEQCIE9TyAC4G5MA9N1rQlgHTTz6E0bNv25TGmZ025fWfvswAMPHKwEN2Lq3GZFjymy3YyJlsyb CZfWULP5yHWve93jjAntZvGNvyEQAiEQAiEQAiEQAiEQAiEQAiEQAiGwUQQiAG4UyTn8sUimXUYt COqP5Z81EU0DthioPwKaBfgX3dhgjsdv6CXW9rOTp0X2hd+acBbMtDPntAU3NzQA8SwEQiAEQiAE QiAEQiAEQiAEQiAEQiAEQmAuAlkDcC5MG3MRSz+bDpg+yxLQ0fp/pgFbLJ9AyIpub9g4w6YHdjmy exCx0sKZ1ivcChtVbExqxZcQCIEQCIEQCIEQCIEQCIEQCIEQCIEQWA4CEQD3UDqy/CMImhZsZ0tT gbfylN8ek41KhN2f3Yj2prD3ccn3EAiBEAiBEAiBEAiBEAiBEAiBEAiBEFhmAhEAlzl1E7cQCIEQ CIEQCIEQCIEQCIEQCIEQCIEQCIHjPIG/Os4TCIAQCIEQCIEQCIEQCIEQCIEQCIEQCIEQCIEQWGIC EQCXOHETtRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAIgRCIAJg8EAIhEAIhEAIhEAIhEAIhEAIhEAIh EAIhEAJLTOBvNituv/rVryZ//OMf1/TeZhI2kbB77Kzdb//whz8MO+f+/Oc/n/z6178eNs2oXWfP fOYzD9+Pd7zjzXyeHXd/8pOfTH72s59NfvGLX0xcz4+Tnexkk7Od7WyTE53oRMO58sT1v//971fP CZ8de6c58XWPOJ3gBCeYnOQkJ5l26ZY4/5e//GXygx/8YGCBqZ19sTj1qU89OcMZzrBQ+G0G8stf /nLyve99b/KnP/1pcrrTnW7Y0RiHaeny5z//eUiPRTcQsWOyPDPmsBeP73//+8MOxdJU/pC/Fn3O mP+LnhMeecimLz4Lj12Tpzns5PFFwupaTHrOnqfcSJPf/OY3k9/+9reDv6c85SkHJo42oFnE8VMe 56/n2bxGGYoLgRAIgRAIgRAIgRAIgRAIgRAIgRDYugQWG/0vEI+Xvexlk8997nNr3lGiyL3vfe/J ec5znp2uJ5x87GMfm7z97W+ffOtb3xrEkV4APMc5zjG54AUvONm+ffsgXvWe2G33C1/4wuRtb3vb 5Ktf/eqoAMgPz7/61a8+OetZzzqISO985zuH55aw4vwd7nCHyWlPe9r+EcP3I488cvLxj398Qljj 14EHHjhT1Bz1ZDecJIB+9rOfnXzmM5+ZfPnLXx4VAM9+9rNP9tlnn8mlL33pmXEg/GH77ne/e/LN b35zBwGQ8HaJS1xicv3rX38QvtqoSfevfe1rk6c+9akLiV38OPjgg0fTmQB79NFHTz75yU8O4fjp T386PFc4znnOc06udrWrTS560YvuJJS14dqIz+KGC7H5gx/84BCeEoYveclLDnmo8lT7PPdJk+c/ //kLMSGG4khs5eS/r3/965NPfOITQ9oce+yxowLg5S53uck1rnGNQewdC0+FreKj3H34wx+efOQj HxnERPfIJ/e4xz1Wn1335BgCIRACIRACIRACIRACIRACIRACIbB1CGyaAPjWt751ENwqqiUi+E44 aC2cWMrd/OY330kAJP696EUvmrzqVa+afOADH5iwGCN2uJ9/5adzhBWWa0TA1hH/CHMvfelLJ+99 73sHIcT19XxCTflFzGChRejzLOLNM57xjFXvznKWs0zOeMYzTm5961uPikhEype//OXDvcKx//77 zxTPVj3ezR+E87nPfe7k05/+9GCdhgWmxZWAREwi9IjrfvvtN2ophtunPvWpydOf/vTJUUcdNVhm Vvrgyp8LXehCk9/97neDP9iWcy9hSvqu5SqNXMfi7GEPe9hOAiDx7xWveMXk0EMPnXz+858f8ol4 eY5wsGwkDD7mMY+ZbNu2bTT91grHPL/Ls6wq5Vf5x5HoLB9yt7jFLSa3v/3tR58vrK5dlAmr1Cc/ +cmrwcNCmrzjHe8YRHM/tGUOD0wJ3MT1Et9d0zvhZi0rLu9///uH+BCPKz6Xv/zlJwcccEAEwB5c vodACIRACIRACIRACIRACIRACITAFiKwaQLgBS5wgcFKqOJKRPjSl740fD3xiU88WOwRmQgRvvfT CIkhrLke//jHT77xjW8MQtr5zne+yaUudanJKU5xisFCj4XVd77zncGKzTRHFl+9I8A84QlPGIQO 4hHxh1hIyCOECJfpoqwVf/jDHw7iTfkhDP7K+Z2YyGpqzArQtSVWtffV/VvlSLQj/Agj6zjCpym/ hCTTeAl/P/rRjwaBCF+/Xfe6191JtGJJSGh67WtfO0z3No364he/+OTkJz/5YIHmOawDH/e4xw3p e7Ob3WzVD2KTabnSU7pMcwRFVnGszzgWfP0UWukorzzxiU+cfOUrXxlEXOFghUl8FA7xeMMb3jBY At7znvccpihPe+Z6z+PpGW95y1smH/rQh4Z8W0IzP/0+K19gYirvPEykH6GPu+xlL7sqaPtuCvS7 3vWuybe//e1hGrd0IWrjbcovS82PfvSjQxoRYfF/yEMeMspEXiBqs/wj/HH8qHjUcfgh/0IgBEIg BEIgBEIgBEIgBEIgBEIgBLYkgU0TAG9729tOrnWtaw2RJhKwvnr4wx8+fCe+ERxY/vmthLmWEOHm Wc961iBiEFFMR2U5RQAiMLHQI0B997vfHQQr00n7NfdYY7H8I1wQV0x5vOMd7zi5zGUuM4gdxDoC ILFL+IiF1kWb5lg9EU7e9773Tfbdd99VMWva9Vv1vLUMz3Wucw1C05WudKVBHLJmHwHQ2o3iaEop azQiknQwfba34PviF784eeMb3zisB0ckvNe97jVMoSbmmq5NvMWqpvqaCnzCE55wwCI9CHSPfOQj ZwqA0lleIQC655a3vOVOYrF18wiRxD956cpXvvLk/ve//xBH+YgY9pSnPGVI5xe+8IWTq1zlKoOA y7+NdIRIU9+JxEQywvbFLnaxIeymWpfV3LRnCo/8vRYT04mxJgAqG8paL6ISyWuKLyvMWgeRoCpN n/3sZw9CJT+OOOKIoXwprz0Tlp3S333KF7GYSGk6fVwIhEAIhEAIhEAIhEAIhEAIhEAIhMDeQWDT BEDCR7neSsh0TFZ0vdVfXe9IMGExSFQhTj3oQQ8ahJ32GqIGSy+CDzHKFN3WsWZjPVabW9z1rned 3OpWt9pBLCFcEUj44Y+V1JgjtBBBTO8k8NzgBjdYFbPGrp91Dg9hIuQQXHznN3GsF3Jm+bPe3659 7WsPQpP1+Yhwrdu2YiFJhCKqPfCBDxxEK1Z8LMXOf/7zr17qd0IhYQ4bU7jvdKc7rfKzpiJLOFNH CV8EVpZ4V7jCFVb9wPp617ve6vexD0RZQi53mtOcZhAiS0R0DjvhbuI9PAAAQABJREFUExbONHCC obUcucp7hGBCL0tR1mxE4Fkbugw3L/hPPHEhUF/4whcewnrFK15xyC/W5FtLAPQ4+dHfLGcKd/l1 pjOdaXiO/FOOheR97nOfIS2IgMpb66SNa1jWKh8saaWN/N+KvO6xeYj4EIyVWWtC2gAkAmBLNJ9D IARCIARCIARCIARCIARCIARCYGsT2DQBsI02EYaQV873EjDqXH80JZfQwBH6iFLTHKs94kXvTAkm AnLEJqLkNIGNqESsmebcz3KRNaFpkaZR2nhkPY5Vmymi1lQTHpaI/L/mNa85Ofe5z70eLxe6Z/vK +oS9pVfrAUHPdF2iq7QiVBKLWgHQtOljjjlmuI3AdKMb3WhV/HMSH6JfpTPB89WvfvUOAuBw84x/ 7n39618/TNF22VWvetVht+Y+7K4RRiIY4a3EP/eUUPnjH//Y18FZG89afOc973nr1IYcPZ9FpXxE eDM1FxsiaB/m9T4Qk1e+8pWr+drUbAJ564h7rAJnOQIo8ZcAyEkv5a0XAC9ykYsMVrGuFydT31lU xoVACIRACIRACIRACIRACIRACIRACOw9BHaLALgeHASjst4y1Zcl0iyLwbFnEEvKesxU0BIDx65d 6xzLOFZ/LBNNOybesYqqnVfXur/9XdxsSGLaKtGIAMh/f7tDAJxHjCJMFn/XEwVbZz3EWhPOeo8s 0coR3V7wghcMOyLXOXEswbDOrXW0bh+x1TRV4bnpTW+6Ux5o/TW1uRVx/cY60K66xGBxcE64WQNu tABo2q9NU4hkrdWdZ26UI8SydpSHxJeQ6bio69NUPhzLF6bem/rL+pKTJzYyPouGO9eHQAiEQAiE QAiEQAiEQAiEQAiEQAgsTmBHVWfx+zftDtN5S9gwbdOuwkSn2vhgngcTYWqaJxHR1Elr0xEDS9ya xx/XmAZpCiQrOBZ81r4jUK3Hefbvf//7Yb29n//854MwSZxkxbYVnPAROouRtexswNI6DIWdw6Rd O5G4aUdenNxHXOJMn15EPHr3u989WKa5l7Wa6d6VJ5zjhLHSgRWnDV7KSXNr8rFEFD4bYXDE5LIu rWs34khAI+C24t9G+Nv6YVo1jhxrR3+9ONteP+0zQbTdNEcaSufeWfOvxL/+t3wPgRAIgRAIgRAI gRAIgRAIgRAIgRDYOwhsWQHQlF9TfzkizzOf+czBYu7Nb37z5POf//xghWfDilmCEkusc57znKsC yate9arJk570pMnrXve6yac//elhMwQiUVkJzkoyU5hZut34xjcerNGsI2dq5zz3zvK3fiPijFlg 1e+788iCDyNOuFgmlnhW4SDE1vRenEs8YllngwkiFRH3zne+8+paie6ZV8CtzTts0sJZK3BsbTwi I0GPIzTWNdLlmJUpynYoZqVpWnBtSuPa3/72t6sCp+97gxNmIjY2nHUX1ys2smC1riPHwo+QuB5r 1sGD/AuBEAiBEAiBEAiBEAiBEAiBEAiBENjSBLbsFGDinymfBDpTbk3bdDTtlhhl3TNWSzYlIDRZ n693hI0b3vCGw/p1dqK1EQMrQhtLELVYNrEsYzXGX/6UtVrvF6HRzqpEJKKSTUdsBrJ9ZT09VlKL ul7sK2u7Rf3Z6OuFw869LBw5cZYO7dqJrrH5Rznin99rnT/347j//vsP06Yf9ahHDZe6j9WgdFnL sdqT5kRGVpzWRxy7TziIgByxkiDmOSw9Tf0lSBKTbQAjzcqxuJSm09K7rttKR9Oh7XRMjGaRKi+u R7QjnBPDibTyoR2e5f8+T26luCcsIRACIRACIRACIRACIRACIRACIRAC6yewZQVA66nd/va3H8QO ghshh2jz8Y9/fPgz3ZNgR7gwNfQ2t7nNsKZbK1TBQgA0tfaII44YBEQWZSwI/ZXFmGmbxEQbJxAD 211mW7SEJTsGWxfNFFlWVNZjI1b2z23v6z97LhFTuH3mLz+IbXvaiddTnvKUYeMNcSIy2RCkdUQ5 1mjlbDrh2o997GOTF7/4xYM4SFSSfu0GFQQ3AiDxdZZznY06TP3miLzW6xsT62oasusIWNaJNL3X hiPSx9RfecPmHETgciUc2vSCyFyCYP0+z1E4iZPWPxwL2zx+zHsNi8Y3velNw4697rnKVa4yCM+L inasO48++ujJe97znkGwVX7ucpe77JBO84Yp14VACIRACIRACIRACIRACIRACIRACOwdBLasAAjf 2c52tmEKKdHNlFtWYXZzNQWSgMOizx9RkFh0v/vdb3KJS1xiB/KmhBKACB0EKn92sC0/fPZHyGM1 9sAHPnCwNtvBk//7QvBheXWd61xncvjhh0+IiW94wxuGHYjbTTDG7m3PERivfe1rD/EjdJaQRITc k85aek972tMm1t4jLBHe7nvf+65Oq23DJszlxIGARvz70pe+NFhWsrhjGUl8LZHKsd0Nuu7vj6b0 Sg9CHr9tvmKa8Zgjnpbjv3B96lOfmrzoRS8anmV3aBtlYF7hcH17n/iyeCRstteUv9OOnmUn6Ac8 4AGra01Ou3ZXz3/7298emOCJCavMWt9yXr9ZShJFDzvssCHvYmqKNjFxPZaE8z4314VACIRACIRA CIRACIRACIRACIRACOxZAltaAISGsMYCjbBHoGPxRQS0flntiGozg9e85jXDFFHTTftNC3y3hhyL O1NJf/KTnwz+ELz4SRQksNhohLhCiCP0TXP8YSn4rne9axDLrDVn99d5xSPPsDlGv7HGtOftjvN2 y33Oc54zbN5BpLNmHkH1cpe73E6PZ+3W8pEmL33pSwcLNdNw99tvv0HgFM9+rb0+bXbyfOUEEdEf xzrTzr4s9cbcqU51qtXTwk0kJs5Kz4tc5CKTu9/97pNtKxaHfms3/hB+4eNMDSYAtmLlqqczPvCT CHzve997xlUb89NRRx015FW+ER0vf/nLL2R1au3Ft73tbYP4ZyqxtTFZaN7hDnfYIS03JrTxJQRC IARCIARCIARCIARCIARCIARCYCsR2PICYMEi4vjjCDmsxAiBL3nJS4ZNJ0xttEECay/TT8cca8Da JMJ6dfxguWZjkYMPPnj4TMz70Ic+NLnRjW405sVw7tSnPvVggfWZz3xm2ElVGFgFEr/2RseK8ulP f/rk5S9/+WAZednLXnby0Ic+dBABx+Ijnu10ZVZl1pOzviKh9W53u9uqqIRvWdsRDtspwWN+E6qs 0Uik5a573esO1ptj1zpHAGS9Jv3d+8IXvnBIT+E78MADJ9tX1mjkWL/V5hm+S8Oatk1cJoYtKgCa lktk3GzrOSyId9bu41j/LWJxKq8Tq5/85CdPiH/WbLzTne6Uqb8DzfwLgRAIgRAIgRAIgRAIgRAI gRAIgeUnsNcIgG1SEDD82fiDqETcsKYfQc8adtMEwNYPoo0pkP6ISMRDf0Qdwt5NbnKT9vKdPpvC a21CzyZYsTyrzSh2ungLn2AFaddeFpQEMhtmPPjBD55c9apXnbmuXa37hxcLSuKZNRkPOOCAYWpz WUMSBlnKcaz43DfLmcpt/T/Ta4l4pqe21ob9vUQ8vxMASwT2vGtc4xqTfffdd3L84x9/uIVobK0/ Ttja6bPiKt7ttObhwjX+ETbFZ604reHNmj8TWOVr4ZNX5e95n2las/sPPfTQIZ1MhSaq9uszrhmI XBACIRACIRACIRACIRACIRACIRACIbDXEtgrBcCWts007ORLACRClcjTXrPWZ9NSL3zhCw8CIJHF hiMlYE271/qE17/+9Yf15li5vexlLxusAeexAiTKWHfQNGYCZglJ5zjHOYZNK6Y9c6PPi6edcoVd HExJvv/97z8IRCWcTXsmAY0VHT9+//vfD1ZwpkFbc6+m1rrX+oxEQjyl1SyuhLvPfe5zk0984hPD Y02zvsAFLjDTshJvaSEc0o6IKR6s/9p1A+ULIhpnp+BWACQ0thaNw0Vb5B9R853vfOdg7SpIV7jC FQaLyHnyGR7WUiT+EanlNVPg73Of+wxpsUWimGCEQAiEQAiEQAiEQAiEQAiEQAiEQAhsMoEtKwCa tkgYm7Yjb3EhGrH84wgc7XRMQhvxadr6ceWHY/lBoOo3jGivq8+eZborK8APfvCDwxRNVllEl7Uc S0EbT7zyla8cxDL32AXYhgxja+6t5d96frdun7Xy/JliasMOa9mZXjqPdZkpqNZCJLxxLOhMv7br buve+973rloAWldwliNCmoItLQhcdiCeZ6orf01t5YRdHKwb2Lrvfve7qwKgKb+nP/3p25+37Gei pU1NSkQlOveMxwKv7LBkPeSQQwYrVd9ZDtrUxeYus4TYMf9yLgRCIARCIARCIARCIARCIARCIARC YO8lsFsWrSM2tBZlxJ1WqBvDR1iyk+vRRx897Pg7dg3hzHp9NrDgTnKSk+ywsYY14V796ldPXve6 161aUI35Q2ApAUnYiFk1bXXs+jrHYo8IeNKTnnSw/jPdlei4liPmfO1rXxvErtpIxDRNm5nsDmcH ZVZ/z33uc4fdk20IYSdbuyWLyzzO9GtTZ8uZkk2Yai3Tamo2lkRVU3JnuW9+85uDWOUa1oKXucxl 1hRvPe/GN77xqmjpu2myrXBM7HzLW96yah1qerDw7y7XWkQK3yLiG6HYZjcckZZ418ZtLA7KxVe+ 8pXJU57ylKH8EP+IpA95yEMGC8K2LI7dP+ucsNfaia7zfa2yPMu//BYCIRACIRACIRACIRACIRAC IRACIbD5BDbNAtCUQ4JYuRLpfLdzKlGOcECsIEiYOtruEEsAfOYznzlM1dxnn32GnU/9TtxhfWdD BDvF1tRbQgRBjnVXOQIgCzfX2qTjYhe72LAJRQlE1oX76le/OjnyyCMHQc59po1ad24eIY+wQ3x6 /etfvzrVtZ691pH/7ZqBPmOxO9yb3vSmybOe9axhCrLn2ZiDqGSqKbGodwSf8573vEMa1G8s7WwW Yv09giJrMzsBE5qIiCzunva0pw27LbvHtYTVac5UV9NViYAccdFU3nnEstoVl+AozaUHUZNg5jtx laUmvqYLm0ZLsNwMx3JV3ic6ltgn71faWuPQeosc1sKB2ZiVqqnVwl7WqcrBtv/bCGdW2OVrG368 4Q1vGOIvPViYEpid652wmc5tZ2EieuuEkchug5dytUOz78oy3soCf0yvJlLOY6VY/uUYAiEQAiEQ AiEQAiEQAiEQAiEQAiGwuQQ2TQA84ogjJu973/uG0BMR2h1YCYOPfexjB0siooH12Gwg0QqArOQI FqZA+mMRZgdfYhVBym+f/exnV9d+Y9G133777TBl1HNNK7U+4Le//e3hN1NKiXwEF2Gy5pyNMAhw RC3TcM997nMPG0rMg976g4QZFldtHOe5t71mHqGrvX5XPr/1rW8drMrw4bB56lOfOtVLrLAltLXO +nw2SyFoEVkPO+ywYaMJoiAh79Of/vRgSXmhC11omF48y3KN4Gs3ZsIoQXj7yu697Rp+7XP7z/y9 5z3vOVj4SU/rDj7mMY8ZBEQiGnGSgEXc2n///Yd1BTeLtzzwvOc9b8hzJQB6dom9widsHP6mIl/q UpcaFQCtESnvKiNEPJaLszZEKS4EQNPLHTmi5DErU6tZuVaa17WOLDStgUlw7QVAvxPZCZGYuf+3 v/2t04MjaD760Y9eFQAJr8p2BMAilGMIhEAIhEAIhEAIhEAIhEAIhEAI7HkCmyYAfutb3xos9CqK rfBgs46vf/3r9dNgfVZiRZ0kjNiwgJhDTCKEEAJZ/xEiiBaEDRZU1jYjwlmDzu/lCHosC4lKplG6 33NZK/GDsMIPQg3rJ1ZnNo+oKZt+L+d5ruudaz2XZZUwlmvvrXPtsf99HovD9v5d+UzAaZ9vDcAf //jHU71kqTn2O0tK6wZyREUinp2UpQHBC2PilmvsPDvNCcsXv/jFwQLQNazRWAuO8R7zw/NYeBLf nvGMZwzCI9GPpRq/hYWY6Jr9VwRA/m+Wk46md5eVXOWzeh5BsreGJXb3TrjFwWYxHB4E2HmYKGue U04eVx7bMli/1ZHoWiJlnXN0j3ulz5hjYUn8Fk/Xiktflsfuy7kQCIEQCIEQCIEQCIEQCIEQCIEQ CIHdR2DTBEDrvV3kIheZKyZEDRaArdu2MtXRunQspogPLPkIPGVlZ6ohayhWgaZQmvrbT+tkWXj3 u999EPf4YSdY4pc/gp7f+WEH2O0rFmemhtZusASRdo07U0eJHGOOJRyRq9Zqc43wt2ultfcR1IiW JTT6TXxYHu4OZ5OM85///HM/Svr0m2q42XnTqu0cTKBiSUiwMp2XgEt0M/X32te+9uoafWMPxZX1 593udrfhZ1aepnMv4qS9PIcjSzcWokRL1ousPk0HxnxWOi7yvGnXCsftbne7wVpv2jXteSJ1uyNx +5tpu/e73/2GU6bVzrMhiouF4cEPfnDr1ZqfMceud9LmZje72dxlmeWfMhkXAiEQAiEQAiEQAiEQ AiEQAiEQAiGwdQgcb8VqZ+dF3zYgfKyOiGzzOtM4e+smVlAsqvhliqm10Ih3RIkS7ogWBLXW8q99 ZvnBusn95Qd/Task+PGLUNQKcvxgzVTWWcI2awprH9+1rm/99ixxIjpOi4drNsr1YZ3HX2LmNEGz rOxYg5kS6kgEIuqJ07T72udWOuOAnTT1eVGHq/hZm45FonQlpBHFhKXPY4v6v9b1ipPnYzKPE0f5 aiyubR6RN4V/HicMRNhF3Czmi+QX8ZB2m815kbjl2hAIgRAIgRAIgRAIgRAIgRAIgRA4rhPYNAFw s8CWXjkmmMz7zI3wY95nHRevw3dX0mejmG2VcGxUfOJPCIRACIRACIRACIRACIRACIRACIRACKyH wF4nAK4nkrknBEIgBEIgBEIgBEIgBEIgBEIgBEIgBEIgBI6rBHbe1eK4SiLxDoEQCIEQCIEQCIEQ CIEQCIEQCIEQCIEQCIElJBABcAkTNVEKgRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAIgSIQAbBI5BgC IRACIRACIRACIRACIRACIRACIRACIRACS0ggAuASJmqiFAIhEAIhEAIhEAIhEAIhEAIhEAIhEAIh EAJFIAJgkcgxBEIgBEIgBEIgBEIgBEIgBEIgBEIgBEIgBJaQQATAJUzURCkEQiAEQiAEQiAEQiAE QiAEQiAEQiAEQiAEikAEwCKRYwiEQAiEQAiEQAiEQAiEQAiEQAiEQAiEQAgsIYEIgEuYqIlSCIRA CIRACIRACIRACIRACIRACIRACIRACBSBCIBFIscQCIEQCIEQCIEQCIEQCIEQCIEQCIEQCIEQWEIC EQCXMFETpRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAoAhEAi0SOIRACIRACIRACIRACIRACIRAC IRACIRACIbCEBCIALmGiJkohEAIhEAIhEAIhEAIhEAIhEAIhEAIhEAIhUAQiABaJHEMgBEIgBEIg BEIgBEIgBEIgBEIgBEIgBEJgCQlEAFzCRE2UQiAEQiAEQiAEQiAEQiAEQiAEQiAEQiAEQqAIRAAs EjmGQAiEQAiEQAiEQAiEQAiEQAiEQAiEQAiEwBISiAC4hImaKIVACIRACIRACIRACIRACIRACIRA CIRACIRAEYgAWCRyDIEQCIEQCIEQCIEQCIEQCIEQCIEQCIEQCIElJBABcAkTNVEKgRAIgRAIgRAI gRAIgRAIgRAIgRAIgRAIgSIQAbBI5BgCIRACIRACIRACIRACIRACIRACIRACIRACS0ggAuASJmqi FAIhEAIhEAIhEAIhEAIhEAIhEAIhEAIhEAJFIAJgkcgxBEIgBEIgBEIgBEIgBEIgBEIgBEIgBEIg BJaQQATAJUzURCkEQiAEQiAEQiAEQiAEQiAEQiAEQiAEQiAEikAEwCKRYwiEQAiEQAiEQAiEQAiE QAiEQAiEQAiEQAgsIYEIgEuYqIlSCIRACIRACIRACIRACIRACIRACIRACIRACBSBCIBFIscQCIEQ CIEQCIEQCIEQCIEQCIEQCIEQCIEQWEICEQCXMFETpRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAo AhEAi0SOIRACIRACIRACIRACIRACIRACIRACIRACIbCEBCIALmGiJkohEAIhEAIhEAIhEAIhEAIh EAIhEAIhEAIhUAQiABaJHEMgBEIgBEIgBEIgBEIgBEIgBEIgBEIgBEJgCQlEAFzCRE2UQiAEQiAE QiAEQiAEQiAEQiAEQiAEQiAEQqAIRAAsEjmGQAiEQAiEQAiEQAiEQAiEQAiEQAiEQAiEwBISiAC4 hImaKIVACIRACIRACIRACIRACIRACIRACIRACIRAEYgAWCRyDIEQCIEQCIEQCIEQCIEQCIEQCIEQ CIEQCIElJBABcAkTNVEKgRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAIgSIQAbBI5BgCIRACIRACIRAC IRACIRACIRACIRACIRACS0ggAuASJmqiFAIhEAIhEAIhEAIhEAIhEAIhEAIhEAIhEAJFIAJgkcgx BEIgBEIgBEIgBEIgBEIgBEIgBEIgBEIgBJaQQATAJUzURCkEQiAEQiAEQiAEQiAEQiAEQiAEQiAE QiAEikAEwCKRYwiEQAiEQAiEQAiEQAiEQAiEQAiEQAiEQAgsIYEIgEuYqIlSCIRACIRACIRACIRA CIRACIRACIRACIRACBSBCIBFIscQCIEQCIEQCIEQCIEQCIEQCIEQCIEQCIEQWEICEQCXMFETpRAI gRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAoAhEAi0SOIRACIRACIRACIRACIRACIRACIRACIRACIbCE BCIALmGiJkohEAIhEAIhEAIhEAIhEAIhEAIhEAIhEAIhUAQiABaJHEMgBEIgBEIgBEIgBEIgBEIg BEIgBEIgBEJgCQlEAFzCRE2UQiAEQiAEQiAEQiAEQiAEQiAEQiAEQiAEQqAIRAAsEjmGQAiEQAiE QAiEQAiEQAiEQAiEQAiEQAiEwBISiAC4hImaKIVACIRACIRACIRACIRACIRACIRACIRACIRAEYgA WCRyDIEQCIEQCIEQCIEQCIEQCIEQCIEQCIEQCIElJBABcAkTNVEKgRAIgRAIgRAIgRAIgRAIgRAI gRAIgRAIgSIQAbBI5BgCIRACIRACIRACIRACIRACIRACIRACIRACS0ggAuASJmqiFAIhEAIhEAIh EAIhEAIhEAIhEAIhEAIhEAJFIAJgkcgxBEIgBEIgBEIgBEIgBEIgBEIgBEIgBEIgBJaQQATAJUzU RCkEQiAEQiAEQiAEQiAEQiAEQiAEQiAEQiAEikAEwCKRYwiEQAiEQAiEQAiEQAiEQAiEQAiEQAiE QAgsIYEIgEuYqIlSCIRACIRACIRACIRACIRACIRACIRACIRACBSBCIBFIscQCIEQCIEQCIEQCIEQ CIEQCIEQCIEQCIEQWEICEQCXMFETpRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAoAhEAi0SOIRAC IRACIRACIRACIRACIRACIRACIRACIbCEBCIALmGiJkohEAIhEAIhEAIhEAIhEAIhEAIhEAIhEAIh UAQiABaJHEMgBEIgBEIgBEIgBEIgBEIgBEIgBEIgBEJgCQlEAFzCRE2UQiAEQiAEQiAEQiAEQiAE QiAEQiAEQiAEQqAIRAAsEjmGQAiEQAiEQAiEQAiEQAiEQAiEQAiEQAiEwBISiAC4hImaKIVACIRA CIRACIRACIRACIRACIRACIRACIRAEYgAWCRyDIEQCIEQCIEQCIEQCIEQCIEQCIEQCIEQCIElJBAB cAkTNVEKgRAIgRAIgRAIgRAIgRAIgRAIgRAIgRAIgSIQAbBI5BgCIRACIRACIRACIRACIRACIRAC IRACIRACS0ggAuASJmqiFAIhEAIhEAIhEAIhEAIhEAIhEAIhEAIhEAJFIAJgkcgxBEIgBEIgBEIg BEIgBEIgBEIgBEIgBEIgBJaQQATAJUzURCkEQiAEQiAEQiAEQiAEQiAEQiAEQiAEQiAEikAEwCKR YwiEQAiEQAiEQAiEQAiEQAiEQAiEQAiEQAgsIYEIgEuYqIlSCIRACIRACIRACIRACIRACIRACIRA CIRACBSBCIBFIscQCIEQCIEQCIEQCIEQCIEQCIEQCIEQCIEQWEICEQCXMFETpRAIgRAIgRAIgRAI gRAIgRAIgRAIgRAIgRAoAhEAi0SOIRACIRACIRACIRACIRACIRACIRACIRACIbCEBP5mCeOUKIVA CIRACIRACIwQ+J//+Z/JD3/4w8mf/vSnyfGOd7zhipOc5CST05/+9CNX59TuJvBf//Vfk+9///uT v/zlL6uPPu1pTzs56UlPuvo9H0IgBLY2AeX4Bz/4wcSx6tk9UY7/93//d/Kb3/xm8tOf/nTyV3/1 VxP1/8lPfvLJKU95ysnf/E2GgFs7FyV0IRACIbA5BI630jj87+Z4HV9DIARCIARCIAS2EoHf//73 kwc84AGTz3/+85O//uu/HoJ2jWtcY/KoRz1ql4NpcFnOoLcGvnUux7UJEGfvda97DQN2/AzaH/KQ h0yuf/3rr31zrgiBLULguF4X/OhHP5rc5z73GV62KMPcgx/84MmNb3zjXU6hlm35Pc3TP//5z5PX vOY1k0MOOWRyghOcYBAkb3SjG03ufve7T051qlNNu+04eX4RrsdJQIl0CITA0hDI65+lScpEpAjo 8PS6toFu3nYWoRyXjYCOK2HHH8uuv/3bv52c6EQnmvzd3/3d5MQnPvGyRXfp4/Of//mfq3EkAh3/ +Mdf/T7tA0uTGsCo/wz2xgQ4lmWf+cxnJp/+9KdXvdpV6z9+fvKTn5x84xvfWH3mqU996sm1rnWt 1WdspQ8tX+FSXvqBNIb//d//PVji4ei7dOiv2+h4/eEPf5h8/OMfn/zkJz9Z9ZooGLcYAWncWlG2 d+sPKB/rdcrZb3/728Gyymf1LCvaaXXtWJ/Es+UleW93OWFVTyzi1tN3+spXvjL5whe+sPoscbzZ zW626WVnkXht9rV//OMfh3Lcll2i4KJOvfO9731v4l5+/upXv5pUfvLbBS5wgclFL3rR1Xq39981 LIrV99UenPe85530dWB/33HhOy6sNHFlJfkf//EfQz2P2bnPfe7JxS9+8aUdN6gH5KPKE21672r9 yC990V/+8pdDHawvqn70N+bavkv7++6uH9tnj33uy8xYv2HsvpwLga1IIALgVkyVhGndBHTKX/7y l+8w7YJnOjzXvOY11+3vojdq0H7961/vMHg8xSlOsUuDjkXDkOuPGwS++c1vTj72sY8N4ovO7M9+ 9rNhIEqAOeMZzzi5yEUuMjnb2c42OctZzjIMVPcGKtUh1wHUGdfRMm1Jx3TZnTrsJS95yWo0TdW6 zW1us/p92od3vetdqwKcgT6LsbOf/eyjHXx+ELc2yvHrOc95zuQNb3jDqpfnO9/5tqQA+Lvf/W7g K19xJzzhCSeXu9zlJhe84AVXw+6D6z74wQ9OlC+DJEy1IeI1Nmja4eZd/OJZlT6bLTjuYlC35O1e grzxjW8crK/GAijNtcfKluO5znWu4Th2bXtOniDOEmS+9a1vDeWNyGhqpzr2Epe4xOT85z//5HSn O91qHjHIft3rXjf5+c9/vnqu/CRCev7JTnayYXCsjj7Tmc5UP2/48Ytf/OIQfvXrPHlYfUtcuvzl L79QWN70pjdNHv/4x+9wzw1ucIOhrO1wcgt+IVq0IinxYlem31c5FtWqc+aNtnvf8573TF70ohcN dZF0Uze0/tzpTneaXOhCF5oqVLnWPdPE8HnDskzXYfLVr351yKPvfe97J1669FwJ1k95ylOmilZ7 Mw9Clj6jumysHvCiq+pH/a5znvOck9Oc5jRrRlm9+9nPfna1flTfEFWrflSXEKzPcIYz7NCXe/Ob 3zwIsf0DKhzqRy9ZhOEc5zjH1Lze37+R3z/wgQ8MLzWqHOF25StfeXLhC194Ix8Tv0JgtxGIALjb UOdBm01Ao/61r31t8rCHPWyHDpLnXvWqVx06sdPe0G902Lz11Wn7xS9+MXitc3HXu9516KiNNbgb /fz4t/wE5Kl3vvOdk+c///kT4o9BiwGDDgrRwODNn07UFa94xcld7nKXvWIaoTjomJq2VALgmc98 5skBBxwwIWouu/Pm/BGPeMRqNAkCt7zlLXfoMK/+2HwgwBksltNR3rZt22gHvx2Uur46tXXveo6E jqrv3N+/LV+Pn5txDyHmn/7pn1a9Ji6b/twLgNbMwvSYY45ZvZYYwDJkM63Ja8BeD1XO/cXNT4BQ 94xnPGOY5t63t/iqV+rPSxJTIglUl7nMZaY+xMsVLxef9KQnDXVt1bf8U8/KEwbLpnj+27/92+rL FuXg4IMPHgbFvefC5l5hMR1TP+Xa17725CpXucqmTM9897vfPYRt3rIpfHe+850XFgCxIQYQrLhd sbbsmW3298MPP3zy3e9+d+hDSheixf7777/wY+WLvp5dtBx/7nOfG9oCyzWUdVofkGLcn5/1XX0v fMdVp24/9NBDJ6985Ss3lOvewpPg6WWdvuNY/djWS16SeJl4wxvecLJ9+/apUcT0Fa94xeRZz3rW 8LJD3i9L1aof//7v/36yzz77DPVhKyg+9alPHYTD3vM2HARAZVE9rb4mKu4uxxr/n//5n4eZE1Vu hO1f/uVfIgDurkTIczacQATADUcaD/cUAY3Nhz70oWGKRB+G73znO5MvfelLk0tf+tL9T5vynQDI iqed8qFzb5DZN7ibEoB4uvQE3ve+900e9KAHTb7+9a8PndhZEX7b29422bYiBu0N64gZnHzqU5+a vPCFL1yN0nnOc57JTW960+OEAOjNuwG0TjpHVCBoOE5zmLmG1XE5YqkBbO+cY6HUWim1nfH++nm/ 9/Va/31efzb7Oh14VpY1GGfd0w/UKwzalJbptOvq+o04EuylDYehPwOnuMUISDvT+tZyLL5Y873j He+YvOAFLxgs+Np75BdT262hdsQRR8z0U74yqDZYNGAtR3Br81Gdb4+Eaf0ULz6s0Wn9uGlT5tr7 Fvks/xLmhHMeR7hTFy3qKt/WfVu1LqjwtUdpbAozJ9zXve511yUAerHA0kndXPFftBwfeeSRg4gt zcqpr4gyRBV50zPK/7qmP3quOt496j1is8/HVfflL395gm3LVVnDhZCPkRdvY+3nsjCTL+epH73U 8yLs6KOPHupH1vKtkwcJ5gRVfba2bW2v89nzlC/1W9vn6NvZ/j7f5XHjKf1ez7v//e8/l9X2mF+L nvv3f//3ySc+8Ymhj1X3Kt8YxoXA3kogAuDemnIJ904EvAnVqI85HXwNx+4SADWK7SBemNJYjKVM zq2HgLVrHve4xw2idpuvWMqZYqETa5qa6YvKhYFfe916nrk779EBLwHMc5WlvSn8u8JKx3Lbilhr +gwn7aT3LAGQ+MdCpBxLNULimPObN9fWkqqBo0HkcdVhUBx6Bv35/nt//UZ8Z9nAIqK10so0o8XJ 9mllGpu1Lg3q1S1mC7C2Va8oPwZ4BpVvfetbd3iYQafyYkpxWye5iBjjj3WgNt9fKyqUR31YCGsE etcSIDl1nrraHytDv9/2treduq5g+b3IUdz7sKx1/3FNKFLfSgNpKe6+r8cpx9JRGhdzU3UXcYTI Nj8RpR7+8IcPL5KlpTCaNj5LqJLXrne96w1T1Evccs+09mGR8O2t12pPf/zjH68GX71ggxZT+KU5 riyD9ybL1dXIrPODJQzkL/GX57z08NJCvaSeNGXa5lSMLFournnMYx4zWFO6rnVEVf0WFnT1IqHK VntdlY86pw+k/OjT6KcIgzTRJvpj3c1fs1rUv5vpWDU+97nPHRhs5nPidwjsbgIRAHc38Txv0wh4 86QTP+Z08E2j2F3OGkN9x9m5WR21tcJmoNL7udY9037XmPaN7rRrx85rhNtOwNg1i57T0dZBXcR5 c8hiZis4nRVpvDucDRe8xW5FMVO1WCsQj+Qzb25Zor7lLW+ZWGOlFYh2Rxg9Yz35RL7q01S+by1q 1hP+9eSveo4O6FjZ3RU/y++x49lX1u4rAVDHWQd61uDRm3VloZy36z3D+k0Zu9SlLjV0quvcWNzq t2lH4dJR53alLnH/ZnHk955066mf5PMrXelKw4Cnwr5ovVj3baXjeuqCjQz/vvvuO0wfU5cIC2Hv oQ996OrUXHmQ5bGyVhaYyr0+hTq0Ff8MTvdfmRZqSpplRYh4BEWWIgass5yyovyx3pY/9FusL2V6 cZVh/nkm4WYjly0xvZiwKP7C4QWRwbT+EYeNQbUXpfoI8p0XSmu5jeyb7Om6oC9rVcetxaD/3YsW S2/gWK73u85PO/ZttvV8rQdLWKk6V91dn8f88VuJO/W7dPa3HrdZ5XhaG7ueMK51j7LcpouZObe6 1a0G0Qkvv+Ezb7u4WWFfT/uxVtyn/a6uufWtbz2Uec9VDxL2qh8ijtb3Y31nGQwOJ7+bTtyKf/pw pgzf5CY3GfIqkVBdwzpan7Rl34cHfzM+HvvYx67Wj9YrNF27LJfVsSy2TQXeTAFQmJ/97GevGeY+ DvkeAnsDgcVG23tDjBLG4yQBHVCNU9uR9YZTo6UzrcE59thjBxN0C8r27qijjhqmUrqe80bQ2/fq WGl4TA/SOeUXoeeyl73s6ppB3pZZK8qzdPJYHPZTfkztMUioTgW/vYm9xS1u0Qdn+K7zZ/FwU5cN VnS8hN093lTqzI851xF8hEknRpx0cK5xjWtMXv/61w/rWLBYMLDQ0dfxWWuqkcb9ta997RAvlmXC ZhqKjuUlL3nJydWvfvWdgoKBtelwwMyiygY1xCvPNsjF2LplLDdtXqExN1VaR2Sas2izNeJMlyJy 6WxgQjQxyBvrEOjQGNx5FmFEOgq7DkqJdt4KmyorDaURgcPaa/ytfNCGya564oMlPp4hLPzTQTJw kkdMK9loR/xr85fw3f3udx/WI5HmvisT/qxrZepvO5C0XotOG+Go4mrHVvlqLK7egLq2fjNAvv3t b79TtKQHSxlrFwmfN8l442LQbAMF4WGN0w6GPvzhD0/8ySfS5v3vf/8OfuuMWluGH67xZ2Am/aTj mNMxNbCWD73tx0Ke3bYikF7sYhcbzbMsLuRF/ks7acpyWF5jEXC7291u2FTFQF8+Fj95Tz6xY+BG OIz5WU4+VDY4fOVh7HASF2KCtFHuy3mT3w5c1V2zhAnpMs/0cHWRMo2T9MVEHWLds0WdcoxhlWP5 lnDJilVdtdWt3vB+8YtfPHBQhqSbepDAov5VBjBX/k2bUs+2eb54qU8NZkwBxaB3/L3Oda6z0xqF /XW+y/OEJHUZpx662tWuNuTll73sZcOgTljlb+XQIub8VzaEV/0n3/iuDbTekjLDqeesOaosiYc2 QPmz6QU/e6dO1H59+9vfHkQ2lh/aGXnGPdIYq93lsJAO4iv+4siaRVlWljhlzZIKJQCKqylrNfB0 DS7Euzvc4Q5DW8M/bSxRwWZj1vtzbpZTvr2sEQ5/21fW1rJrrvJQTllrRcc6vytH4bM2aDl9JnV7 9Zuko/xiYF1uLM/67diV/pR8K9zqJf0tLynueMc7rhn/8ttROqhTtKfyrfZXG8oqWdsrLO10wfZe 1polUOCo7lDO9LXsdK5sKVPifeCBB462xZZqkc5Vhsua03OkK/9N/66+ofBqh5TJ1nJa2N/+9rdP Lcf802ebVa9Jc+2y+HuO/mLrhO3pT3/6UI7EV5iqHFcZlIc/8pGPDJuGtG1A+SOva//0v9o+Qf3e H7VxeFY5lierHGs3lONp6cMv9bt+kvpAGIVbv48f6hsv5uUlcVHXCJe+yEZaKBJyWHLh6jk2d2qd 9FcPsCoTPoy058rltBdp2mH9UIKYttB18gMm+rprsbVGuDqfk0f1F+WPY1bGEfqqLO6USy+EbFKk fZ6Vd9r4rOezsmazn7Z+lB+lTdVD2Oh7lgCoXhQPZbac8Iq/tdjVNVU/ykfqB+vtVl6te/qj+ret H22+hRExrpx6elafpq7blaOpz+pkeUZZki8wiAuBZSAQAXAZUjFxGDruGs6qnDW+OkYaCMICpzOo kzYmABItdFJ0urh601odeQ286Rx+9wwik6NncBprHQjPcA/hwD2tIzIaQJVzHZFhTADU6OroGUjq nPDP8zSc4qajqxPzwAc+cCfBy8DsVa961dCR8Az3XeEKVxjCpiPrDZxOIr90wITd9IdpnTgdtCc8 4QkDRx19A98Ki7VliA0EAJucGByV0+nCpAajH/3oRwdrCuKTZ+tAESntGFjWbM4Tf3AmtrROZ0mD TMTkp86HhlkcCUwG2jrg//iP/7iTGCO+/BV/HQn+Y68Tr1PIYc5/HVZ+ukYnkMDknnLSwvRbz8LO wFY4yomD/KETY7qOztC0QVTds+hRGteg1b3SQ2cRh3IVZp01cRDucjpjFoRXZiqu+J71rGfdKR8Y AMmLJUKJ381vfvMdBEDPN5i286NOozyLifOcZ+hAGThZ4N4guQbZfieyeQbmnMFC6zz7ec973g6i lg43C5wxAZDYYT0a+UueLVaYyLPKjzfURFNhKicfPvnJTx6+YiE8BETspKHBrk74q1/96iGO4ide ygiB0j276rBq/REGZYYzSH7kIx855Ed8t68MUAjw0r4VAA1E2sGfjrO6aZrDYi0BUHnFhmigw+/5 mKjXlAP5Yh4nLYkOBrrCJOyV7vxTPyvjyj9rpHn9nefZG3mNcl/1mzQTTvnBoNAAXDwxcl49qz5U z7IMap16Bw8DbP70zv3q1X6TkvY6z1GelSuDxyrrBtnqV5Yc6jbloZ5xj3vcYxhs+658GOjY9VIZ EQ8DUoJZCYDq3MNXNkhQvoXJPQaNrDV8b518Kq/gIK+or/jpWepbZV++kb5e+OwOV8+vulj5EP7i IQw+V73puxcP6nn3ljNIZ4WlvWzvla7EJ+Ie7mu5tq42UCYctAKgslED77X8mvd3ca/4u6cNf/kh Lfs8Wr/VUR/CRjr6INoN5dd9mBiY+9znibq3PWonrB2GccVXXhYu9TsRSB9IXiU09X7K20TmcoQ+ 98vvwqgc8Et6eImqv9TWre4jYKjXi0XVtX6T7uLzxCc+cTUPOOc5xIxWAFSOvWhpyxg/WofPNBGH v0R40/+rDPZ9SPXsM5/5zFUO7tHvYmlYbPR1tOva0zYvVziklRes+jZriVTCo9+rD60c6zd4JlZV jqXPrHKs3jvssMOGNqwYe2lFWNcnkwfUD5zwsrhV5xB9NsIJrxdWuMr7vqu7WyeNtZHFSx7S/uDa C4DKJL+qH6r9avOsNGaxdt/73ncQ7trntJ/1Z+QVTl1E6NbvUYcTetv+rfzrJZ/NhTbbVf0gTNtW XjC2/QjPrt99FiYcMC3nnnvf+95DGSmeflOniKO635hhLdfWj8qsl2utAIhRXz7W8nOR3615yOih +qLyg7qmfRm0iH+5NgS2GoEIgFstRRKedRHQ6WnFNQ2mDqMBfQmAGgx/YwMpnRsdxGrISuyowGjg dSjL6QRo+Mv5brBQncfyp3531FhVB6jO1/X13dFbXxYGrJc0sJ7dOp0w4dVh1nHRkWinR7pep7z1 W4eQSEHMaP3z9lKn1SDMG7fqRNbzDEisi2RQqzPd3usaYSGw8EdHTuel1irTyWqZ6Cjyo9iIp+lH RNoSaPips+aNcysASjcipGkAnqcTW/5UODTMrjNQda23meWEW3pJ10oD/rTxERe/Fzf+O9c6+YzV j3BLT9/HXPklLO0zxq5dzzkdZB2qtiNr4XkCQ2u9wW+dMNe2gzqdVAMAQjEnrkTwGtgOJ//vn0GW TnzLorf4VM4Mrgz8peVYnN2vM0Ucbf3yGGnXlq82bf0uveX51smrrehVv8mDBnUGZNKn9wsz5YPQ 65muL5FDuPzGyZfu9exyLFWIGm25NHgxECbA7L///nXpuo/yZytqikPlSQMyZb4csQw7XEv08Rsr q3bgomwqi9Ncz7a/znOJu+qRtgy7TngMStv81d9f33E76KCDho71WDl2nbpUfKtOka+3opPH2/pN GIlswt3XlcqPPOnFEqu51sk/vT/t7z7XIKQ/X99ZO3nxQcho6yT5WT421bVeVtQ9/UDGM9r6UR3R 5inhlC7VNiob7unLlxcBD3nIQ4aBfM/Bs4VJPlD+iJ7aL+LXZjsDynbw6nlePLTlW13J2qacPNoO Mv3OOonwU+1IXeuoDHjB0Q+a22vGPqvL2gGva3Aaq0fH7l/vuT7t+DN2rvUfE1P5ahOFNozyvhcv hDvhn+W0jdYUa/s57bPdr83WL5NPtOmsE9s0lLfbek1+JP6pk9p05RdLP8KTfkXbz+nLXhsG4ZeH 1Z+tE78Sreq8766rurrOt0d12yzn97YM9mHR3lX5K3/a/Omc9MCl2rG6rj26p+1ztb/VZ+2ccqzv 57ltOrsGU+VYO6t+U8f0fQ/XVb3RciEea1P40aaT69ULfRyd3xXnOXhUme25SuOel3zeX8cfm/Po y2ozhb29xu/yrLymviUUTptCj0ebd5Un7av7en8xVAY20+kv9PWWurztY4prWf8Ji/Rv+w7qR7NI WJj63DuiMWOEtgz314x9V177DXQwadmP3bfec8oxsVF9xhEs73e/+w0vKvp2c73PyH0hsKcJRADc 0ymQ5+8yAY2ACrudLlECYNvQ6MS4hnjRnq8A6BxUJ6dvWOp7HasjUfdqPHX+ndeIGoSVX3WN39pB ufP9oFnjQpTxRrwVNzSmrq0Blw6CDou3b/vss89gjdV2aj2rwuo5Onwaa+fb34RRR4c1DmtGg77W /eu//usgeLSDSr8THvjnGTqS/DD1zE6tBkhc/yzx0Rki8Hmuv+p0GQA6z4mbzo5OpamiHIurl770 pauizHBy5V+Fw3f+6RSwNBRuFiZjrrjUsa4pLv35+t1RB0+nTrjrOuKrN8VEF3EUbp1m8fC3GY6Q QGjFvZx464TrfLJsZNHVWijUdY7CTCDVsTEQ4zAnEvedN29Cxbviy2pm+4rlWTm/Eb+IxTWoUL6k HStLDDzD7/Jvn5f4Y/CrcygNPcc19bx6jvxd5dZv7mnzvOuI/YQWb9b5VY7Y6XrWS8qYcEpDZU2e /Id/+Ie6dPW5rsFYuFzru4GCP51Rea/YGbixkNt/EwTACmvVX22eqsGrQYdwlZOuraCg7qi6B7v2 2rpn1pHwTixp6yTXq5eEx2BG+VnLse5QT6iPKn2xlAbSS7lxXvrrfBOHDCrlya3oqs6osCn7eBC5 24GCuImP+roXALUXlZflb3Fv8648Pout56jrDKjbvCFM/JVmrDb73yrM/bHSpX+m7318+2vcS4Ah Hsi35Qja/ry0Us+In3qDpYyBr/zaD/Dq3o06suY4dkWskGfVQ8JhGnrLWp1ZLwPwUr6Kh3CoD9R/ fbzbMPaD6Pa3+tzfrzy2L0Bcpz1R92w1R1zz0rAXsypvEASU75ZrHweignqAZWxbpyg32jain7LE D79rl6wJph7o+yht+khX4XNOuWnDQBTTlm1fabvaJRYwlif8cW14KtxVd/qufPrep7Oyyy8cqg8o HG34yr+xo/uqfeO/sHtW7/hd+UceVcbru2t9Fg7P9ds0f3p/++/6UNrTNgwssbatWHhp9+plsj6X et2LUQLttHLcclDu2/qhffa89VR7z6zPeFRaFVfPbsPjfuyrPyHOfdnDUT2rLWz7Q+413nBO2F2n b6xu0Wf1UnbadOY2DMq/fD8W//Y6z9sMZwaUcOOgbBNiGVW0fQXrBJo9wYmn8LZhY1Gq/Mp301yl xbTfnW/zs++YeMncOpaEa1mwttcv8ln9Jv0q7zOC0EepOmIRv3JtCGxVAhEAt2rKJFxzE9AQscBp O2466kQlFmGtY6FkMN9OVW1/r899A1Tnpx0JQN5869hqJHRYmeu3b4699WRpV37rbBARWuc+08ra uBBzrF9jYKIRNMAqf3W+PIcI2E5lbP302TP5w0pLo20a4bErg6FyLEd0ntvOtYEZYacaQeE13VBH XANvUCksJYbp9OvUW9+pOgnlvyPLCPdqXHWMdMKwYnlIuDLNhhDJ6YDoZBKRhNfAuX3TaKBw0EEH DW8bdVDs0kgAkxeEV37QUTMla5qrdGh/HztXv+vo4E6orE6PcEibO93pToOopqNCjJGOpqFKs1l+ lt+LHr1lJa4ZJJUTbwK3jjkhRYec2C1srUVZXe9Nrt9dx0kPIpZ8UsIhyyID5Yqv60z3bvOttOoH /CwtTEEyLVua6BwbTHtzLl17JtbTsh6Za6WnvKcclDNFTp4VD9dw8qMpwK0znawEBucJncJRoqZO LUs2b7bFSZ4lLptupIPXO1ZVwnXAAQfsYHnHGkX9QjBQ5rFv06L3Z9Hv7TQ1frOIwLBE8vJPfiQC S4O2ziAetB3tw1embtabfNeKF0uDeRye8oXnt056YEPUecADHjAMHtrf+8/SXZkwEC8nHxsgYSk9 CLfEWPGSzupv9ZuyvLc4VjPqNINiYS+RXvkiAhLs1Bvl5GF1ovSRp13DAly9Oo9zPSG7HTgq27iy ZqulD+T1zXam9bHoEldOO8HiyhRBgzVtjGlUNc1e3mY1KR+xDNlMJw+rpzjha8sMgdzadZjVIE89 pO1pnYF+K3C4Bve+PjOILjGnvd9n+VxZkt7aNOXCCz/tV+sILa1lf/vbnvqsbcNRnmud+tGyENLT 2l9etMxyyrl6ua2zTDfXjqu78CHYegGgvsBY2ukfaCt6caaepfxoF60zhq28xWq7nPpTuWoFQNbL 4sW5X3uuDZVOvsuXj370o1fbHeflAf2c1mljhFcel4fUi/JTa/nWXj/22fRyecFz1X+PeMQjBpG8 rtVe3/Oe91ydZeG8tsL15bCRHq6VL+VRZU7Y5nXWy1NvSE+OcGZ2wN3udrfVcqyN1g5yrsNZn9Aa fms55U/7pN3QBugnKQ/aZes69m3NWv6t9bs0bLnKR5bsKCfMrFGJSrhLYy8l2hf0xDH1ebWj7tVf 1nf1gtHv2llcONx990KcMLqW81zpJQ9YI7H6YNpfY4u2rKzl13p+12c2PhIG6SOe9Uz5y1JFlrQp Jq6Rx1unjm/HVmP1I7bqxrZ/0vrhs3GN+lnZJ4yqcyyT0TpluK2L29925fMxK1aY8r/05IytLOMj vMIeFwLLQiAC4LKk5HE4HjqH3iSX01mxzorBh0aUeKBDx+lk63C3jVTdtytHHYF2swedsP4tmDDp lLWuHTho8HS6hK+cdWYMBnUgXKuTTAywVlNZmBjIa7Q00K1/5YcjBsQ//uDlzd6xjQDomX2nizBU z+AHUVUnUpg4i/9z1jop5w2pzSHGBECdJFaGOv+EQh0IHQGWaOKl414CoN/q2d7oE6JaR3zQGa2B AGGIPyUSulenaZYA2Po3z2dsq0NT1+sg6Sj04pFp5tu3bx/eDE8bCJYf6zkSEAhZ0rIVR3z3R+jS OdMhx5SoYlDQOoIxAYsYq/PJST/r4lXn073FtO6988puw63zvH7Kjg6ceG9bGcSWw0gekM/78ue6 Eimlff+218BbJ76dnsffduDDwpBlQQ1a/K7jZsBYaSDvEi+VA505f4Q79/Zp6H550nOFTT4sRwRV 5uXzsjyuDmNdsytH6Suc/BRG4qmBZS14X34rszrIRKbqrPtN57ji7Lt4lDPYbQWoOj/tKA/1L1KI Ogai8hDewmHdn1lOPWU6eevcQzgo0YX1gPQwgJeH5Et1Gw6t6Nz6sVU+qx/kIQKgsPosH5suWU4a Ejdb/qxD2vTRVmnD5nXKeS8MqyPVm1EAACyOSURBVOvle/54aSPvEgnVX5vpDNKU73LKiPVStY34 yMvKvvB6GcAZ4MrXytlmOvm+hJ72OcKl/WHdop0sJ//1Qpd6yB8nzNqhMeEfcwJDtU/lZx29WNNe KTueY6DbC7QGnvhtJSecXi5VeyFsBIuykJG+8hwxtW8TKh7qCv2PVjwgvGif+FX5pMqPNomTd/Xz 9HOmcbWpjPKnnyUs/MLaZ46g2+cBL6ta14oK7lfHja1T2bY97tc/qjWhfde/mhZOv4857S4W5axZ 3Dplx4vUtq8pjP7KqUu9OK28jJsXkos4dVb1v9znecoxFp6Fp7ASeit95F8vkucRADH2DC/e1IXl pxcB+69Y0WO5kU45siRQuV6gFi8v8Yl+5Vqu4ssaUltYThyEVX9JOruGkKmt9PKHk9+IV0TOtdov 4wV9Z0teYFttovQT9srD9fyNPqq327q79V99pn5s16/UT9PPbB0OVWcR2o0N5IneeeFnGZ26tv1d PPX3tQeeoV+jD9rXj/rX25r+ZevHej/rR3khUO2pttnL0vaF7Hr9zn0hsNUIRADcaimS8CxMQCOh k1dOB70GVBp2okMJgAbrOp59p6/u3ZVj2yHUiLWdstbf9rr2vMaXONY6HWKdyuoMePumo2yaY3XQ PEuHZtYzdSh0zDzbH4FAh6NEAwNTQk7rdBr5yXk+0YSAUuFnnaDD5lw18hr9snhp/fK5Onp9507H CKsaWLnWwKg6I/yruPpNx1YHv7WOYPHC6sabO/EwQJnXwomf8zocq7PqHvxYkHlzqmNu0Ca9xBHj Pg8YQO23336DaFMc53m2PG5ww3KmOmE6qwYInsnyrRdJMcBNOhJUhNVi6uWkKaFSvjC9k9PRMsDT 4TOQs8tj+8bbtb0I5zpWG62TH00Hl3/9ySfKog6yTlXPxfc6J89Vvis/69wsZjpt8nHrdBC9+S+/ HQkwwlDCpgEhEaJ3+CgjnunNtmMNfOsteCvklLhCTGfta7CAzSJOPE3h1uEkLpaoqCwcuzKgrDDX 23PlhLjjmT6X6wcbs7jVPdOOBMYqi3WNgY+BKp4YEfEMXCp8dV17VDf4K2ew4Hp1t/zNCWdfD8m3 0merTgOu+GBhEClvceqz3kpIPPsXLa5t06fP+36f5lxLaGmZqX+0fyU+yKNEE6KLvL+ZThms8ONh kKz+IXKVU5/IM+VcL//KY5s1paueNXb0fAN21kj6B164cc5Xvqz7xMkfJ07amBos1jWOyl9xaM/X Z/WyNrOuqWP9bsAvzdo2sX7bk0fhVh+0zgZCBvSVh/UTtMfKeh8v96knewFGPnG/urrqWHkEay8y Kh3wrnq2DUN9ltdZXFVY1KHanOqTKHttWXFfXVt+jB3nuab3ayzuY3735+pZxaH/nb91Tf9bfW/z qXOLhmWsHMuvLXvluNrBeq5yrA1eK996gSbfVB1V96s7+/5h/barx2I2jSv/65r+Wfhh0t4rX+nL tf1QdW9Zf5cf6hR1W98m1+915J9+mr5U1TF+w6iWwqlrd/dRedWnwcCayeWqXNb3Nt/5Td+kxgZ1 jaPr+nvb3/GaVT/qh9rIpvpfXvYbE8l709Kw9b8+61t4+WP2Eb8YOHjJUH0pFrza0hp/1X05hsAy EIgAuAypeByOg4bZAKN926xxMbA0FakfkKrYDcx1EtfqpOxurDpUvcWBAWQ1chUewo+OUitalBVS XdMfDazaQZeOGxFBA8jh0nYSNaTEqnI64aaq9Y2rN8MEoWrk+VHTptpODH/q3v58Na51dK3OQYWt n0JjcKGz1Dp+EnqJcdXB14lwL+Fpo5zOmM5rWSryl0hDADQ4YdloMMOyjoWUsLZOnLDq35y210z7 LM1LEHKNOBMkWTnKz6ZIseazlkvbUddpJXqzSBH2Vqyzg6ewlgDIX1NwCDru8Ta7zRfeUPeilvzp 7bDpLuU8XxyJWVjJb/IP60FTjNu8WPfs6pFAVnmm/PI2t5/6JG+1HOWTsfTAt/Jqa03H7zrf5tka HIi7NFYvrccZZCsrRMCy+BNeU3Q8Q/5iHUO41DFX9g3KK80Jxf3Aaj3hqHvUrS1X9YYBSTFwnTDZ GbM2XKp764h5Lxzw02Ciz0/i0T7PvV6MbHUBUFxbSwF5o29jpF8NLorNrhyJUL2oJ21aCyH+e0mz kXliLMzqizbd1BvSrd3MyX0YKHOtc6/8vJkCoOlr6j/5lzWJ+poVijLk2do801INCA0wXddaYwkv AaleiIiHODr2rq0z+9/q+9h96klhrOnbde1WOcpvbV9LPXX2lTUR2/pR3U4QJKpWndSGX/6vF7J1 Xv1r6nBbn/pNXaj8l2NtOeZn/U6MaUUp4VIGSwD07Oof1D057khAPd2+pJCX9TVZFLdO/q2yUOcJ gNKsr/fq9zrqr0yrj9p2pa7f00cM+j52tXlt2MRJn6p18nbLs/2tPitH2s9e/KvfdwcTm5uoq5Vf /Q1l1EYYZkeor6W1PiTLvBvc4AZDmdf/bJ3y1fatNrp+9KwS7NrlX+Q7L8DV44s6grNwSifjh/LD i/Vb3vKWOwi8vd81punP53sI7A0EIgDuDamUME4loOK29ohjOcKVtTp04J3vOyksnEypW6uTUv7t rmPfufbcXvxzTqNDANMpqHhrvOqza3rXD7LXari8vW873q7vp216hs52b8ZPANRJn/aMeToz4lID pF7EnSZwCF/rt/AbWG6kAGiA6i2twWM7TVVYDSD9yVvWHiLEebOos9SycG3FrU+nWd+npa80IAp7 o876wvNNDya+1XPciwULSZYu5ZQRU7m9na6OG4ssflgwvR3s6fB6RhsX/hi0bV+ZjmG6B0vEcp6p 4+tPusgXRHlrEhqM9yJu3bfeI/G872i3IvY0f4Wzn14y7dp5zvNvvWnMf/fjVVOinZM2FqXm1Aks Kg2GiRfeykunGtjqlE8bXA0eLPhPXdByNchuB/y8kydmlTMDiH4asXj2ZXssaFj2ItfYdfOe60WG ee+b57pWfHB9X1bm8WORa9SzJW7Uff3LHufV0X0bUNdv1FEbVHmw/DQgnCft5IM2j9X9G3lUnojI 8q48ZQquesuf+k5+lEeJgARAacmKu3XCWOFUxgzYlU3Cpzqkj397b/tZ34NwJk20W4RGwgHLPxbu 6uPNzKdtWBb5LO5tnYrBWF0jPtPCL8+2Ly89Xz5p25ppYfL8WYz7emmaPzk/ncDuKMe9sD49NFvn l74eU8+O5bd+XKFO6V949LHSTqij2/5rf81mf2ctq37UJ1Q/snwze4NYq6+rflTXWX5In1b5bl94 CZ+xVln5Y6N+VL/pi6sf2zHFrPioU7w8F5aqH/VxiX/6q15wtfWLsK23z+U+/NU/+sjllANLG9Rz pE3FzTXiop/v5bkXbNYJjQuBvYlABMC9KbUS1p0IqPhNbWqdCr3EjPZ8fSYAEiMWMav3HH+b6TQ0 vWXUtLfdGto2PBs9bUID3HZGPKsXUrHQca8BUbHRATKwacNXvy1yrPv7AYbnjXUkeiZ4rjXtog1P Pa89N/bZtFnimPWuvDE0mHFvdUB8FhbTH+ykZ0Cng1BOuMY6jvX7tKN72jTpr8OcqMZS0CC21iOr 64SpLMrqnKP4sDStBfINZt/4xjcOlnttmrNMmSbaEWUPOuigYRr0YYcdNqy1KZ1aJvKygT6rPJ24 fffdd10c2rC3n+U7jOTJcjqQ87iNFGqk0XrTWFjdLzytAKjzXAKgPG26eeUhFs1teSAAbqTYQwjx rBp4S9Mx11p/9b9Lh35gVJxm5Wn+zJuG/TOnfSdkt67KbnvOZ+f9ta7yWHtuT36WT3rRUV6otKqw Kcf9ufpt3mPPor8P1z4tlYN5ylZ/X+/3Rnz3DGGpP3ma1Y2BrrUpxQ+jsmb3e2/hQgQoS1b162te 85qh7B1zzDETFjS9SDAWbuEwqK61IYWn6gvldh5eY/7ujnPKYttHwWssX6j7x84Lo7j2ZRCTqs/W isc0f903lo/Gzq31jOPy79Kmz4PzluP+vmkc2zw07Zqtdr6vZ6e1d32fHc952uM9zUQ5kX71pzwS 3Vj8tZa3dptXBuWJXgDUvzPzwe9EOuuI649Ze90L4rH1Uvt0Fg79w9pMRXgq/6l/xvoDdc28dUj7 TH5z1Vet31h89ksytX1LcXSNOM0ab5Z/OYbAViMQAXCrpUjCsxABFW+/e55GoO/06ajWwNVbHJW2 9Zr66+rhfSPOOm9X3ayOK79Z1rA4aONjCqtwa+DKGeD1Fkv9lLy6dr1Hb2hb4U0Y+rf2/NbR7y17 dBq44j18Wce/4tVbFvVTVMrrEuLqu44CK4tpTvjaQTGmfbqP3VsdHwvAW2xfJ4F4xhLVLnY6QTUw Mg3KgLIEQJ0ib1BZCk7Le2PPxEJ6mFrFCadzOpa9P77rdLK0s6ti5V2dl/YNZz3Hm2fTp22gUWnG grbt7PDTwu7TOrJ+J0Lf6EY3Gqb4eptKaCckekMqzUqkEh6WiFdfWcextx6tMI0dKz+M/eactNaJ lifL2f1wmmhZ1/C3z2P126JH6a7sEH4xaMvtvH6xBHJfKwBKlxJjcWahVBYzvXXBRlsASiN5rwY8 pshUWCpO4j2Wt+p3dVvVC3XOOpMW2BbPyhv1W3vEYpGXNe29Y5+VDVaUVYfK57VsQXs9rv3yAxuV T9rn7Mpng9LemkaY+zzBmmGeuq0NizzXpoupfW3Zaq/1WRrVYMp3dYVpgxbJn/VszxGHdmkC9+8O V/VW+yzs1M/EXi9TxKnaCWG1UZdNIQjx9eJNflqkrKun+L23OfWA+qCETnWCPpg6FMtypuS1eafO O2qXvRRrl0ggwpqOXXVMe3372TN2dz5Zq91pw7cMn6VNK7LoT1v6w5ImbZ+gjytOXgSyJFs2J9/1 ax/rx8j77UtmDForMRyIZL14uDfx6es28WYxzTJP3OWPKuvibyqu8RVexUab27YNa8Vf/lukfrTZ m36T/NnWQ2s9p/prwqdub8u636ren+ZPXTOrfZt2b86HwJ4mEAFwT6dAnr9LBEwpLIGDRypylkUa DxW6xkDjpFFyLaeSJ3ZY+0yHhWPOrwNfFb7BtfsMYpxrp3sON6zxz339gKA6zdNuFYZesDIdk7l9 u66I3RP7aV8sGRZp+KaFoc7za9u2bUNHHy8NnLXhDACrM+M88au4ulfDvYioU8+bdSTg8Lc6n4Ql U3B1MCrO8gArjrqGfwaV1elwJEK0zkCvHdB6m1frf7TXtZ/F2T0GcPVHyKj17Qxq7ne/+61a08mD NTUVN/GQ7/izqBPXio8Fj1nzGWCz3uvjxm8dM8+r8uH+MQHPeRYpFmCvN7T9QEz+s5Ndn6c9R1xw d8TEc4XHQEDeJbQQI9udullH9s/gVzl+tE4c+jzf/u6zgYvnlrDjnHxrcFn5xLnWGegLu07uRjgM lGO7G0r79Thpxp9WAGz9UWep3/DVwe7fPhPaxtK5/JjGon7vj8oRru1zWMBuW6kfpDenflyrjiSe yT/FRXp64TFtQybXKaPq4bVE3D7Ms74Lg0FZ5RPlWR3mWdKO80zTq1uRAgN/m+3G0mfsnHAoJ70o aR1GdVm9FMLRcgQV37Hw87/iXr8rc+1g1guWWX4QzOTNmiLqufKMTYvk6TGnfJbYVnlp7LqNOCeO PUdCthc0yls5+aOsVQ1yleW27mL1zQLXWqZVztr7y5+teBTOCisWVRbbsDrXnm+5ySN9+04QtfRE lVECtDVxlaExh1m/Nq58oO/mRdSYU0drm6sNHbtmo85VmvIPB2UAsz7vrPW8sevHzq3lz67+3qZf 69e0sKjjpCWRhxN35d4O7bPKsbLk3nnK8bRnt+HbSp+Ft8+z2i87ILdrnHrRcsyKNXDr9OmrPmnP b7XPY/lEG6AdVD7LuU5Z5fQ/LAvz+te/vn4e6lPWzV6Qt+1l1TurF27gBy/G9VHX84zq0zrqB06r twRXHdTWjV6IyO97Q/puIO54tSQEdhxlLUmkEo3jDgG7lLaVvg67hWr7DoZOO+usqrxZ2emolgCo U2swVQKSxp3gxdJG58diuIs4g+a+I8QaSWOp0axGxzPbxpSQpANaDS5RxiYK+6/susk/YTG9s7VM 0QhZG6OP8yLhHbtWp54FWzFh4WPR/loXg7AlLPU7P4R/o9/QEzT4qXPFEWStNUc82LYiQvgufUq8 co2OqvCXw7QfuIiPBY41+rgSNVi5zHLEAh0bazWZpmBA5FnSUZpKd2JsTafll3sq3/nu2l11BtmH r2y6oaN1t7vdbdiNTvzkEeVBPFhUtIKmfGK675gTH1PaLPzclqe69ja3uc0Onbk67yh+BIZjVzbh sGgyqxjhEE/c5XdiFvGyBHbHsefwz3W9FQHxnMBL1OBndVaLv/tYWRLGWHOV3xaW1wEnDgqP++RX f/KLfCNfyU+1uzK/dtWJQ4m16/FLOOV7x4oLfwyAa2dZ6S2veZnROmVFWpcjwrT5T57oO7l4KAP1 LEfP8kdoV0ZaK7mnPe1pwzqEfiOcHXTQQTs8o57dHlkm6qgbUHC4q6vlD2FWjjxX2IjDhH7T7A1C 1MUb6QwWTGUq96lPfWrY/fWhD33oEA4iGivYVqRW31RdXfft6lE939cP0qFNL8/AuIQ13+UL5cAA Sz6Q3jhxrjP1isgpD3lZ8spXvnKHumC4sPknr/ZCojZG+1OLrasf2zA0t69+tK6eciX80lH7bC1S O4KrE9SRyr78xi8vs+zg+KQnPWmoU1c92oQP6kSihnpA+AgWyn8r8uLaTmtTb+2/0va+5z3vWW2T tXvaQNarJQJiLB23ulOGj12pp/GX5l6M+lwOF+WzNhxyjXxfLyPUA8q8F5PljjjiiKEu0IZIW+Wm pkn/v/buZ0WWIgvA+Myb3Edxqyt3ihsHRVEUd64UEXUhguBWFzILRRB8h3kHX2AeZfpXw2mikqq+ 3X3r3u6b9ztQlZVZmfHnixMRJ05EZs4565aumkxS3yduZeA6K6fFMXoiPOVE97zx/pNPPjlMJq3t 2xr2JX6v9ov2SNnqz+Wb7jiGi77HPrlEPb5E2qUNL+0WXSbaBcdW8b92ZuWIufbNVj02iYC/j8fs sDdMrrtmymfqsf6fHnx91Q+oE3sTLE1UaW+HJcew9sObf7Wd2ju2OqfgCB2n63T6sQu7QPsozdoB Oq0f0RfaH9Ee0H3CUWyFt3Z8xiwmdHDRHrrtl77QJX3Y8xL66PMswjYxsa6+TN1Zw9N/0f+580Ib YGUsB/CsBF/P73cEHjuBZx+JPvYclr7dEmCY/Odqto3RQzTIBvEGrVt5cuUoMhia29TMUHMqcHoQ TgId3xjxwub0eO3qAeEMpfW23G3Yp/YNdqeTnP8Z1VaLcRwxJHQynBbffvvt4RT7bktmQHF2EAaW 2zgZ3Ixws+0608mzc955552LOi+ESXTev//++7XjjeHjpRYcDnhyqHoBwQj+bhM1U3xJwYgzz0BS uRADMvnGy+1G+KyDdfzdnjvCUGfYS+OEwTHy3nvvHQYv9GKe/TTXnNoy8v59ZQj//PPPB2cahy7n Esez8BjKU3Zz/dYhM8cvsWVsccJKDyOUg4/O0LWVh7g4Wtx2e0oYqFa1uF1XPlZh+BjAn6pXzsOT s4ZT6KeffjrcBkwH6Ov8ZwA33F3DiXUuPGVkEM6gG8OTcSpsjnzXKk8OkC+++OLaQcEwZYxxUuNC rDSUrzfffPPgPHSdlUwGdZ6dh9G0AYcLHtGXWWXlspaHMpz0jrP5lANQW0YwV485W8aoZaivznLn GeB+8MEH1wNy51hd6m3QVlCKE8spD04ExrCXkWgDOBKeJhxJ77777uFtn8LxcSs4XaWXnLsGCcrH 6tZZJaqOX1Lo1b+unDoGa+oz0bZxpmvv6J/8j0Nt4lYH6NglRb+iPeFsE68y0t/4jGjrvcl6+jr7 6uTrr79+cIZof9x6/+eff84l/zDZZEWmdtokx+q8vT5p+SFueVM/hok6p05rEzjWtW1rv7Ncfv3T y304a2eCiu5+9tlnh7bbZBoHg35X2XLAGkSfaweuA73Qjx9++OFQxspfujBW/8cJJRpc6fSI8tBf 639mFSAGJkqs9MZLXy68tb19GqcJ/0VvOYK/++67Q1rlTfswNo+02MfJYypGPvzww+t9fYzV4gbK k19lyDGnnTVxyi7Y1p0JyxYzPN1GPc9vVgbqnmvnWbPC0hZo38QhzIlzDe/Sv7crvQz4vQxBG6gv l1Z17tNPP72+M0Ma1WMOlKnHdEK6V+HsZsMROqIP87bR999/fz3t3r/xMWmCK87KWHrVt1W0ufSX 7kqHcpcnk5smxU2EqMfjyNWfcnorI/VYvySvU48xEob49iocwPrIedEZbpxj7nKgy+xQz+ld6xNW r12NIaY/fsxsPLvZM021j9p+NgN9Wuuc8lXPR+x7ccgbb7xx6E/nuLZVeL/++utBx0y+rG3CY2wf 6bTnHd4k+ocRnNii+os96/3kt+3+COQA3F+ZvjI5soJkfUirgcS5wSLDjVNiHIAGnxwAzteoM2o5 t9YVYAaFY/Qz1HSEMwB+GmTGl47fIGdmxhhIOkbOqukwZjZpwuM0+fjjjw8OxxlE6TgZdDocg7O1 8+TUtBJB+i4tjP3PP//8H19++eX1gBQDz7qTFvlZeXC+MpQZwJcUcXEscgpYkTgGqwEuA1QapGXE bBzjXJmvwsA1y7e+CIORztAVhplKZTUD4PXa9be4OCqkhQ6NwS9drp3ydg1HlhngSzNZ8yw+H2my OmX4rGkWPyPVKo1zYiBigChfq9Djpzk+xElPPQ+Ss4L+K7dJy8pEfRPm1kE+caob6gHD0sqsEbpn QCiPIxy4s0LJdQY1nMM+U1cMXuRLesiwsyXKUzofmygz3OnoCAfgPE/Syq9ZDTj/2xrATfuCgdUZ 25VbWx3XDnGIjeBBbzmWlNPbb7990ItpP/2vHHCduse5Y+BwTpQ7R+wff/xx7TA0OFWmHAo3lc+5 MO9zHBu3daoP2rIRafE5JU+uHGnSzhF2SZF3zvG1H5g6M/HYtyprnWzByqSDW+v1ARy12rHpv+TD hIbrlDVnsoHplNWEvW61l+rcWv/VOc59zAxibc8xEpaVlRzO3kI+aREvh8NMosnP1EG/tbu2z1v0 pz7yIL5tnOobZ9/6lnRpGmePvua/V45vaXftDPRP6bx6Kp7HJtIt/TetxlHmPoRNtXKSJ7fpspdm pZP/OYPcBug3HdMWiGPa2C0Hkxcmb9hHY+fQK4w5WKaMVj0RxrnwtuE/yz5nhhVMU67ypA9RL6aN 4gyy2p2+E3qhHk9eHBsWfo+wWUw+jcgnO+tSDkB13WTO2K0Tz5Ybxx5H/Kqj8kT39R9+c9x///33 17YffeegnQkn+VvLR/1xbK/CxuYE9XIK5U3oOp3Vjg+Lwx9XXziyQ01svQyiD+Kwnrp3qiw5wdXb VdghuLCrZ/W3/8cunXq0XsPZRl8em9wnTfe55rHlu/S8mgT+PyJ6NfNerl9yAm5PWmeVdFznHICM rO0tfmZiZ4aWwWNFC8N9FR28Y/4b48//OretUbVe5zdnBKeK1WgM6blemAw1H79XkQez4z/++ONR ep3HQJ5O2WDaakLOljFC13CEvcp2X9pXp4zfE/Z6nRlPTsD1tqhJy+Rf3syccRSus+fCW+OY84U/ x23n+Gzn/3XfrKPZaTOqZq2J8DFZGUon7gahq3HrfM4UzlUv4lgFG2VsRc12gL9lIsy5vVv6DJQ4 ig12bCdfBsvSwlg6d9vtmoa7/pYXzsx57pLrpfWUTnEUyJvb7DjmzgnjjpN8a9AY6Jxz1gmLXhvw zXNQlInBwjDBaDhKr7rEoURvzonzrFTh4OLQnRn0yaN8bnVaWMI0gOQQke8RaZqBrd+jWwxRjo9J yxx3nfAn3XRs/W/CXdMg3K3OzXn32eK6dWLjrK0imFi5vIrynfrhuPRI1/Ca7XqN31uu8rvWK6vf rAhk7I+4ZvKsfq4rA5zjv61Iu3rM+TZt7YRzqnzU1e3t4Nsw77NvMOd2Q7e63aTbwqaDVmGfWtk8 9d159GOrI9t9TEanXDN5n3KxXbk7hwhnPcfvCVsZ6zM8pH9t2+Ya+eNgWMvu/6Eef6tz2k195SrC oWucPvqyVSYNc0xapv018J22RJ6mfDGTfnlXDsp31dkJ61m3W/0Tn48020qrflQbwMln5ZnHJmz7 AOfpx90O99rVxAWH5Tmh01bMWjU3bZZz17SIW/4fQkYnbhu3spLeVbQ53ni8nRSSJ+Vs4kB/M2Xv 2rWe2MdU3bOq2/nTd4jLuXRl1RPtGr1UNq4d2daV7f6W9an8TFiztaKHY/3JldNf3Zk+c9jJ57b8 Jp75b1hMmLPdhuE8x87JNp7t/qnrbhOH9GIlvPUz4WHMAcghqM2esnTNqXpM1/VVp+rxlOmE/Ri2 0rSKfG2Prf/Pbzr/76uVnh65M+2A69TvVffYZpyn6sGqrxOO7domKIP1+vW85/X7VHzyQn+GhfZR 3WTLmty3qm/bH8ufcZfJQBNr2tNzIiwTttrH9bxVr8V9Km3nwnyRx9cy8/umuvsi01VcEbgPgfOj wfuE1jUReIEEGCIcQtNZGcBYwXBKDJx1UquDkLE+HY3BtgEhA8ZKCiv1dGwGTQarOiwrXuZ85z25 MhBvEgaR1S5W1piVNcPmM05L4Z9KL8PirbfeOjiOvvnmm8OqRTPQjFcG6XSibrey+mNrYDBYzdKv ndWskpr0Srt8cVoR+cFoKwZobqX1nBPGupl+M3qTFtd4NopbgAz4xskpHOw4BmdW3MBhZSp9MwB0 PuNqyoehL28jDFDGlNVPbkszCy0duAgDEw4fM64Gw45tRR6tJBTvb7/9dlihIr1majk4OIgZsrPK yfXysPJVNribCbe6xuos4dFFeshgcg5ngbgwXgeC2zTdd59TjgPYqgPP2VIu9IrjTXqlwUf6PafE W9LGyXUuzmGB3axuUafk4RTPCUc8Vk1w+Fl1ZHXBOoBzLS6cE26Z5kjC/Cahw7PKxK2Nbnv3dmUr 2aYO4ro6PCY8z8VzOyeD1C3D6hw996FH0iJN2DDkxaM+EA6O0UHhj5OK3pksUMY4SR/OVgzJP1Hf V/0/HHyGL2l87crhgOsI58JqOBucWdU5bYo8rQ4M+dVGblcATng3bYU9g18svvrqqwNv7RkWyphz loOMU88KIO3mCIfyVvCxqhBjt63/5+oRDuqQspEH8U35GHTQPQOPS8uUnTRb+a0+a0uwZtRrK3y0 QZx/yn9bj5XP2r4JU5pH7Lt+9MlxbeRafnTG/zMRNdc+bStuej6iHkx/YDWl1XfyQX+1hyZxrCK3 6uecCJNzXln88ssvh/ZVXVPG6olyc8u2ujgif1udx83Eh1vj9BlWx8xkgPCmfLXZdIezfjs5N+Hf dysv+qVzbZ7/MdMOcSzRMX3m1OVtvPQSA+0KfdH2q1P6IPnXL+sLDYD1hZiN08SWnozzlF7MKt5t PM97n35qD06tyjkVN07rpJ5z5FebY4KGU1Tfo3yVJ+fA119/fVjl5hbeaZeEMzwmHnqg7KWH41Ud FI600RP1zTnKhJ5wzLEBHBvB0arzEeetoq5xNM6trPRBn3aTSKcVrPpMj/OQP3mZFa2ufXLVX6zt rLJVxvqau4g8rvV4vRZndpv6OCK/WJ4TaXfO5PfceaeOs8/W+uK3u0v07W4Jd9v7uXrM4UUntnam ePRJ2ri1D1rZnUrL8zyGKz1d22Xtz5r3c/G7lr66VdYzKz1eYfoNZakN0CZq/7Qn2z5jDZe+aP+J cnseE8VrfOtv7Zl6vTJY/5duZaTs1BeP6JBedVH7tRXpV/Zucdd3WDWu3sw4Sp+AjTqsfTSJvrLR Vs++8E+Ni7ZxPsQ+XvJF5NmdKkkEXlYC/7wa0BxPhbysOSndrxwBTijOl1FhnbOO5pyYZRqD1Dka 8G2HZlDL0WBZv/B0RDMoZYhNXDophth0WufidFwaGbQzszZh+E8azhkezpdeaXLbCAOU4cKIP5V2 4Y24bp1Vk4d1cCNN62y4/EiHPJ8S6R+njrQw5p5cGcHSM3y2hsFcIx+E4Y6X49KHg2scF8ZaPtKB r+OruEY6nMvwN7g02LIKcgYL2Nwk8m2Q4ZY66eGomAGKsCe9wsBkGx524pcPA2osfOwbVBoMGFhO mDel5Vn+w0JafOimtHjWF6YGtdJhYHpbPTVo4Hhe3+psBajB0NMMdsxwxYBBLC2MP+nihJj04C09 txV5FK7w/Z6P6+WTTm/LZ8IeHZem/17dskNfxK1sGLbSRb98JoxVB4U/dYK+Ckf8juNKOEodJ09r fw4n3fGLPsrHiLSu9VjcU5ecIw3+X+uxMlh1esJ62harbVkpC+nRPhrsMvoZ9uKc/yZcTM+1bc6Z emxQ6XEOnGDa73HMGLxP+az5mfAvtZ22ks7SE/kziGPc09ctzzXelS29wMs1I6s+OYaJdmry4//R 77nmNltxnapLwpIft2P5bSJCGciDdm59U7OJHc97m7RMvPKvDmsf6TeHgrIQnzBH350vXGV0Suic tNhia2LFvgGlOmgQiAdmU/9OhXOfY+qpuNa0ruHgNx/5X9uA9bztb+HSW+GyE/SF0m8FoTZSOMp3 K1s9OXfe9rpL7ytbZSgft5FzeubaCcvEqLLlUNDO0zd81niEM23mNt5hqi7olzmY6R2d0xZwkuA1 H2GNbNvHbZuz6qBrXEtnb6Nv8iCP0ieclRmdWduFS9fjyR8dFvbI1PmVwfw32y2TOf60LSbytA1b 3kfnOT+UtfJRj5WPiVfXKp+17Zv4cHS9cEa089t2Z/57EVvlKk0jUx+3eZ//t9tVZ/Hw0Q9y5mK4 6sb22tl/6DZB/fQ5JTisH+V6mzojLFzprK1nA7uOc5m+nOO82lHiHV08lbaHPLYts21//5BpK+4I 3JVADsC7Euv8V4IAo4XcttN73lDGAGU03dZIeV5peixpGcMcj/sYk8r4vtcOW2mYj2PCm8+c86K2 Uy6TjqcxYQRbfcVQs8LBS1bcUj6ruAxk//rrr8Oqi6eFtc3jpAWb0VlcHkomPbdl81DpfFniHZ6X ah+F5zN15676dglu057sQUe25WOfI+82DsBhuQ1jjt9nO2wfS3twnzxsr5k8OT5t3PacV2F/OFyK wdhe0xY8ZL/xKpTfXfI4Zb2nenyX/J86d5jQ04fot06l6bEcm7p8qbbhseSrdERgDwROT93uIWfl IQLPQOBSA9tnSMLRpY/JsHgsaWFwPUs5Pcu1UzgzSJn9h9zetVy8tc5tmFZy/f3334ePFQcjbvlw G8tdw3X9fa6ZeJ/H9rGl53nk8UWGeWmewrt0mHfl8aztyV3je57nX4LlJcKYPO6J7Z7zNHm7y/bS ZXuJfvku6e/c2xO4dFnfPubHe2ZMzpdNdfk8m/6JwEMTyAH40CVQ/BGIQAQegIBbYj2vxe1+Zmqt +Blxu8ZHH310uFV2jrWNQAQiEIEIRCACEYhABCIQgZeXwOkHfr28+SnlEYhABCJwCwIcflb8uRV4 df55K6OHsnuI/6ln+twi6E6JQAQeGQHPWVpFvU8iEIEIRCACEYhABF4tAq0AfLXKu9xGIAIROBB4 cvUSF29vtQKQeHC1l2N4cYC3snnAcRKBCLz8BNym5g3p80Z2OfKGZceTCEQgAhGIQAQiEIFXh0Av AXl1yrqcRiACEbgmYNWfN7DO6j9vaOP08+yvnt1yjakfEdgFAW+RX1f9eRPnTW9p3kWmy0QEIhCB CEQgAhGIwBGBHIBHONqJQAQiEIEIRCACEYhABCIQgQhEIAIRiMC+CPQMwH2VZ7mJQAQiEIEIRCAC EYhABCIQgQhEIAIRiMARgRyARzjaiUAEIhCBCEQgAhGIQAQiEIEIRCACEYjAvgjkANxXeZabCEQg AhGIQAQiEIEIRCACEYhABCIQgQgcEcgBeISjnQhEIAIRiEAEIhCBCEQgAhGIQAQiEIEI7ItADsB9 lWe5iUAEIhCBCEQgAhGIQAQiEIEIRCACEYjAEYEcgEc42olABCIQgQhEIAIRiEAEIhCBCEQgAhGI wL4I5ADcV3mWmwhEIAIRiEAEIhCBCEQgAhGIQAQiEIEIHBHIAXiEo50IRCACEYhABCIQgQhEIAIR iEAEIhCBCOyLQA7AfZVnuYlABCIQgQhEIAIRiEAEIhCBCEQgAhGIwBGBHIBHONqJQAQiEIEIRCAC EYhABCIQgQhEIAIRiMC+COQA3Fd5lpsIRCACEYhABCIQgQhEIAIRiEAEIhCBCBwRyAF4hKOdCEQg AhGIQAQiEIEIRCACEYhABCIQgQjsi0AOwH2VZ7mJQAQiEIEIRCACEYhABCIQgQhEIAIRiMARgRyA RzjaiUAEIhCBCEQgAhGIQAQiEIEIRCACEYjAvgjkANxXeZabCEQgAhGIQAQiEIEIRCACEYhABCIQ gQgcEcgBeISjnQhEIAIRiEAEIhCBCEQgAhGIQAQiEIEI7ItADsB9lWe5iUAEIhCBCEQgAhGIQAQi EIEIRCACEYjAEYEcgEc42olABCIQgQhEIAIRiEAEIhCBCEQgAhGIwL4I5ADcV3mWmwhEIAIRiEAE IhCBCEQgAhGIQAQiEIEIHBHIAXiEo50IRCACEYhABCIQgQhEIAIRiEAEIhCBCOyLQA7AfZVnuYlA BCIQgQhEIAIRiEAEIhCBCEQgAhGIwBGBHIBHONqJQAQiEIEIRCACEYhABCIQgQhEIAIRiMC+COQA 3Fd5lpsIRCACEYhABCIQgQhEIAIRiEAEIhCBCBwRyAF4hKOdCEQgAhGIQAQiEIEIRCACEYhABCIQ gQjsi0AOwH2VZ7mJQAQiEIEIRCACEYhABCIQgQhEIAIRiMARgRyARzjaiUAEIhCBCEQgAhGIQAQi EIEIRCACEYjAvgjkANxXeZabCEQgAhGIQAQiEIEIRCACEYhABCIQgQgcEcgBeISjnQhEIAIRiEAE IhCBCEQgAhGIQAQiEIEI7ItADsB9lWe5iUAEIhCBCEQgAhGIQAQiEIEIRCACEYjAEYEcgEc42olA BCIQgQhEIAIRiEAEIhCBCEQgAhGIwL4I5ADcV3mWmwhEIAIRiEAEIhCBCEQgAhGIQAQiEIEIHBHI AXiEo50IRCACEYhABCIQgQhEIAIRiEAEIhCBCOyLwP8Aq3n90t2tEy8AAAAASUVORK5CYII= --_004_D6BA5A34E4CF48569CF7E75C98A928ACjunipernet_-- From nobody Tue Apr 7 14:43:53 2020 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 1D7463A08E5; Tue, 7 Apr 2020 14:43:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Gyan Mishra via Datatracker To: Cc: last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158629580378.13606.6350807287790835622@ietfa.amsl.com> Reply-To: Gyan Mishra Date: Tue, 07 Apr 2020 14:43:24 -0700 Archived-At: Subject: [Idr] Genart last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 21:43:25 -0000 Reviewer: Gyan Mishra Review result: Ready with Nits Reviewer: Gyan Mishra Review result: Ready with Minor Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-rmcat-wireless-tests-08 Reviewer: Gyan Mishra Review Date: 2020-04-7 IETF LC End Date: 2020-04-8 IESG Telechat date: Not scheduled for a telechat Summary: Ready, but with nits and minor issues that should be addressed. There are just a few minor points that I would like to bring up related to clarification of how BGP Flow specification works described in the introduction as well as updates to "Dissemination of Flow Specification Rules" [RFC5575] and "Clarification of the Flowspec Redirect Extended Community"[RFC7674]. Major issues: None Minor issues: I am familiar with BGP Flow specification and would like to recommend some verbiage that may help in the introduction as far as explaining how BGP flow spec works. Ssince the introduction has been re-written with this update, this could be a possible addition to the draft. This could be placed at the end of the introduction if desired. BGP flow specification is a client-server model that allows for a more granular approach to DDOS mitigation than its predecessor, “Remotely Triggered Blackhole (RTBF) which tagged a prefix with a community and sent it do a discard next hop. BGP flow spec has two main components, the “controller†being the BGP speaker device which acts as the server side, which injects the new flowspec entry, and the client side which is the BGP speaker devices that receives the flowspec NLRI and acts on the instruction to match a particular flow with Layer 3 and Layer 4 parameters and then implements the hardware forwarding action requested. Nits/editorial comments: 7. Traffic Filtering Actions This document defines a minimum set of Traffic Filtering Actions that it standardizes as BGP extended community values [RFC4360] Any mention of [RFC4360] should be updated with [RFC7153] IANA Registries for BGP Extended Communities. From nobody Tue Apr 7 15:23:55 2020 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 251463A09AF for ; Tue, 7 Apr 2020 15:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 zHRC55N7CC_h for ; Tue, 7 Apr 2020 15:23:52 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 F0E173A09B0 for ; Tue, 7 Apr 2020 15:23:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Tue, 7 Apr 2020 18:23:49 -0400 Message-ID: <003c01d60d2b$36783250$a36896f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01D60D09.AF67A3C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYNKbLttlifEHJ9SUaxzPgT467Y0w== Content-Language: en-us X-Antivirus: AVG (VPS 200407-0, 04/07/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IDR interim - 4/8/2020 - at 13:00-15:00 UTC - update X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 22:23:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01D60D09.AF67A3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings IDR: I did not correctly provide Randy's title. The correct title is: 3) Weaponizing BGP using Communities presenter: Randy Bush paper: https://archive.psg.com/181101.imc-communities.pdf Time period:15 minutes Just in case you missed the link to the web-ex info and agenda link is below: Or you can just go to the "upcoming" meetings to the IDR meeting for 4/8/2020 at 13:00-15:00. Sue ----------------------------------------- WebEx: https://ietf.webex.com/webappng/sites/ietf/meeting/download/5FF4D33B273CA952 E0536284FC0AC72E Etherpad for note-taking: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-idr-02?useMonospace Font=true Etherpad for virtual blue sheet:https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-2-bluesheet jabber: idr@jabber.ietf.org Agenda: https://datatracker.ietf.org/doc/agenda-interim-2020-idr-02-idr-01/ ------=_NextPart_000_003D_01D60D09.AF67A3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings = IDR:

 

I did not correctly provide Randy’s title.  =   The correct title is:

<= br>3) Weaponizing BGP using Communities
presenter: Randy = Bush 
paper: https://archi= ve.psg.com/181101.imc-communities.pdf<= br>Time period:15  minutes 

 

Just in case = you missed the link to the web-ex info and agenda link is = below:

 

Or you can just go to the “upcoming” = meetings to the IDR meeting for 4/8/2020 at 13:00-15:00. =

 

Sue

 

-----------------------------------------

WebEx: https://ietf.webex.com/webappng/sites/ietf/m= eeting/download/5FF4D33B273CA952E0536284FC0AC72E

Etherpad for note-taking: https://etherpad.ietf.org:9009/p/notes-ietf-inter= im-2020-idr-02?useMonospaceFont=3Dtrue

Etherpad for virtual blue sheet:= https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-2-bluesheet

jabber:  = idr@jabber.ietf.org

 

Agenda:

https://datatracker.ietf.org/doc/agenda-interim-2020-idr-02-idr-01/

 

 

------=_NextPart_000_003D_01D60D09.AF67A3C0-- From nobody Tue Apr 7 16:09:41 2020 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 8EF863A0786 for ; Tue, 7 Apr 2020 16:09:39 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ6I4ysptOjz for ; Tue, 7 Apr 2020 16:09:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 65DFC3A0780 for ; Tue, 7 Apr 2020 16:09:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jLxLb-0001tE-Me; Tue, 07 Apr 2020 23:09:35 +0000 Date: Tue, 07 Apr 2020 16:09:34 -0700 Message-ID: From: Randy Bush To: "Susan Hares" Cc: In-Reply-To: <003c01d60d2b$36783250$a36896f0$@ndzh.com> References: <003c01d60d2b$36783250$a36896f0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] IDR interim - 4/8/2020 - at 13:00-15:00 UTC - update X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 23:09:40 -0000 > I did not correctly provide Randy's title. if warren is 'Ace,' i guess i am 'Deuce.' randy From gongxia@chinatelecom.cn Sun Apr 5 02:51:08 2020 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 842083A0900 for ; Sun, 5 Apr 2020 02:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 JrBPbji3vyd0 for ; Sun, 5 Apr 2020 02:51:04 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id EBA413A08FB for ; Sun, 5 Apr 2020 02:51:03 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:35686.561968910 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-113.111.9.218?logid-98BE0828866247B9B7FAE56043BBF61A (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 8478E280079; Sun, 5 Apr 2020 17:50:53 +0800 (CST) X-189-SAVE-TO-SEND: 71041897@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id 98BE0828866247B9B7FAE56043BBF61A for shares@ndzh.com; Sun Apr 5 17:50:55 2020 X-Transaction-ID: 98BE0828866247B9B7FAE56043BBF61A X-filter-score: filter<0> X-Real-From: gongxia@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Date: Sun, 5 Apr 2020 17:50:33 +0800 From: "gongxia@chinatelecom.cn" To: "Susan Hares" , "'IDR List'" References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.10.151[cn] Mime-Version: 1.0 Message-ID: <2020040517495963614112@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart018681472161_=----" Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 00:46:36 -0000 This is a multi-part message in MIME format. ------=_001_NextPart018681472161_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IFN1cG9ydCB0aGUgYWRvcHRpb24uDQoNClNpbmNlIHRoZSBsZW5ndGggb2YgdGhlIHBhY2tldCBo ZWFkZXIgb2YgU1IvU1J2NiBpcyBub3QgZml4ZWQsIHBhdGggbXR1IGNhcnJpZWQgZm9yIHRoZSBT UiBwb2xpY3kgdmlhIEJHUCBjYW4gZGVhbCB3aXRoIHNvbWUgbmV0d29yayBkZXBsb3ltZW50IHBy b2JsZW1zLiANCg0KDQoNCmdvbmd4aWENCiANCkZyb206IFN1c2FuIEhhcmVzDQpEYXRlOiAyMDIw LTAzLTMwIDIwOjM1DQpUbzogJ0lEUiBMaXN0Jw0KU3ViamVjdDogW0lkcl0gV0cgQWRvcHRpb24g LSBkcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1LTAzLnR4dCAtIDIgV2VlayBXRyBhZG9w dGlvbiBjYWxsICgzLzMwIC0gNC8xMykNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIGFkb3B0aW9u IGNhbGwgZm9yIGRyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1tdHUtMDMudHh0IA0KIA0KWW91 IGNhbiB2aWV3IHRoaXMgZHJhZnQgYXQ6IA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS8NCiANClRoaXMgZHJhZnQgZGlzdHJp YnV0ZXMgcGF0aCBtYXhpbXVtIHRyYW5zbWlzc2lvbiB1bml0IGZvciB0aGUgDQpTUiBwb2xpY3kg dmlhIEJHUC4gIA0KIA0KQW55IGRpc2N1c3Npb24gcmVnYXJkaW5nIG9uIHdoZXRoZXIgb25lIGRl c2lyZXMgDQpTUiBQb2xpY3kgc2hvdWxkIGJlIGNsZWFybHkgZGlzdGluZ3Vpc2hlZCBmcm9tIHRo ZSANClRlY2huaWNhbCBkaXNjdXNzaW9ucyBvbiB0aGUgbWVjaGFuaXNtcyB0byBwYXNzIFNSIHBv bGljeSBNVFUuIA0KIA0KVGhlIHF1ZXN0aW9ucyBmb3IgdGhlIHBlb3BsZSB0byBkaXNjdXNzIG9u IHRoaXMgZHJhZnQgYXJlOiANCiANCjEpIElzIHRoZXJlIGEgbmVlZCBmb3IgdGhpcyBtZWNoYW5p c20gaW4gbmV0d29ya3MgdXNpbmcgDQogICAgICAgIE1QTFMtU1Igb3IgU1ItVjYgYW5kIFNSIHBv bGljeT8gDQogDQoyKSBBcmUgdGhlcmUgYW55IGVycm9yIGhhbmRsaW5nIGlzc3VlcyBiZXNpZGVz IHdoYXQgaXMgYmVpbmcgDQogICAgIFRha2VuIGNhcmUgb2YgaW4gUkZDNzc1MmJpcy0wMy50eHQN CiANCjMpIERvIHlvdSB0aGluayB0aGlzIGRyYWZ0IGlzIHJlYWR5IHRvIGJlIGFkb3B0ZWQ/IA0K ICAgICBJbiB0aGlzIGNhdGVnb3J5LCBwbGVhc2UgbGlzdCBhbnkgY29uY2VybnMgeW91IGhhdmUN CiAgICAgcmVnYXJkaW5nIGFkb3B0aW9uLiAgVGhpcyBjYXRlZ29yeSBjYW4gaW5jbHVkZSANCiAg ICAgZ2VuZXJhbCBjb25jZXJucyBhYm91dCBCR1AtTFMsIE1QTFMtU1IsIA0KICAgIFNSLVY2LCBh bmQgU1ItUG9saWN5LiAgIA0KIA0KQ2hlZXJzLCBTdWUgSGFyZXMgIA0KIA0KIA0KIA0KIA0K ------=_001_NextPart018681472161_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A= =0A
 Suport the adoption.=

=
Since the length of the packet header= of SR/S= Rv6 is not fixed, path mtu carried fo= r the SR policy via BGP can deal with some network deployment problems.&nb= sp;

=0A
gongxia
=0A
 
From: Susan Hares
Date: 2020-03-30 20:35
To: = ;'IDR List'
Subject: [Idr] WG Adoption = - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 -= 4/13)
=0A= =0A

This begins a 2 week= WG adoption call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/=

 

This draft distributes path maximum = transmission unit for the

SR policy via BGP. 

 

Any discussi= on regarding on whether one desires

SR Policy should be clearly distinguished from the

Technical discussions on the mech= anisms to pass SR policy MTU.

 

The quest= ions for the people to discuss on this draft are:

 

1) Is there a need for this mechanism in networks using

     =    MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling issues besides what is being

    &= nbsp;Taken care of in RFC7752bis-03.txt

 

3= ) Do you think this draft is ready to be adopted?

     In this category= , please list any concerns you have

     regarding adoption.  This catego= ry can include

 &n= bsp;   general concerns about BGP-LS, MPLS-SR, <= /p>

    SR-V6, and = SR-Policy.   

=  

Cheers, Sue Hares=  

 

 

 

 

=0A ------=_001_NextPart018681472161_=------ From nobody Tue Apr 7 19:43:21 2020 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 1EF5E3A07EF for ; Tue, 7 Apr 2020 19:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShkFqp_tZLbY for ; Tue, 7 Apr 2020 19:43:17 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594163A07EC for ; Tue, 7 Apr 2020 19:43:17 -0700 (PDT) Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8C7D0D5E6A67B56FF3CC for ; Wed, 8 Apr 2020 03:43:14 +0100 (IST) Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Apr 2020 03:43:14 +0100 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 8 Apr 2020 03:43:14 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.216]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Wed, 8 Apr 2020 10:43:10 +0800 From: Mach Chen To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAGwQTXw Date: Wed, 8 Apr 2020 02:43:10 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.48] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297A6681Bdggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 02:43:19 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297A6681Bdggeml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Support the adoption. Best regards, Mach From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 8:36 PM To: 'IDR List' Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297A6681Bdggeml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Support the adoption.

 

Best regards,

Mach

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

    SR-V6, = and SR-Policy.   

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297A6681Bdggeml510mbxchi_-- From nobody Wed Apr 8 00:36:48 2020 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 13E9D3A0B22; Wed, 8 Apr 2020 00:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 pv7l1oJvIeub; Wed, 8 Apr 2020 00:36:44 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 D72BE3A0B30; Wed, 8 Apr 2020 00:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ShjrA8WxbI/1rRE7q7QjJ8CXZf1XIkFCsg1/6YRuKcc=; b=F2/XnXa+mxbGwYBqVytIkHalYo wFXDBtM8vklrgrYxqRIUH1G2eng6iaM42StxC140tAzwFEfymMZwa6WsjHQb6NbI5VWs+o13cTQqV rQwluZef/HUSPtH0a5UKxMICVbAmoSphowJybkPBhsugT/R9CVnbPCfHGn0kSTpitlEB5UAZ7EBto YW9p49Es2HxenDCcfDFZdX3VPjxQoIiumpNxxzYu1nZZwqaLSuvvQQvLb9updCkZU0uKRYl/EaTxI iYgcKiLQ5mVTC9CWzQRHxjTRsofSZmEq/QgTgpqtj9Ed/zSv0hYlg/BPaMPxTPQs/+LQQgmoAqb6h 5Tbag2JA==; Received: from 089144206206.atnat0015.highway.bob.at ([89.144.206.206] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jM5GH-000745-Lj; Wed, 08 Apr 2020 09:36:38 +0200 From: Christoph Loibl Message-Id: <3A63035D-C0F3-4830-8EBF-8A99411A01C6@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1E7C30E-7E6B-4BED-AF26-961B3004F73A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Wed, 8 Apr 2020 09:36:33 +0200 In-Reply-To: <158629580378.13606.6350807287790835622@ietfa.amsl.com> Cc: gen-art@ietf.org, last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org To: Gyan Mishra References: <158629580378.13606.6350807287790835622@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Wed, 08 Apr 2020 09:36:37 +0200 Archived-At: Subject: Re: [Idr] [BULK] Genart last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 07:36:47 -0000 --Apple-Mail=_A1E7C30E-7E6B-4BED-AF26-961B3004F73A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Gyan, Thanks for the review. I will collect the results of all reviews and = comment on those later. I need to note that the reviewed document is = draft-ietf-idr-rfc5575bis-20 not rmcat-wireless-tests ;-) : On 07.04.2020, at 23:43, Gyan Mishra via Datatracker = wrote: Document: draft-ietf-rmcat-wireless-tests-08 Reviewer: Gyan Mishra Review Date: 2020-04-7 IETF LC End Date: 2020-04-8 IESG Telechat date: Not scheduled for a telechat Thanks, Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_A1E7C30E-7E6B-4BED-AF26-961B3004F73A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Gyan,

Thanks for the = review. I will collect the results of all reviews and comment on those = later. I need to note that the reviewed document is = draft-ietf-idr-rfc5575bis-20 not rmcat-wireless-tests ;-) :

On = 07.04.2020, at 23:43, Gyan Mishra via Datatracker <noreply@ietf.org> = wrote:

Document: = draft-ietf-rmcat-wireless-tests-08
Reviewer: Gyan Mishra
Review Date: 2020-04-7
IETF LC End Date: 2020-04-8
IESG Telechat date: Not scheduled for = a telechat

Thanks,

Christoph

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



= --Apple-Mail=_A1E7C30E-7E6B-4BED-AF26-961B3004F73A-- From nobody Wed Apr 8 02:06:19 2020 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 4DB343A0EB6; Wed, 8 Apr 2020 02:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hiBoVs12d0Ts; Wed, 8 Apr 2020 02:06:12 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BB63A0EB5; Wed, 8 Apr 2020 02:06:12 -0700 (PDT) Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D56456173F1E76C9A11F; Wed, 8 Apr 2020 10:06:06 +0100 (IST) Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 8 Apr 2020 10:06:06 +0100 Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Wed, 8 Apr 2020 10:06:06 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.59]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0487.000; Wed, 8 Apr 2020 17:05:43 +0800 From: "Chengli (Cheng Li)" To: "Ketan Talaulikar (ketant)" , "Susan Hares" , 'IDR List' CC: SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aA= Date: Wed, 8 Apr 2020 09:05:43 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029AC713dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 09:06:14 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB029AC713dggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, Many thanks for your comments, and sorry for my delay, please see my reply = inline. Thanks, Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (keta= nt) Sent: Friday, April 3, 2020 4:18 PM To: Susan Hares ; 'IDR List' Cc: SPRING WG Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hello, I have a few questions for the authors of this draft and some discussion po= ints for the WG. 1) What is precisely the definition of this "path MTU" for an SR Polic= y? I am guessing that it includes all the labels/SIDs that are used for the= SR path? [Cheng] Yes, The Path MTU describes the largest size of the packet, includi= ng the overhead of Labels/SIDs/IPv6 header/SRH and others. When encapsulati= ng a packet, the length of the payload(inner IP packet or something else) s= hould be less than the PMTU minus the overhead of SID List/SRH/ FRR overhea= d and Binding SID overhead, but it is a implementation choice. 2) While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path= MTU" for RSVP-TE LSPs, it does describe the procedures for the same for ha= ndling IP packets/payloads on the headend. It does not cover the scenarios = where the incoming packets may be themselves labelled. [Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rf= c3209#section-2.6, but I think it covers the scenarios where the incoming p= ackets may be themselves labelled. I may be wrong. " The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined. Using the terminology defined in [5], an LSR MUST execute the following algorithm: 1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node. " 3) Shouldn't the concept of "path MTU" for SR Policies and its' applic= ability and operations be first defined in a (Spring WG?) document before w= e introduce its signalling aspects in protocols like BGP? Note that such a = document would bring in requirements and guidelines for how the value is go= ing to be computed and it's usage for different steering mechanisms over SR= Policies. [Cheng] This is a really small but useful and straight forward extensions, = it might not need to write a draft to describe the requirement instead of a= dding text in the current SR policy architecture draft or it current docume= nt. 4) Finally, specific to the proposed encoding here, would this "path M= TU" not be more suitable on the CP level since each SL may have different s= ize label stack and different paths and one does not know which SL would be= picked for a particular flow? So may be the lowest value computed for all = SLs is what gets applied to the packets at the CP (i.e. SR Policy) level? [Cheng] You are correct. The PMTU is defined for SID List. When we talk abo= ut Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID li= sts. But do we need this value? If we need, then the node can compute it ba= sed on PMTUs. Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 30 March 2020 18:06 To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_C7C2E1C43D652C4E9E49FE7517C236CB029AC713dggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

 

Many thanks for your c= omments, and sorry for my delay, please see my reply inline.

 

Thanks,

Cheng

 

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org= >
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hello,

 

I have a few questions for the authors of this draft and some discuss= ion points for the WG.

 

1)      What is precisely the definition of this “path MTU̶= 1; for an SR Policy? I am guessing that it includes all the labels/SIDs tha= t are used for the SR path?

[Cheng] Yes, The Path MTU describes the largest size of the packet, = including the overhead of Labels/SIDs/IPv6 header/SRH and others. When enca= psulating a packet, the length of the payload(inner IP packet or something else) should be less than the PMTU mi= nus the overhead of SID List/SRH/ FRR overhead and Binding SID overhead, bu= t it is a implementation choice.

 

2)      While https://tools.ietf.org/html/rfc3209#section-2.6 defines “path MTU” for RSVP-TE LSPs, it does = describe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where = the incoming packets may be themselves labelled.

[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the scenarios where the i= ncoming packets may be themselves labelled. I may be wrong.

 

   “

   The following algorithm applies t= o all unlabeled IP datagrams and to

   any labeled packets which the nod= e knows to be IP datagrams, to which

   labels need to be added before fo= rwarding.  For labeled packets the

   bottom of stack is found, the IP = header examined.

 

   Using the terminology defined=
 in [5], an LSR MUST execute the<=
/span>
   following algorithm:
 
   1. Let N be the number of byt=
es in the label stack (i.e, 4 times the
      number of l=
abel stack entries) including labels to be added by
      this node.<=
o:p>

       “

 

3)      Shouldn’t the con= cept of “path MTU” for SR Policies and its’ applicability= and operations be first defined in a (Spring WG?) document before we intro= duce its signalling aspects in protocols like BGP? Note that such a document would bring in requirements and guidelines for how the val= ue is going to be computed and it’s usage for different steering mech= anisms over SR Policies.

[Cheng] This is a really small but useful and straight forward exten= sions, it might not need to write a draft to describe the requirement inste= ad of adding text in the current SR policy architecture draft or it current document.  

 

 

 

4)      Finally, specific to th= e proposed encoding here, would this “path MTU” not be more sui= table on the CP level since each SL may have different size label stack and= different paths and one does not know which SL would be picked for a particular flow? So may be the lowest value computed= for all SLs is what gets applied to the packets at the CP (i.e. SR Policy)= level?

[Cheng] You are correct. The PMTU is defined for SID List. When we t= alk about Path MTU for SR policy, it CAN be the lowest value of the PMTU of= SID lists. But do we need this value? If we need, then the node can compute it based on PMTUs.=

 

 

 

 

Thanks,

Ketan

 

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoption call for draft-li-i= dr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org/doc/draft-li-idr-sr-= policy-path-mtu/

 

This draft distributes path maximum transmission uni= t for the

SR policy via BGP. 

 

Any discussion regarding on whether one desires

SR Policy should be clearly distinguished from the <= o:p>

Technical discussions on the mechanisms to pass SR p= olicy MTU.

 

The questions for the people to discuss on this draf= t are:

 

1) Is there a need for this mechanism in networks us= ing

        MPLS= -SR or SR-V6 and SR policy?

 

2) Are there any error handling issues besides what = is being

     Taken care of in RFC77= 52bis-03.txt

 

3) Do you think this draft is ready to be adopted? <= o:p>

     In this category, plea= se list any concerns you have

     regarding adoption.  T= his category can include

     general concerns about= BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  =  

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_C7C2E1C43D652C4E9E49FE7517C236CB029AC713dggeml529mbxchi_-- From nobody Wed Apr 8 04:37:34 2020 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 A71043A010D; Wed, 8 Apr 2020 04:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=Oy6T33tw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PWWVnKbY 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 12Eaff_0RRhN; Wed, 8 Apr 2020 04:37:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93193A0101; Wed, 8 Apr 2020 04:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31077; q=dns/txt; s=iport; t=1586345849; x=1587555449; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C4hUd5QJPkzHcvPDivkbgDOKuFlVoSieXOTrYo09TLs=; b=Oy6T33twg7BzsSM/HRA4n2Orgdtw8tVpLiEDg2CavqSRH6PemoF4Ql4n orqUZxv3VNKW4j5ogOHJwEhN9GvzgCt8hrag9r5mg4+G7+z9OL3eEMsyv bqBu2dK0+8nryGIyDVtnzFvCbDdEREIse5TBR4bnbgA1ebj6bfscoE6Kx A=; IronPort-PHdr: =?us-ascii?q?9a23=3AFGQx4xIHbAfC7OlbvtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCtKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXE72MPfscwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAAALt41e/4oNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagMBAQELAYEkLyQsBWxYIAQLKgqHVwOKaoJfgQGXH4F?= =?us-ascii?q?CgRADVAoBAQEMAQEjCgIEAQGERAKCByQ3Bg4CAwEBCwEBBQEBAQIBBQRthVY?= =?us-ascii?q?MhXABAQEBAxILEBMBATcBDwIBCBEBAwEBIQECBAcyFAMGCAEBBAENBQgagwW?= =?us-ascii?q?Bfk0DLgEOpVgCgTmIYoIngn8BAQWBQ0GDQhiCDQMGgTgBhSINhwMagUE/gRA?= =?us-ascii?q?BQ4IYNT6CZwEBAgEBgSwBEgEjJAcJgw6CLI4ADg2Id4o8j2YKgj2HBHGPXYJ?= =?us-ascii?q?OiDqPEIFwhF2KX4kokwMCBAIEBQIOAQEFgWgjZ3BwFTuCaVAYDZEiCQMXFYM?= =?us-ascii?q?7hRSFQXQCgSeNGQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,358,1580774400"; d="scan'208,217";a="736398898" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 11:37:19 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 038BbJ6E028027 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 11:37:19 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 06:37:19 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 07:37:17 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 07:37:17 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cr1dbfV1B+XXSv0W7T1kj8YZvRZgNepU5DcN7D3Te5+htPzqSmvWmjnw+2XEzYF2Nf0DNejsVKR/PtAD4bIv94uc2UTg4vYvy/NCQPHLtvPCNfFKYH6FCCgfVv1NDMKD+5EsPWj3PiE4jqFiXCN2+MxX6RjjRiKp4sMgyIg9pc+NQpBgLmeFUDAIGtUCBhoOnXHtLt7yBJAUko3q+f3UiiwBVS37IXmcL2K0ItOLOIzErcH03vKGbmPrTonngUZMNH2jK/NP/qjSFbukgNE3YHg/pBcLULRJYR/RtNa120AA8dvnHKDiCD3QD8RSPMqtwmhM5QpOYuLijct8socMQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ywZobnxgLUCQjGA8zomZm7Y9VXJbbXtyL04BmqsXB/8=; b=BXJYmDvO2TyhdVWcG554581udU4cz2ip7b9gjXI90c1LNbyMplb0XuqrluVm7hBUmhfTfMq2SdIfdl3E7BJzDgvfINvb7v5BaAlBHFf/Rtd42dDOIKVywD6BPXYHZsiLOFV35iBPT+jA5LWnDwLbdgiUcMvkCOb/wJ4zxDehKbhEGud+W2STvxS93x8QyF2sOZxrS8yG+N7Afcqqxzt48mLs7FlxjFQMFDgjbuxqd6Qmog/RIfchtPL9ET45yUzJN+UJttE8AsCCcTTYe7AQl4JqnNyLHPeUlTMdZe3SlYTdzYqDHWuMnuuD0eZbqUbKWGbBe2XJ3QnvbskZ0HrxWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ywZobnxgLUCQjGA8zomZm7Y9VXJbbXtyL04BmqsXB/8=; b=PWWVnKbY60iF7n756UR0Z37R/6aBdgli3wWdwJbS9viwy+5yMa4EiFKp6hLMKxABOJpk9XTDrKmiRJWO/Sr07h+hewOegVp6YVcvuyIshGLo2coFY/lpS6qt4kSc8gSHpCazxvGZRB4VPZrjqjHHj1YQFx/VyaVk44pwFE1XQ+Y= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4602.namprd11.prod.outlook.com (2603:10b6:303:52::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr 2020 11:37:16 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::dc3d:f0de:21ec:cf87]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::dc3d:f0de:21ec:cf87%7]) with mapi id 15.20.2878.022; Wed, 8 Apr 2020 11:37:16 +0000 From: "Ketan Talaulikar (ketant)" To: "Chengli (Cheng Li)" , Susan Hares , "'IDR List'" CC: SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aAABGXt8A== Date: Wed, 8 Apr 2020 11:37:16 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [72.163.220.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 211cb429-64b9-4b37-e302-08d7dbb1309d x-ms-traffictypediagnostic: MW3PR11MB4602: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(66446008)(6506007)(9326002)(81156014)(76116006)(9686003)(55016002)(71200400001)(966005)(5660300002)(86362001)(66556008)(8936002)(52536014)(64756008)(8676002)(81166007)(66946007)(478600001)(66476007)(33656002)(186003)(2906002)(4326008)(26005)(110136005)(53546011)(316002)(7696005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iFvA47DK8iAnoftucrdzmtu8wJLiAi3mKzkV9vcwVBz61xce8/MgKqyqGXmahjuwvoYc5iw0mh9vdzHBGa9Rlr8cXy9YmILPEHkUKt9S5NvqTglUXY6HhI7eytx7+ghaLyUfkONRWxvg8sIh9EhI6rzTr+nwcBmMt83bkHUn2uYB7RCf4ajYeWyskP7bmf6kA2vMIzxgt/asJqMzMg/hj/LxgDAIfikJbMe6FI+9uts5bPksuCsMVUVtMr2tOi7OEmvwunkAhR7JOT3vHdInh/qrk1wBTE2Hq7Bu4jzlz2RxY/uGGFD4ziJXmzwt3NGlCmwnsV8urKoJVxD1C+gLm9H9y2FoEVGosLRQBMPQb7FntCfufJiMiLJKBGuzXA3LXxARfFy4W/hUdBf0iKdbS5GXp4x+XV6dJ2gS8iLntoUNbKOcXqQuvViRtPZh2r3HB2KhwdRC68ssj57C55aQoOfHBrIer52ArdH1VgVMdrX79HmBwPdFRopnVwcReImnWZ04K/smUxtUgTtsdWBqMQ== x-ms-exchange-antispam-messagedata: NCC+JAj/fOyrdMpXihcKAQHhAvRwqhBemlghYtCnxA7E1R1Dp7qcElWmcLC94obNoFU9Qz8oegqzmVsUJhqkHo4SJqZCfz0g4wdS1QeVCle9teVt23fIOqLkp/cEBLWJFn8c1OffggEcfbBmZaEyig== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45707D22CD2D9DF041851846C1C00MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 211cb429-64b9-4b37-e302-08d7dbb1309d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 11:37:16.5481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ewEb+ckmChmKVj4egx/mP4IiwalANJcJP1yhlyobsCUSfXoWtx9kTy0Ij5FDUjc/W47fanV4F7eNHpucGnX8CA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4602 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 11:37:33 -0000 --_000_MW3PR11MB45707D22CD2D9DF041851846C1C00MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Cheng, Please check inline below. From: Chengli (Cheng Li) Sent: 08 April 2020 14:36 To: Ketan Talaulikar (ketant) ; Susan Hares ; 'IDR List' Cc: SPRING WG Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Many thanks for your comments, and sorry for my delay, please see my reply = inline. Thanks, Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (keta= nt) Sent: Friday, April 3, 2020 4:18 PM To: Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hello, I have a few questions for the authors of this draft and some discussion po= ints for the WG. 1. What is precisely the definition of this "path MTU" for an SR Policy?= I am guessing that it includes all the labels/SIDs that are used for the S= R path? [Cheng] Yes, The Path MTU describes the largest size of the packet, includi= ng the overhead of Labels/SIDs/IPv6 header/SRH and others. [KT] Here, "path" is the SR path and the SR path is specified by a label st= ack. So the "payload" over the SR path does not include the SID List use to= construct the path itself, right? Or do you mean that the "path MTU" is th= e lowest MTU value of all paths over which packet steered over the SR Polic= y may go over? When encapsulating a packet, the length of the payload(inner IP packet or s= omething else) should be less than the PMTU minus the overhead of SID List/= SRH/ FRR overhead and Binding SID overhead, but it is a implementation choi= ce. [KT] Here a "path MTU" object is being defined. It is to be calculated by a= component X and communicated over BGP protocol to a node/component Y. IMHO= we cannot leave such things to implementation aspects - this attribute sho= uld be clearly specified so that both X and Y have the same understanding o= f what it means and how it is to be used. 1. While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path M= TU" for RSVP-TE LSPs, it does describe the procedures for the same for hand= ling IP packets/payloads on the headend. It does not cover the scenarios wh= ere the incoming packets may be themselves labelled. [Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rf= c3209#section-2.6, but I think it covers the scenarios where the incoming p= ackets may be themselves labelled. I may be wrong. " The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined. Using the terminology defined in [5], an LSR MUST execute the following algorithm: 1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node. " [KT] May be I misunderstood your proposal then. It seems that the authors w= ant the headend to perform the behavior described in RFC3209 Sec 2.6 for SR= Policies, then please specify the same with normative language. How would = this work for SRv6? This way the WG can review and understand what the prop= osal is. Note that we can also have a label stack introduced during transit= due to something like TI-LFA. 1. Shouldn't the concept of "path MTU" for SR Policies and its' applicab= ility and operations be first defined in a (Spring WG?) document before we = introduce its signalling aspects in protocols like BGP? Note that such a do= cument would bring in requirements and guidelines for how the value is goin= g to be computed and it's usage for different steering mechanisms over SR P= olicies. [Cheng] This is a really small but useful and straight forward extensions, = it might not need to write a draft to describe the requirement instead of a= dding text in the current SR policy architecture draft or it current docume= nt. [KT] It is not about the size of the document, but the clear and normative = specification of behaviors being introduced - both for the node calculating= this value and for the headend for how it is supposed to handle this. My w= orry is that there is devil in the details here and operational aspects on = how exactly this will work. I am not against this work. I only ask the auth= ors to document the behaviors associated with this in a Spring WG document = so the WG can review all that is entailed by the proposal. It is somewhat s= imilar to how Path Segment was introduced - I would suggest to start with a= fresh draft using much of the content from this BGP document plus other cl= arifications as discussed in this email thread. Once the "Path MTU" for SR Policy is properly specified, the BGP SRTE encod= ing is actually trivial by simply referring to its base draft. The same may= be also specified via PCEP or a Yang model. 1. Finally, specific to the proposed encoding here, would this "path MTU= " not be more suitable on the CP level since each SL may have different siz= e label stack and different paths and one does not know which SL would be p= icked for a particular flow? So may be the lowest value computed for all SL= s is what gets applied to the packets at the CP (i.e. SR Policy) level? [Cheng] You are correct. The PMTU is defined for SID List. When we talk abo= ut Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID li= sts. But do we need this value? If we need, then the node can compute it ba= sed on PMTUs. [KT] Sure. I think these are details and we can leave them aside for now. M= y main concerns are the previous comments. Thanks, Ketan Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 30 March 2020 18:06 To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_MW3PR11MB45707D22CD2D9DF041851846C1C00MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Cheng,=

&nbs= p;

Please ch= eck inline below.

&nbs= p;

From: Chengli (Cheng Li) <chengli13@huawei.com>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares = <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Keta= n,

&n= bsp;

Many th= anks for your comments, and sorry for my delay, please see my reply inline.=

&n= bsp;

Thanks,=

Cheng

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.c= om>; 'IDR List' <idr@ietf.org= >
Cc: SPRING WG <spring@ietf.org= >
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hello,

&nbs= p;

I have a = few questions for the authors of this draft and some discussion points for = the WG.

&nbs= p;

  1. What is precisely the definition of this “p= ath MTU” for an SR Policy? I am guessing that it includes all the lab= els/SIDs that are used for the SR path?

[Cheng] Yes, The Path MTU describes the largest size = of the packet, including the overhead of Labels/SIDs/IPv6 header/SRH and ot= hers.

[KT] Here, “path= 221; is the SR path and the SR path is specified by a label stack. So the &= #8220;payload” over the SR path does not include the SID List use to = construct the path itself, right? Or do you mean that the “path MTU” is the lowest MTU value of all paths over which packet steered = over the SR Policy may go over?

 <= /i>

When encapsulating a packet, the length of the payloa= d(inner IP packet or something else) should be less than the PMTU minus the= overhead of SID List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation choice.

[KT= ] Here a “path MTU” object is being defined. It is to be calcul= ated by a component X and communicated over BGP protocol to a node/componen= t Y. IMHO we cannot leave such things to implementation aspects – this attribute should be clearly specified so that both X = and Y have the same understanding of what it means and how it is to be used= .

 

  1. While https://tools.ietf.org/html/rfc3209#secti= on-2.6 defines “path MTU” for RSVP-TE LSPs, i= t does describe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where = the incoming packets may be themselves labelled.

[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#secti= on-2.6, but I think it covers the = scenarios where the incoming packets may be themselves labelled. I may be wrong.

 

   “=

   The following algo= rithm applies to all unlabeled IP datagrams and to

   any labeled packet= s which the node knows to be IP datagrams, to which

   labels need to be = added before forwarding.  For labeled packets the

   bottom of stack is= found, the IP header examined.

 

   Using the term=
inology defined in [5], an LSR MUST execute =
the
   following algo=
rithm:
 

   1. Let N be th=
e number of bytes in the label stack (i.e, 4 times the

    &nb=
sp; number of label stack entries) including labels to be added by


    &nb=
sp; this node.


     &=
nbsp; “


[KT] May be I misundersto=
od your proposal then. It seems that the authors want the headend to perfor=
m the behavior described in RFC3209 Sec 2.6 for SR Policies, then please sp=
ecify the same with normative language.
 How would this work for SRv6? This way the WG can review and understand wh=
at the proposal is. Note that we can also have a label stack introduced dur=
ing transit due to something like TI-LFA.


&nbs=
p;


    

  1. Shouldn’t t=
he concept of “path MTU” for SR Policies and its’ applica=
bility and operations be first defined in a (Spring WG?) document before we=
 introduce its signalling aspects in protocols like BGP? Note
 that such a document would bring in requirements and guidelines for how th=
e value is going to be computed and it’s usage for different steering=
 mechanisms over SR Policies.


[Cheng] This is a really small but useful and straigh=
t forward extensions, it might not need to write a draft to describe the re=
quirement instead of adding text in the
 current SR policy architecture draft or it current document.  


[KT] It is not about the =
size of the document, but the clear and normative specification of behavior=
s being introduced – both for the node calculating this value and for=
 the headend for how it is supposed to handle
 this. My worry is that there is devil in the details here and operational =
aspects on how exactly this will work. I am not against this work. I only a=
sk the authors to document the behaviors associated with this in a Spring W=
G document so the WG can review
 all that is entailed by the proposal. It is somewhat similar to how Path S=
egment was introduced – I would suggest to start with a fresh draft u=
sing much of the content from this BGP document plus other clarifications a=
s discussed in this email thread.


 <=
/i>


Once the “Path MTU&=
#8221; for SR Policy is properly specified, the BGP SRTE encoding is actual=
ly trivial by simply referring to its base draft. The same may be also spec=
ified via PCEP or a Yang model.


 


 


    

  1. Finally, specific=
 to the proposed encoding here, would this “path MTU” not be mo=
re suitable on the CP level since each SL may have different size label sta=
ck and different paths and one does not know which
 SL would be picked for a particular flow? So may be the lowest value compu=
ted for all SLs is what gets applied to the packets at the CP (i.e. SR Poli=
cy) level?


[Cheng] You are correct. The PMTU is defined for SID =
List. When we talk about Path MTU for SR policy, it CAN be the lowest value=
 of the PMTU of SID lists. But do we need
 this value? If we need, then the node can compute it based on PMTUs.<=
/o:p>


[KT] Sure. I think these =
are details and we can leave them aside for now. My main concerns are the p=
revious comments.


 <=
/i>


Thanks,


Ketan=



&nbs=
p;


Thanks,


Ketan


&n=
bsp;


&nbs=
p;






From: Idr <idr-bounces@iet=
f.org>
On Behalf Of Susan Hares

Sent: 30 March 2020 18:06

To: 'IDR List' <idr@ietf.org&=
gt;

Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt =
- 2 Week WG adoption call (3/30 - 4/13)






 


This begins a 2 week WG adoptio=
n call for draft-li-idr-sr-policy-path-mtu-03.txt



 


You can view this draft at: 


https://datatracker.ietf.org=
/doc/draft-li-idr-sr-policy-path-mtu/


 


This draft distributes path max=
imum transmission unit for the



SR policy via BGP.  <=
/o:p>


 


Any discussion regarding on whe=
ther one desires



SR Policy should be clearly dis=
tinguished from the



Technical discussions on the me=
chanisms to pass SR policy MTU.



 


The questions for the people to=
 discuss on this draft are:



 


1) Is there a need for this mec=
hanism in networks using



     &=
nbsp;  MPLS-SR or SR-V6 and SR policy? 



 


2) Are there any error handling=
 issues besides what is being



     T=
aken care of in RFC7752bis-03.txt


 


3) Do you think this draft is r=
eady to be adopted?



     I=
n this category, please list any concerns you have


     regard=
ing adoption.  This category can include



     g=
eneral concerns about BGP-LS, MPLS-SR,



    SR-V6, =
and SR-Policy.   


 


Cheers, Sue Hares  


 


 


 


 


 
--_000_MW3PR11MB45707D22CD2D9DF041851846C1C00MW3PR11MB4570namp_-- From nobody Wed Apr 8 05:19:32 2020 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 8E88B3A08A3 for ; Wed, 8 Apr 2020 05:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.246 X-Spam-Level: *** X-Spam-Status: No, score=3.246 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 Jq0pcOXitdgX for ; Wed, 8 Apr 2020 05:19:30 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 EB02D3A08B6 for ; Wed, 8 Apr 2020 05:19:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Wed, 8 Apr 2020 08:19:26 -0400 Message-ID: <007601d60d9f$f26b5590$d74200b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01D60D7E.6B5D10F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYNnyiVr2ZUmibuT5KsNcvNg3xGuw== Content-Language: en-us X-Antivirus: AVG (VPS 200407-0, 04/07/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-flow-spec-v6-10 - WG LC [4/8 to 4/22] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 12:19:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01D60D7E.6B5D10F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings: I'm going to again restart the WG last call on draft-ietf-idr-flow-spec-v6-10.txt. The WG LC call is from [4/8 to 4/22], and the draft can be accessed at: https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/ The IESG requested that when a revision for RFC5575 is sent in that it be accompanied by an IPv6 capability specification. In the WG chairs mind, the draft-ietf-idr-flow-spec-v6-10.txt fulfills this requirement. However, this WG LC requests that you consider: 1) Is this draft ready to be published? 2) Do we know of any of implementations? Drafts in IDR can pass WG LC and await implementations. Cheers, Sue ------=_NextPart_000_0077_01D60D7E.6B5D10F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings: =

 

I’m going to again restart the WG last call on = draft-ietf-idr-flow-spec-v6-10.txt. 

The WG LC call is from [4/8 to 4/22], and the draft = can be accessed at:

 

ht= tps://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/

 

 

The IESG = requested that when a revision for RFC5575 is sent in that it be = accompanied by an IPv6 capability specification.

 

In the WG = chairs mind, the draft-ietf-idr-flow-spec-v6-10.txt fulfills this = requirement.

 

However, this WG LC requests that you consider: =

 

1) Is this draft ready to be published? =

2) Do we know of any of = implementations?

 

Drafts in = IDR can pass WG LC and await implementations. 

 

Cheers,  Sue

------=_NextPart_000_0077_01D60D7E.6B5D10F0-- From nobody Wed Apr 8 05:37:29 2020 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 940D43A097B for ; Wed, 8 Apr 2020 05:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.347 X-Spam-Level: * X-Spam-Status: No, score=1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 d_VVp4xxlgmr for ; Wed, 8 Apr 2020 05:37:26 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 B531F3A0973 for ; Wed, 8 Apr 2020 05:37:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Wed, 8 Apr 2020 08:37:22 -0400 Message-ID: <008901d60da2$74031370$5c093a50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01D60D80.ECF3E470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYNokgRyeOIrfLpRmOFOKAsBaX81g== Content-Language: en-us X-Antivirus: AVG (VPS 200407-0, 04/07/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] status - incremental 4/8/2020 - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 12:37:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008A_01D60D80.ECF3E470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: A little status to read with your coffee this morning. We have an interim at 13:00 UTC (9:00 EDT, 6:00 PDT, 21:00 Bejing time) Please let me know if I've missed any updates. Cheers, Sue --------- At IESG in IETF LC 1) draft-ietf-idr-rfc5575bis-19.txt - Shepherd: John Scudder Status: IETF LC ended, IESG telechat: 4/15 IESG Publication request: 7/9/2019 2 AD Reviews [8/2-9/10/2019, [1/17-1/23/2020] 2) draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt [Shepherd: Susan Hares] Status: 3rd round of AD revisions IESG Publication requested: 10/15/2019 IETF WG LC: 6 days -------------- AD review - authors need to respond 1) draft-ietf-idr-tunnel-encaps-14 - sent to IESG [Waiting 47 days] 2) draft-ietf-idr-capabilities-registry-change-05.txt [Waiting 57 days] ------------ WG past WG LC - stuck waiting for implementation reports on wiki [reported to have 2 implementations, but no details on wiki] 1) draft-ietf-idr-ext-opt-param 2) draft-idr-eag-distribution-09.txt --------- Drafts stuck post WG LC - waiting for minor edits 1) draft-ietf-idr-rfc8203bis.05.txt - ---- Flow specification drafts in WG LC 1) Draft-ietf-idr-flow-spec-v6-10.txt Status: restarted [4/8 to 4/22] Status: IESG desires, but is it ready? Needed: implementation reports 2) draft-ietf-idr-bgp-flowspec-oid-11 Status: 3/13/ to 4/13 Status: light response, please comment Authors: Please fill out implementation report ----------- WG Adoption calls: 1) Draft-hujun-idr-bgp-ipsec WG adoption: 3/30-4/13 Shepherd: Susan Hares Comment: only 1 response, heading toward "no consensus" 2) draft-hujun-idr-bgp-ipsec-transport-mode WG Adoption: 3/30 - 4/13 Shepherd: Susan Hares Comment: only 1 response, heading toward "no consensus" 3) draft-li-idr-sr-policy-path-mtu-03.txt WG adoption: 3/30 - 4/13 Shepherd: Susan Hares Comment: Positive response: Heading toward WG Adoption Request for input: ---------------------- draft-scharf-tcpm-yang-tcp-04 Proposed WG LC drafts for flow-specification that were on hold: ------------------------------------------- [Authors should contact chairs] 1) draft-ietf-idr-flowspec-interfaceset-05 - WG notes indicated this might go ahead without flow-specification v2 2) draft-ietf-idr-flowspec-path-redirect-10 - WG discussion needs to occur on whether flowspecification Proposed WG LCs (3/30 and 4/8) ---------------- 1) draft-ietf-idr-bgp-open-policy-08 - on hold pending revision -09 2) draft-ietf-idr-flowspec-l2vpn-13 - in slides for 4/8 Proposed Adoption calls ----------------------- draft-cl-idr-bgp-ext-com-registry-udpate-00.txt ------=_NextPart_000_008A_01D60D80.ECF3E470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG:

 

A little status to read = with your coffee this morning.   We have an interim at 13:00 = UTC (9:00 EDT,  6:00 PDT, 21:00 Bejing time) =

 

Please let me know if = I’ve missed any updates.

 

Cheers, Sue =

 

---------

At IESG in IETF LC =

1) draft-ietf-idr-rfc5575bis-19.txt – =

    Shepherd: John Scudder =

    Status:  IETF LC ended, IESG telechat: = 4/15

    IESG Publication request: 7/9/2019 =

   2  AD Reviews [8/2-9/10/2019, = [1/17-1/23/2020]

   

2) = draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt

 = ;    [Shepherd: Susan Hares]

 = ;    Status:  3rd round of AD revisions =  

 = ;    IESG Publication requested: =  10/15/2019

   &nbs= p; IETF WG LC:  6 = days  

 

--------------

AD = review – authors need to respond

1) <= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-idr-tunnel-encaps-14 - sent to IESG =

[Waiting 47 days]

=  

2) = draft-ietf-idr-capabilities-registry-change-05.txt =

[Waiting 57 days] =

------------

WG past WG LC – stuck  waiting for = implementation reports on wiki

[reported to have 2 implementations, but no details on = wiki]

 

1) draft-ietf-idr-ext-opt-param

2) draft-idr-eag-distribution-09.txt

---------

Drafts = stuck post WG LC – waiting for minor edits

1) draft-ietf-idr-rfc8203bis.05.txt  -

----

Flow specification drafts in WG LC

 

1) Draft= -ietf-idr-flow-spec-v6-10.txt

 = ;  Status: restarted [4/8 to 4/22]

 = ;  Status: IESG desires, but is it ready?

 = ;  Needed:  implementation reports =

=  

2) = draft-ietf-idr-bgp-flowspec-oid-11

    Status:  3/13/ to 4/13 =

    Status: = light response, please comment

    Authors:  Please fill out = implementation report

 

-----------

WG Adoption calls:

 

 = ;  1) Draft-hujun-idr-bgp-ipsec

 = ;      WG adoption:  = 3/30-4/13

 = ;       Shepherd: Susan Hares =

 = ;       Comment: only 1 response, = heading toward “no consensus”

=  

2) = draft-hujun-idr-bgp-ipsec-transport-mode

 = ;    WG Adoption: 3/30 – = 4/13

 = ;     Shepherd: Susan Hares

 = ;    Comment: only 1 response, heading toward = “no consensus”

=  

3) = draft-li-idr-sr-policy-path-mtu-03.txt

 = ;   WG adoption: 3/30 – 4/13 =

 = ;    Shepherd: Susan Hares

 = ;   Comment: Positive response: Heading toward WG = Adoption

=  

Reque= st for input:

-----= -----------------

draft= -scharf-tcpm-yang-tcp-04

=  

Propo= sed WG LC drafts for flow-specification that were on hold: =

-----= --------------------------------------

[Auth= ors should contact chairs]

=  

1) =  draft-ietf-idr-flowspec-interfaceset-05 – =

WG = notes indicated this might go ahead without flow-specification v2 =

=  

2) = draft-ietf-idr-flowspec-path-redirect-10 – =

WG = discussion needs to occur on whether flowspecification =

=  

=  

Propo= sed WG LCs (3/30 and 4/8)

-----= -----------

1) = draft-ietf-idr-bgp-open-policy-08 – on hold pending  revision = -09

2) =  draft-ietf-idr-flowspec-l2vpn-13 – in slides for = 4/8

=  

=  

Propo= sed Adoption calls  

-----= ------------------

draft= -cl-idr-bgp-ext-com-registry-udpate-00.txt

=  

=

=  

 

 

 

------=_NextPart_000_008A_01D60D80.ECF3E470-- From nobody Wed Apr 8 05:50:12 2020 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 675C93A09CE for ; Wed, 8 Apr 2020 05:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=xepzojEZ; dkim=pass (1024-bit key) header.d=juniper.net header.b=Ot/jF7uG 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 Tdg9xCZh0wRb for ; Wed, 8 Apr 2020 05:50:08 -0700 (PDT) Received: from mx0b-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 C776D3A09C7 for ; Wed, 8 Apr 2020 05:50:07 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 038ChS3o018312; Wed, 8 Apr 2020 05:50:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=BcLmowYTH7D9eki/pVGa2rRK0L4bLgX1/kRNUYZ9+yE=; b=xepzojEZWaov8tFrgHthqGNiRlHYSrfqtdDiK4lPXGzLQtYTQ1ERtE3PQsIw340R+WQa 302ADKM0+FVLXizvFjc4+2FxG2tgQPiqFjcDIIdrnJ56JOkVzI41xSvI0p00qMtNBeH9 f211Jt5dLAZ2PtXs9yWfY7tlb6EIBYBiTPfl4wUixr821ggSVtmuhCEpWccEy8T/iG/I qClxHu3gLBWPimxiSJrXEOzAq7E44YK+3abW8Vmth5/6/4BVAEi9IGn9lPtm74tAV3Mk KAcCtjPcwtRVRWSDEy0QsF6QN582S+Dmt9/0Y9oVCcB5m4uECBPSLtY1NkDfljzBp+Yd Ag== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) by mx0a-00273201.pphosted.com with ESMTP id 3091rh97yu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Apr 2020 05:50:07 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=USeVyvHOtWFDk5cGuX34a5JvODXaXIBJpE+srA6ssl5WEQD/mQLQ3rkWqTXEgzPlA3XY6Td37vEHedF1CGgc0TvoSPoyAqtLWHDKeqR2NCXpZ/jgNcDkT3mSSxvLn9OMClsjDCX16Mw5P25cFJttXf1oZCfZsMxpKE3/D6uuiSJVh3oeXx2Iy+HpPCZVdxtrT+IbBdMZs2pQ4STRkfGefyyplSqNsfQeoSMnrto55WY0OBrrXuSqmq+1tinIwDwVvGTLUS5P8slPn35gqgI3cb1XQ9jOS/o2+f5utfl7rlmjKYppNa0YsrZBEWs9j2h7/JU4Hg0SB1jJl3W9RrPo+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BcLmowYTH7D9eki/pVGa2rRK0L4bLgX1/kRNUYZ9+yE=; b=g/Ikhv7xrBgyYmBJnuLi9SG38jImM7oGT64AEf2AIExnLd3K3Bm9fOsdphWdikRcx277kh0X39EqspSa+Kkx21wKLwrRJQ8xGQbs0dZtFXMufOP0wTdSqSQqQMN/AadEiwZ4rDAseCcFb+iHEm6IgNrna1WZuBGPc6CKfag9JAuoCnhQrxlcGDaXDTJ6tJ64CpI9e5y0MYDsIGBPzTcyY8i9/HLCVz9ixwzAcHIXdjqHqrdNpu4XfHoKPGRccW4ZLk+vj+F77nUfQmkrNhb+gjwGq5XvAwWjiY5kusZOkHiKFRKp6JR/YO3BUQNOJYZcbQNxrq0Mr7AQUKtUnqMCSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BcLmowYTH7D9eki/pVGa2rRK0L4bLgX1/kRNUYZ9+yE=; b=Ot/jF7uGgoEaQBZ6XX+DwTn46XW++W73RCNc1657laD79dNl/fgRgU1t7rYiR3yVc3+4RauvGYgdzK5NkITTR4Pqk4D5Fit3HVRc9LLcPo+aMMb34uR8M3MfyF0/R6aXRRShAB0py0WuhVintuxHaN44XLX8DvHd23zzxNCzkPc= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB4705.namprd05.prod.outlook.com (2603:10b6:208:5e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Wed, 8 Apr 2020 12:50:04 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2900.015; Wed, 8 Apr 2020 12:50:03 +0000 From: John Scudder To: Hares Susan CC: "idr@ietf.org" Thread-Topic: [Idr] IDR second session - 4/8 13:00-15:00 UTC (9-11am EDT) Thread-Index: AdYM+YszaQKpvMuSQFO9dmXNJ7zgjgAqq1uA Date: Wed, 8 Apr 2020 12:50:03 +0000 Message-ID: <1C4FE3CA-DDF4-4736-9CD1-DE2296E73383@juniper.net> References: <01aa01d60cfb$09ef2340$1dcd69c0$@ndzh.com> In-Reply-To: <01aa01d60cfb$09ef2340$1dcd69c0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-originating-ip: [2600:1700:37a0:3ca0:71eb:2155:fd58:729e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 73379f51-b8ca-4077-e38d-08d7dbbb5bb2 x-ms-traffictypediagnostic: BL0PR05MB4705: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(396003)(346002)(136003)(376002)(39860400002)(366004)(6486002)(316002)(33656002)(71200400001)(6916009)(91956017)(2906002)(66446008)(76116006)(4326008)(66946007)(86362001)(66556008)(64756008)(66476007)(966005)(5660300002)(8936002)(6506007)(186003)(81166007)(6512007)(478600001)(53546011)(2616005)(8676002)(36756003)(81156014); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /Dq3e4w+jtu8AyiRI1wfa93GE/8T4zSQ7rHWIBqIQfOJLQe39GbK5QHnKEZBtYFO0f8A2GP0y4VVBfoAQzGFH/uPv/232uMqRVoAI1e6mZdwmxzLHQZtlYid6wCXHKZCPr6xRTDVvbA9eKqqY5N1+3pGVfvVROZJazgmEwspuysAPPdBaYALFBizFxpOLpcTdDcIG2s1o6v6iZsHyKXET1ik7RezEupE+4Q9FAye03X86pnqC3x+S7W6mPtFpgRsJy/hg584v4rdIUnjxWHlDQPEOesAvoO7/AfSIMRpxuWSUip5K9IR41CWBxyMlN7GauYUUOA2bqsQvv8Lp3H3V0aIn7TzdpXeAaQNZAmZjA12QPKo2abOrdebaKODu1TRgfnMZcJmlnLUKsiMeJhic3Xtn1rFyXc56kCVO1g3DazfIknDcmUbPwPujm7WkArm4Ul9uZSOdWS/tFx9bLm+Z19Pvf+iu1rJz04FSZb1lKFF1QBIHBIyL3Kx8F9w4jxe0WAN3jcS9TPIw/AH2NfjEg== x-ms-exchange-antispam-messagedata: s7rIHJstPE8t4C/NA5OVWReQfeskcZhrDTq+h4aOTQpLNF8H5aOVLrnYqky/dW/TB04b/k2u6v3bTgYAB2WH9P8S4T53dRYRzsMoNYzKQXCpJDi3RHKZxOxP2VpkEwry7FobttUyF52GxQ8t0P5aCVRb5Q+9gF/gWnTrA/Z074c+LiOfIMKAdronx2tS/HlClYWoM3wFgNWCdQ6KoCo3Eg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1C4FE3CADDF447369CD1DE2296E73383junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 73379f51-b8ca-4077-e38d-08d7dbbb5bb2 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 12:50:03.8842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qAq8a+xS8cQToUffAIuXtC0rFhY7JsoV6YmF85qQiD09M3sU58/Jf590snC4fg5N X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4705 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-07_10:2020-04-07, 2020-04-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 lowpriorityscore=0 adultscore=0 clxscore=1015 malwarescore=0 priorityscore=1501 spamscore=0 mlxscore=0 impostorscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004080105 Archived-At: Subject: Re: [Idr] IDR second session - 4/8 13:00-15:00 UTC (9-11am EDT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 12:50:11 -0000 --_000_1C4FE3CADDF447369CD1DE2296E73383junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gY2FzZSBhbnlvbmUgbmVlZHMgdGhlIFdlYkV4IG1lZXRpbmcgbnVtYmVyLCBpdOKAmXMgNjQ3 IDk5OCA2MTQNCg0K4oCUSm9obg0KDQpPbiBBcHIgNywgMjAyMCwgYXQgMTI6MzggUE0sIFN1c2Fu IEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+IHdyb3RlOg0K DQoNCltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KDQpPdXIgc2Vj b25kIGludGVyaW0gaXMgb24gV2VkbmVzZGF5IDQvOC8yMDIwLg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLQ0KV2ViRXg6IGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vd2ViYXBwbmcvc2l0ZXMvaWV0Zi9t ZWV0aW5nL2Rvd25sb2FkLzVGRjREMzNCMjczQ0E5NTJFMDUzNjI4NEZDMEFDNzJFPGh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2lldGYud2ViZXguY29tL3dlYmFwcG5nL3NpdGVz L2lldGYvbWVldGluZy9kb3dubG9hZC81RkY0RDMzQjI3M0NBOTUyRTA1MzYyODRGQzBBQzcyRV9f OyEhTkV0NnlNYU8tZ2shVHc1dkp2Y0cxMUc5NldUSi1hMm9RemhfcDVxeFFGeWt5NXFRQmJ5dTFw alloZzBMZHlMY3YxWUc0Rk1CX1EkPg0KRXRoZXJwYWQgZm9yIG5vdGUtdGFraW5nOiBodHRwczov L2V0aGVycGFkLmlldGYub3JnOjkwMDkvcC9ub3Rlcy1pZXRmLWludGVyaW0tMjAyMC1pZHItMDI/ dXNlTW9ub3NwYWNlRm9udD10cnVlDQoNCg0KRXRoZXJwYWQgZm9yIHZpcnR1YWwgYmx1ZSBzaGVl dDpodHRwczovL2V0aGVycGFkLmlldGYub3JnOjkwMDkvcC9ub3Rlcy1pZXRmLTEwNy1pZHItMi1i bHVlc2hlZXQNCmphYmJlcjogIGlkckBqYWJiZXJ0LmlldGYub3JnPG1haWx0bzppZHJAamFiYmVy dC5pZXRmLm9yZz4NCg0KDQoxLkFkbWluaXN0cml2aWEgKyBTdGF0dXMgMTAgbWludXRlcw0KICBT dGF0dXM6IEZlZWRiYWNrIG9uIGludGVyaW1zDQoNCjIuIEJHUCBZQU5HIE1vZGVsIFN0YXR1cyBh bmQgSXNzdWVzDQpEcmFmdDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt aWRyLWJncC1tb2RlbC0wODxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1tb2RlbC0wOF9fOyEhTkV0NnlNYU8t Z2shVHc1dkp2Y0cxMUc5NldUSi1hMm9RemhfcDVxeFFGeWt5NXFRQmJ5dTFwalloZzBMZHlMY3Yx WlB4WmlRWnckPg0KDQpQcmVzZW50ZXI6IE1haGVzaCBKZXRoYW5hbmRhbmkNClRpbWUgcGVyaW9k OiAxMCBtaW51dGVzDQpDaGFpcuKAmXMgcXVlc3Rpb25zIGZvciBXRzoNCjEpIERvZXMgaXQgbWF0 dGVyIHRoYXQgdGhpcyBpcyBvbmx5IG1hY2hpbmUgZnJpZW5kbHk/DQoyKSBBcmUgd2UgcmVhZHkg Zm9yIFdHIExDIG9uIHRoaXMgZG9jdW1lbnQ/DQoNCjMuIFByZXNlbnRhdGlvbnMg4oCTIG5ldyBk cmFmdHMgb3Igc3RhdHVzIHVwZGF0ZXMNCjEpICAgICAgRmxvd3NwZWMgZm9yIEwyIGFuZCBUdW5u ZWxlZCBUcmFmZmljDQpEcmFmdDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtaWRyLWZsb3dzcGVjLWwydnBuLTEzPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2cG4tMTNf XzshIU5FdDZ5TWFPLWdrIVR3NXZKdmNHMTFHOTZXVEotYTJvUXpoX3A1cXhRRnlreTVxUUJieXUx cGpZaGcwTGR5TGN2MWFXVG5jLTBnJD4NCiAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLW52bzMtMDg8aHR0cHM6Ly91cmxkZWZlbnNlLmNv bS92My9fX2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1mbG93c3Bl Yy1udm8zLTA4X187ISFORXQ2eU1hTy1nayFUdzV2SnZjRzExRzk2V1RKLWEyb1F6aF9wNXF4UUZ5 a3k1cVFCYnl1MXBqWWhnMExkeUxjdjFhOXlHMXM4USQ+DQpQcmVzZW50ZXI6IERvbmFsZCBFYXN0 bGFrZQ0KVGltZSBwZXJpb2Q6IDIwIG1pbnV0ZXMNCg0KQ2hhaXLigJlzIHF1ZXN0aW9ucyBmb3Ig V0cvcHJlc2VudGVyczoNCjEpIEFyZSB0aGVyZSBpbXBsZW1lbnRhdGlvbnMgb2YgZHJhZnQtaWV0 Zi1pZHItZmxvd3NwZWMtbDJ2cG4tMTMudHh0Pw0KMikgQXJlIHdlIHJlYWR5IGZvciBXRyBMQw0K MykgSXMgdGhlIHJldmlzaW9uIGRyYWZ0LWlkci1mbG93c3BlYy1udjAzLTA4LnR4dCByZWFkeSBm b3IgZWFybHkgYWxsb2NhdGlvbj8NCg0KMikgICAgICBCR1AgV2VsbC1rbm93biBMYXJnZSBDb21t dW5pdGllcw0KRHJhZnQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZWl0ei1p ZHItd2tsYy0wMA0KUHJlc2VudGVyOiBKYWtvYiBIZWl0eg0KVGltZSBwZXJpb2Q6IDEwIG1pbnV0 ZXMNCg0KNCkgIEJHUCBjb21tdW5pdGllcyDigJMgUmVzZWFyY2ggaW50byBXb3Jtcw0KIFBhcGVy OiBodHRwczovL2FyY2hpdmUucHNnLmNvbS8xODExMDEuaW1jLWNvbW11bml0aWVzLnBkZjxodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9hcmNoaXZlLnBzZy5jb20vMTgxMTAxLmlt Yy1jb21tdW5pdGllcy5wZGZfXzshIU5FdDZ5TWFPLWdrIVR3NXZKdmNHMTFHOTZXVEotYTJvUXpo X3A1cXhRRnlreTVxUUJieXUxcGpZaGcwTGR5TGN2MWJmNnNCcHZRJD4NClByZXNlbnRlcjogIFJh bmR5IEJ1c2gNCg0KNCkgTGFyZ2UgRGlzY3Vzc2lvbiB0aW1lOiAxNSBtaW51dGVzDQoxKSBXaGF0 IGFyZSB0aGUgb3BlcmF0b3IgbmVlZHM/DQoyKSBXaGF0IGFib3V0IHRoZSBpc3N1ZXMgcmFpc2Vk IEJHUCByZXNlYXJjaGVyPw0KDQo1KSAgICAgIEJHUCBFeHRlbmRlZCBDb21tdW5pdHkgUmVnaXN0 cmllcyBVcGRhdGUNCkRyYWZ0OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2wt aWRyLWJncC1leHQtY29tLXJlZ2lzdHJ5LXVwZGF0ZS0wMA0KUHJlc2VudGVyOiBDaHJpc3RvcGgg TG9pYmwNClRpbWUgcGVyaW9kOiAxMCBtaW51dGVzDQpRdWVzdGlvbiBmb3IgV0c6ICBTaG91bGQg d2UgYWRvcHQ/DQoNCjYpIE9wZW4gbWljIHRpbWUNCg0KVG90YWwgdGltZTogfjE6MTUgbWludXRl cw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBt YWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWRyX187ISFORXQ2eU1hTy1nayFUdzV2SnZjRzExRzk2V1RKLWEyb1F6aF9wNXF4UUZ5a3k1cVFC Ynl1MXBqWWhnMExkeUxjdjFackVjdlFmQSQNCg0K --_000_1C4FE3CADDF447369CD1DE2296E73383junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkluIGNhc2UgYW55b25lIG5lZWRzIHRoZSBXZWJF eCBtZWV0aW5nIG51bWJlciwgaXTigJlzJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEs IDMxLCAzMSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsiIGNsYXNz PSIiPjY0NyA5OTggNjE0PC9zcGFuPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iIzFmMWYx ZiIgZmFjZT0iSGVsdmV0aWNhIE5ldWUiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDMxLCAzMSwgMzEpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY29sb3I9IiMxZjFmMWYiIGZhY2U9IkhlbHZl dGljYSBOZXVlIiBjbGFzcz0iIj7igJRKb2huPGJyIGNsYXNzPSIiPg0KPC9mb250Pg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gQXByIDcsIDIwMjAsIGF0IDEyOjM4IFBNLCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSIgY2xhc3M9IiI+c2hhcmVzQG5kemguY29tPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDIzNSwgMTU2KTsgd2lkdGg6IDg2N3B4OyBib3JkZXI6IDFwdCBu b25lIHJnYigxNTYsIDEwMSwgMCk7IHBhZGRpbmc6IDJwdDsgZm9udC1zaXplOiAxMC41cHQ7IGxp bmUtaGVpZ2h0OiAxMnB0OyBmb250LWZhbWlseTogTGF0bzsgdGV4dC1hbGlnbjogbGVmdDsgZm9u dC13ZWlnaHQ6IGJvbGQ7IiBjbGFzcz0iIj4NCjxzcGFuIDs9IiIgZm9udC13ZWlnaHQ6Ym9sZDs9 IiIgc3R5bGU9IiIgY2xhc3M9IiI+W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250 ZW50XTwvc3Bhbj48L2Rpdj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KT3VyIHNlY29uZCBpbnRlcmlt IGlzIG9uIFdlZG5lc2RheSA0LzgvMjAyMC4mbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpXZWJFeDo8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vaWV0Zi53ZWJleC5jb20vd2ViYXBwbmcvc2l0ZXMvaWV0 Zi9tZWV0aW5nL2Rvd25sb2FkLzVGRjREMzNCMjczQ0E5NTJFMDUzNjI4NEZDMEFDNzJFX187ISFO RXQ2eU1hTy1nayFUdzV2SnZjRzExRzk2V1RKLWEyb1F6aF9wNXF4UUZ5a3k1cVFCYnl1MXBqWWhn MExkeUxjdjFZRzRGTUJfUSQiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vd2ViYXBwbmcvc2l0 ZXMvaWV0Zi9tZWV0aW5nL2Rvd25sb2FkLzVGRjREMzNCMjczQ0E5NTJFMDUzNjI4NEZDMEFDNzJF PC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCkV0aGVycGFkIGZvciBub3RlLXRha2luZzo8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9ldGhl cnBhZC5pZXRmLm9yZzo5MDA5L3Avbm90ZXMtaWV0Zi1pbnRlcmltLTIwMjAtaWRyLTAyP3VzZU1v bm9zcGFjZUZvbnQ9dHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9ldGhlcnBhZC5pZXRmLm9yZzo5MDA5L3Avbm90 ZXMtaWV0Zi1pbnRlcmltLTIwMjAtaWRyLTAyP3VzZU1vbm9zcGFjZUZvbnQ9dHJ1ZTwvYT48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpFdGhl cnBhZCBmb3IgdmlydHVhbCBibHVlIHNoZWV0OjxhIGhyZWY9Imh0dHBzOi8vZXRoZXJwYWQuaWV0 Zi5vcmc6OTAwOS9wL25vdGVzLWlldGYtMTA3LWlkci0yLWJsdWVzaGVldCIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9l dGhlcnBhZC5pZXRmLm9yZzo5MDA5L3Avbm90ZXMtaWV0Zi0xMDctaWRyLTItYmx1ZXNoZWV0PC9h PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCmphYmJlcjombmJzcDsgPGEgaHJlZj0ibWFpbHRvOmlkckBqYWJiZXJ0 LmlldGYub3JnIiBjbGFzcz0iIj5pZHJAamFiYmVydC5pZXRmLm9yZzwvYT48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQoxLkFkbWluaXN0cml2 aWEgJiM0MzsgU3RhdHVzIDEwIG1pbnV0ZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgU3RhdHVzOiBG ZWVkYmFjayBvbiBpbnRlcmltcyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQoyLiBC R1AgWUFORyBNb2RlbCBTdGF0dXMgYW5kIElzc3VlczxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpEcmFmdDo8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlk ci1iZ3AtbW9kZWwtMDhfXzshIU5FdDZ5TWFPLWdrIVR3NXZKdmNHMTFHOTZXVEotYTJvUXpoX3A1 cXhRRnlreTVxUUJieXUxcGpZaGcwTGR5TGN2MVpQeFppUVp3JCIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1tb2RlbC0wODwvYT48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpQcmVzZW50ZXI6IE1haGVzaCBKZXRoYW5hbmRhbmk8c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KVGltZSBwZXJpb2Q6IDEwIG1pbnV0ZXMmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KQ2hhaXLigJlzIHF1ZXN0aW9u cyBmb3IgV0c6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjEpIERvZXMgaXQgbWF0dGVyIHRoYXQgdGhpcyBpcyBvbmx5IG1hY2hp bmUgZnJpZW5kbHk/PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCjIpIEFyZSB3ZSByZWFkeSBmb3IgV0cgTEMgb24gdGhpcyBkb2N1 bWVudD88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KMy4gUHJlc2Vu dGF0aW9ucyDigJMgbmV3IGRyYWZ0cyBvciBzdGF0dXMgdXBkYXRlczxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZsb3dzcGVjIGZv ciBMMiBhbmQgVHVubmVsZWQgVHJhZmZpYzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkRyYWZ0OjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt aWRyLWZsb3dzcGVjLWwydnBuLTEzX187ISFORXQ2eU1hTy1nayFUdzV2SnZjRzExRzk2V1RKLWEy b1F6aF9wNXF4UUZ5a3k1cVFCYnl1MXBqWWhnMExkeUxjdjFhV1RuYy0wZyQiIHN0eWxlPSJjb2xv cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1mbG93c3BlYy1sMnZwbi0xMzwvYT48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWlkci1mbG93c3BlYy1udm8zLTA4X187ISFORXQ2eU1hTy1nayFUdzV2SnZjRzEx Rzk2V1RKLWEyb1F6aF9wNXF4UUZ5a3k1cVFCYnl1MXBqWWhnMExkeUxjdjFhOXlHMXM4USQiIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1mbG93c3BlYy1udm8z LTA4PC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NClByZXNlbnRlcjogRG9uYWxkIEVhc3RsYWtlPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KVGltZSBwZXJpb2Q6IDIwIG1pbnV0ZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQpDaGFpcuKAmXMgcXVlc3Rpb25zIGZvciBXRy9wcmVzZW50ZXJzOjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQoxKSBB cmUgdGhlcmUgaW1wbGVtZW50YXRpb25zIG9mIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLWwydnBu LTEzLnR4dD88bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQoyKSBBcmUgd2UgcmVhZHkgZm9yIFdHIExDPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjMp IElzIHRoZSByZXZpc2lvbiBkcmFmdC1pZHItZmxvd3NwZWMtbnYwMy0wOC50eHQgcmVhZHkgZm9y IGVhcmx5IGFsbG9jYXRpb24/PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KMikm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQkdQIFdlbGwta25vd24gTGFyZ2UgQ29tbXVu aXRpZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQpEcmFmdDo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWhlaXR6LWlkci13a2xjLTAwIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaGVpdHotaWRyLXdrbGMtMDA8L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KUHJlc2VudGVyOiBKYWtvYiBI ZWl0ejxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NClRpbWUgcGVyaW9kOiAxMCBtaW51dGVzPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KNCkgJm5ic3A7QkdQIGNvbW11bml0aWVzIOKAkyBSZXNlYXJj aCBpbnRvIFdvcm1zPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwO1BhcGVyOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6Ly9hcmNoaXZlLnBzZy5jb20vMTgxMTAxLmltYy1jb21tdW5pdGllcy5wZGZfXzsh IU5FdDZ5TWFPLWdrIVR3NXZKdmNHMTFHOTZXVEotYTJvUXpoX3A1cXhRRnlreTVxUUJieXUxcGpZ aGcwTGR5TGN2MWJmNnNCcHZRJCIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9hcmNoaXZlLnBzZy5jb20vMTgxMTAxLmlt Yy1jb21tdW5pdGllcy5wZGY8L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KUHJlc2VudGVyOiZuYnNwOyBSYW5k eSBCdXNoPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KNCkgTGFyZ2UgRGlzY3Vz c2lvbiB0aW1lOiAxNSBtaW51dGVzPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjEpIFdoYXQgYXJlIHRoZSBvcGVyYXRvciBuZWVk cz88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KMikgV2hhdCBhYm91dCB0aGUgaXNzdWVzIHJhaXNlZCBCR1AgcmVzZWFyY2hlcj8g Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KNSkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQkdQIEV4dGVuZGVkIENvbW11bml0eSBSZWdpc3RyaWVzIFVwZGF0 ZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCkRyYWZ0OjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y2wtaWRyLWJncC1leHQtY29tLXJlZ2lzdHJ5LXVwZGF0ZS0wMCIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNsLWlkci1iZ3AtZXh0LWNvbS1yZWdpc3RyeS11cGRhdGUtMDA8 L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KUHJlc2VudGVyOiBDaHJpc3RvcGggTG9pYmw8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQpUaW1lIHBlcmlvZDogMTAgbWludXRlczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClF1ZXN0aW9uIGZvciBXRzom bmJzcDsgU2hvdWxkIHdlIGFkb3B0PzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo2KSBPcGVu IG1pYyB0aW1lPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClRvdGFsIHRpbWU6IH4xOjE1IG1p bnV0ZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5J ZHINCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpJZHJAaWV0Zi5vcmciIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5JZHJAaWV0Zi5vcmc8L2E+PGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcl9fOyEhTkV0NnlNYU8tZ2shVHc1dkp2Y0cxMUc5NldUSi1hMm9RemhfcDVxeFFG eWt5NXFRQmJ5dTFwalloZzBMZHlMY3YxWnJFY3ZRZkEkIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyX187ISFORXQ2eU1hTy1nayFUdzV2SnZj RzExRzk2V1RKLWEyb1F6aF9wNXF4UUZ5a3k1cVFCYnl1MXBqWWhnMExkeUxjdjFackVjdlFmQSQ8 L2E+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PC9zcGFuPjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_1C4FE3CADDF447369CD1DE2296E73383junipernet_-- From nobody Wed Apr 8 06:00:03 2020 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 9BACE3A0A2E for ; Wed, 8 Apr 2020 06:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=HxIOVnep; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qSa8nPMs 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 pG1xMOf9n94N for ; Wed, 8 Apr 2020 05:59:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615DA3A0A29 for ; Wed, 8 Apr 2020 05:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31759; q=dns/txt; s=iport; t=1586350798; x=1587560398; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=A5jTp6mjXFTpOzJgFfaByvHykpx8lO4nGIKQm3hRz3U=; b=HxIOVnep7COZKLFCV5S+VyVWvQw41BH0Jq5CiZq/EgnilD6unS8e1dcA Loxqx4PRRGxHYjjlKzblYR+0AS/CLFRYCJQ+VQipAvnsfWspHccZNH9AD awCERL4UV/Jg+74mnxNjkds5jzI/GQAiJYsy7bMmfa2bjmkk5lbu8QwKU 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AMqGNIRVx+uH1o9GkVHo3nSHoAZbV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dEwd4TgxRmBceEDUPhK/u/Zic3EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIBAAoyo1e/4MNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElL1AFbFggBAsqCoQSg0UDimtOgWwlgQGXH4JSA1Q?= =?us-ascii?q?KAQEBDAEBIwoCBAEBhEQCF4FwJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQE?= =?us-ascii?q?BAQMSER0BATgPAgEIDgMDAQIhCgICAjAdCAEBBAESIoMEAYF+TQMuAQ6lVgK?= =?us-ascii?q?BOYhidYEygn8BAQWBQ0FBgnkYgg0DBoE4jDMaggCBEScMEIIYNT6BBIFjAgM?= =?us-ascii?q?BgXgJDYJlMoIsjgASgnuGBZoiCoI9h3WPQB2CTog6hF+MIYRdil+JKJMDAgQ?= =?us-ascii?q?CBAUCDgEBBYFpIoFXcBU7KgGCPlAYDZEiDAwLg1CFFIVBdIEpjRkBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,358,1580774400"; d="scan'208,217";a="743637650" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 12:59:56 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 038CxutF030224 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 12:59:56 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 07:59:56 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 07:59:56 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 07:59:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aHHdKhAqWUtdUpr3lj4proks02ITEeIwyOAr3tmUPasM+/n8dzChUmayJkJFt1dOkwTbggBUhOhajMhtqNNs/wKu36k1oKQfSZsVz78kwHViCx1SQy4yOf1G3+KscNUutBr4ewrr6crKQwBJOpT8jIquFDQifMqEizbVp7ha0APySokAY9azi/Kc7vaPZkhecjFcNOe5sCb8c9qgv4L0sptog2ayJjvFtStvzaa6QO3k3M5TFoVj8ppzMHWvqmeQfClmJBRuNzEFvjpB1EoZPcPwavSMZJJmAsM5v0xa/pLr2gzHZGMmPz9o9JYFplcWbUlMsEafwp3yuyPy0/zqWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A5jTp6mjXFTpOzJgFfaByvHykpx8lO4nGIKQm3hRz3U=; b=oZJaWiyBSaIQS7tuQniyBSrp5E7pfOc63bz8O2Mu/6kChfYfq5E7YqPdt+bRz/EUC+tx5jxxI/QEWFTQYdyiPqaBc39Mg4QEu/FrG7tuz/7O7PBl/sRMA09gAiw7uxqSF+HRJmXNMmmDIfrza1DI8fdAAVYIqeVepEMEqDvsryxvsm/ce50BVveyr2t5VmJgTURR7T9v37ZizAOQ7rAYRB0Kxila8TTRS3SAreA9HEA5d53vhzdONNKH4UYXJS5Zrp4aC+1AHsruKslmpTtObDRS/bAXMxKIQnYcDzkhL33LVfmhloOh6x9v/+/u3Xel7TFcrkrUV2NH/4zoL3ATEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A5jTp6mjXFTpOzJgFfaByvHykpx8lO4nGIKQm3hRz3U=; b=qSa8nPMsvkCXznuhgTNgL96eCgXxeq3yELEPQ0c/kcbs+b3fX8CunHAYKtL2UMM+GaI+dQTlF2rN/+uAE8mHILQ2CjrUnm9aoYuF2B/53mxqSFw/x5UqQHzM214AhVpuOZcZKjnHwEhb5PO8Sbdt3WSrjk3taCYPgv0nMeRGXtw= Received: from BN8PR11MB3794.namprd11.prod.outlook.com (2603:10b6:408:8f::13) by BN8PR11MB3651.namprd11.prod.outlook.com (2603:10b6:408:81::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr 2020 12:59:55 +0000 Received: from BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::55b2:c415:675f:5fb7]) by BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::55b2:c415:675f:5fb7%3]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 12:59:55 +0000 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] status - incremental 4/8/2020 - Thread-Index: AdYNokgRyeOIrfLpRmOFOKAsBaX81v//w5KA Date: Wed, 8 Apr 2020 12:59:54 +0000 Message-ID: References: <008901d60da2$74031370$5c093a50$@ndzh.com> In-Reply-To: <008901d60da2$74031370$5c093a50$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c190057b-450f-45f4-8038-08d7dbbcbc00 x-ms-traffictypediagnostic: BN8PR11MB3651: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3794.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(136003)(376002)(366004)(346002)(39860400002)(478600001)(71200400001)(91956017)(81156014)(6512007)(66946007)(66476007)(76116006)(186003)(6506007)(6486002)(2616005)(66446008)(8676002)(53546011)(26005)(64756008)(316002)(36756003)(110136005)(33656002)(66556008)(5660300002)(86362001)(9326002)(81166007)(8936002)(2906002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ngk3KGHnzjItWBqwC1eti8thzDT+sbL+7uOQRmNy8NkrZ4fdiBSgwTa3vHBJ8JwlDE+KoEBei0SISR21adwFqo6YeQOLElhJCt2cPxw1+GB84tIZ/ddAvTQ3BKEeGd7g9RfwjKDHl2ihOtNfEEMwQbxGBd6VQil9u38mtAb8QrcK2JhLIMmOqd0peW4UKqOaIV1oCxZS7VESZ9E4rUPaVYGJLhhzYAgjHfhnALVMlgGGtjOVB2ksNzB5Zx28gEI4XlozKvnvHjE8nFgXaX62ejpUx6Ln5UPeEk3HeHHv8cVAHg1T02vfsbhZ9D7jUuuPY7Ce5x2j/FILwncKQ6QqREuFC1SkTK01oqXAl4xK8DJeapy5v2+LBQ9eb/uRvsfjUdNOR7G4uoK7ou0Ej3vweUcmDKlSHJw8A13CFlDcEQxicl0bSJd0QI8f1YQVwSQiQ31S8Fbp0Rj67gIv35FKBQx77+QbHorObAw41k4fbDr2j35zfdhsadqjI73xJY9oTehJsBFh6a+ZfD1A4VvBdA== x-ms-exchange-antispam-messagedata: dHSbuRay8rLt5kZCwf93rhBugCgdZsleShYSID8itILkcibUrmTlwSHHtwT9wkfFFOYmFPCH6Co+nLqqLOnqJ7mVUnAXZsKUWxVcTaMhKA4cYsXdcHDkRt3mU45b0pcTlwYkyJpV+L7AXXfj0M0/Dg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DDB167A3977A4815AE9BC5D404816CAEciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c190057b-450f-45f4-8038-08d7dbbcbc00 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 12:59:54.9379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OfnvBxUsnJ4zkzNe3dSIfsWEbnaaWIvkFhJUSlgXKkM6dg+ypsfnIq59oDoNp3ao X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3651 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Idr] status - incremental 4/8/2020 - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 13:00:01 -0000 --_000_DDB167A3977A4815AE9BC5D404816CAEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KT25lIGNsYXJpZmljYXRpb27igKYNCg0KRnJvbTogSWRyIDxpZHItYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+DQpEYXRl OiBXZWRuZXNkYXksIEFwcmlsIDgsIDIwMjAgYXQgODo0MCBBTQ0KVG86IElEUiBMaXN0IDxpZHJA aWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWRyXSBzdGF0dXMgLSBpbmNyZW1lbnRhbCA0LzgvMjAyMCAt DQoNCklEUiBXRzoNCg0KQSBsaXR0bGUgc3RhdHVzIHRvIHJlYWQgd2l0aCB5b3VyIGNvZmZlZSB0 aGlzIG1vcm5pbmcuICAgV2UgaGF2ZSBhbiBpbnRlcmltIGF0IDEzOjAwIFVUQyAoOTowMCBFRFQs ICA2OjAwIFBEVCwgMjE6MDAgQmVqaW5nIHRpbWUpDQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiBJ 4oCZdmUgbWlzc2VkIGFueSB1cGRhdGVzLg0KDQpDaGVlcnMsIFN1ZQ0KDQotLS0tLS0tLS0NCkF0 IElFU0cgaW4gSUVURiBMQw0KMSkgZHJhZnQtaWV0Zi1pZHItcmZjNTU3NWJpcy0xOS50eHQg4oCT DQogICAgU2hlcGhlcmQ6IEpvaG4gU2N1ZGRlcg0KICAgIFN0YXR1czogIElFVEYgTEMgZW5kZWQs IElFU0cgdGVsZWNoYXQ6IDQvMTUNCiAgICBJRVNHIFB1YmxpY2F0aW9uIHJlcXVlc3Q6IDcvOS8y MDE5DQogICAyICBBRCBSZXZpZXdzIFs4LzItOS8xMC8yMDE5LCBbMS8xNy0xLzIzLzIwMjBdDQoN CjIpIGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctbXNkLTA4LnR4dA0KICAg ICBbU2hlcGhlcmQ6IFN1c2FuIEhhcmVzXQ0KICAgICBTdGF0dXM6ICAzcmQgcm91bmQgb2YgQUQg cmV2aXNpb25zDQogICAgIElFU0cgUHVibGljYXRpb24gcmVxdWVzdGVkOiAgMTAvMTUvMjAxOQ0K DQogICAgIElFVEYgV0cgTEM6ICA2IGRheXMNCg0KLS0tLS0tLS0tLS0tLS0NCkFEIHJldmlldyDi gJMgYXV0aG9ycyBuZWVkIHRvIHJlc3BvbmQNCjEpIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNh cHMtMTQ8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItdHVu bmVsLWVuY2Fwcy8+IC0gc2VudCB0byBJRVNHDQpbV2FpdGluZyA0NyBkYXlzXQ0KDQpTbywgdGhp cyBkcmFmdCByZXF1aXJlcyBhIHJlc3BvbnNlIGZyb20gdGhlIGF1dGhvcnMgdG8gQWx2YXJvPyBJ dCBoYXNu4oCZdCBnb25lIHRvIGZ1bGwgSUVTRyB5ZXQg4oCTIHJpZ2h0PyBXZSBoYXZlIGEgY291 cGxlIExTUiBkcmFmdHMgd2l0aCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuDQoNClRoYW5rcywNCkFj ZWUNCg0KMikgZHJhZnQtaWV0Zi1pZHItY2FwYWJpbGl0aWVzLXJlZ2lzdHJ5LWNoYW5nZS0wNS50 eHQNCltXYWl0aW5nIDU3IGRheXNdDQotLS0tLS0tLS0tLS0NCldHIHBhc3QgV0cgTEMg4oCTIHN0 dWNrICB3YWl0aW5nIGZvciBpbXBsZW1lbnRhdGlvbiByZXBvcnRzIG9uIHdpa2kNCltyZXBvcnRl ZCB0byBoYXZlIDIgaW1wbGVtZW50YXRpb25zLCBidXQgbm8gZGV0YWlscyBvbiB3aWtpXQ0KDQox KSBkcmFmdC1pZXRmLWlkci1leHQtb3B0LXBhcmFtDQoyKSBkcmFmdC1pZHItZWFnLWRpc3RyaWJ1 dGlvbi0wOS50eHQNCi0tLS0tLS0tLQ0KRHJhZnRzIHN0dWNrIHBvc3QgV0cgTEMg4oCTIHdhaXRp bmcgZm9yIG1pbm9yIGVkaXRzDQoxKSBkcmFmdC1pZXRmLWlkci1yZmM4MjAzYmlzLjA1LnR4dCAg LQ0KLS0tLQ0KRmxvdyBzcGVjaWZpY2F0aW9uIGRyYWZ0cyBpbiBXRyBMQw0KDQoxKSBEcmFmdC1p ZXRmLWlkci1mbG93LXNwZWMtdjYtMTAudHh0DQogICBTdGF0dXM6IHJlc3RhcnRlZCBbNC84IHRv IDQvMjJdDQogICBTdGF0dXM6IElFU0cgZGVzaXJlcywgYnV0IGlzIGl0IHJlYWR5Pw0KICAgTmVl ZGVkOiAgaW1wbGVtZW50YXRpb24gcmVwb3J0cw0KDQoyKSBkcmFmdC1pZXRmLWlkci1iZ3AtZmxv d3NwZWMtb2lkLTExPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aWRyLWJncC1mbG93c3BlYy1vaWQvPg0KICAgIFN0YXR1czogIDMvMTMvIHRvIDQvMTMNCiAgICBT dGF0dXM6IGxpZ2h0IHJlc3BvbnNlLCBwbGVhc2UgY29tbWVudA0KICAgIEF1dGhvcnM6ICBQbGVh c2UgZmlsbCBvdXQgaW1wbGVtZW50YXRpb24gcmVwb3J0DQoNCi0tLS0tLS0tLS0tDQpXRyBBZG9w dGlvbiBjYWxsczoNCg0KICAgMSkgRHJhZnQtaHVqdW4taWRyLWJncC1pcHNlYw0KICAgICAgIFdH IGFkb3B0aW9uOiAgMy8zMC00LzEzDQogICAgICAgIFNoZXBoZXJkOiBTdXNhbiBIYXJlcw0KICAg ICAgICBDb21tZW50OiBvbmx5IDEgcmVzcG9uc2UsIGhlYWRpbmcgdG93YXJkIOKAnG5vIGNvbnNl bnN1c+KAnQ0KDQoyKSBkcmFmdC1odWp1bi1pZHItYmdwLWlwc2VjLXRyYW5zcG9ydC1tb2RlDQog ICAgIFdHIEFkb3B0aW9uOiAzLzMwIOKAkyA0LzEzDQogICAgICBTaGVwaGVyZDogU3VzYW4gSGFy ZXMNCiAgICAgQ29tbWVudDogb25seSAxIHJlc3BvbnNlLCBoZWFkaW5nIHRvd2FyZCDigJxubyBj b25zZW5zdXPigJ0NCg0KMykgZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS0wMy50eHQN CiAgICBXRyBhZG9wdGlvbjogMy8zMCDigJMgNC8xMw0KICAgICBTaGVwaGVyZDogU3VzYW4gSGFy ZXMNCiAgICBDb21tZW50OiBQb3NpdGl2ZSByZXNwb25zZTogSGVhZGluZyB0b3dhcmQgV0cgQWRv cHRpb24NCg0KUmVxdWVzdCBmb3IgaW5wdXQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpkcmFm dC1zY2hhcmYtdGNwbS15YW5nLXRjcC0wNA0KDQpQcm9wb3NlZCBXRyBMQyBkcmFmdHMgZm9yIGZs b3ctc3BlY2lmaWNhdGlvbiB0aGF0IHdlcmUgb24gaG9sZDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCltBdXRob3JzIHNob3VsZCBjb250YWN0IGNoYWlyc10N Cg0KMSkgIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldC0wNSDigJMNCldHIG5v dGVzIGluZGljYXRlZCB0aGlzIG1pZ2h0IGdvIGFoZWFkIHdpdGhvdXQgZmxvdy1zcGVjaWZpY2F0 aW9uIHYyDQoNCjIpIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMTAg4oCT DQpXRyBkaXNjdXNzaW9uIG5lZWRzIHRvIG9jY3VyIG9uIHdoZXRoZXIgZmxvd3NwZWNpZmljYXRp b24NCg0KDQpQcm9wb3NlZCBXRyBMQ3MgKDMvMzAgYW5kIDQvOCkNCi0tLS0tLS0tLS0tLS0tLS0N CjEpIGRyYWZ0LWlldGYtaWRyLWJncC1vcGVuLXBvbGljeS0wOCDigJMgb24gaG9sZCBwZW5kaW5n ICByZXZpc2lvbiAtMDkNCjIpICBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1sMnZwbi0xMyDigJMg aW4gc2xpZGVzIGZvciA0LzgNCg0KDQpQcm9wb3NlZCBBZG9wdGlvbiBjYWxscw0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCmRyYWZ0LWNsLWlkci1iZ3AtZXh0LWNvbS1yZWdpc3RyeS11ZHBhdGUt MDAudHh0DQoNCg0KDQoNCg0K --_000_DDB167A3977A4815AE9BC5D404816CAEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <58183D33B9C45F48A58B088A60344C62@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFN1ZSwgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgY2xhcmlmaWNhdGlvbuKApiA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+SWRyICZsdDtpZHItYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFN1c2FuIEhh cmVzICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwg QXByaWwgOCwgMjAyMCBhdCA4OjQwIEFNPGJyPg0KPGI+VG86IDwvYj5JRFIgTGlzdCAmbHQ7aWRy QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bSWRyXSBzdGF0dXMgLSBpbmNyZW1l bnRhbCA0LzgvMjAyMCAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklEUiBXRzo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+QSBsaXR0bGUgc3RhdHVzIHRvIHJlYWQgd2l0aCB5b3VyIGNvZmZlZSB0 aGlzIG1vcm5pbmcuICZuYnNwOyZuYnNwO1dlIGhhdmUgYW4gaW50ZXJpbSBhdCAxMzowMCBVVEMg KDk6MDAgRURULCZuYnNwOyA2OjAwIFBEVCwgMjE6MDAgQmVqaW5nIHRpbWUpDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIGxldCBtZSBrbm93IGlmIEnigJl2ZSBtaXNzZWQg YW55IHVwZGF0ZXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hlZXJzLCBTdWUN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLS0tLS0tLS08L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkF0IElFU0cgaW4gSUVURiBMQw0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hp dGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjEpIGRyYWZ0LWlldGYtaWRyLXJmYzU1NzVi aXMtMTkudHh0IOKAkw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NoZXBoZXJkOiBKb2huIFNjdWRkZXINCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5k OndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsgU3Rh dHVzOiZuYnNwOyBJRVRGIExDIGVuZGVkLCBJRVNHIHRlbGVjaGF0OiA0LzE1DQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3 aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 SUVTRyBQdWJsaWNhdGlvbiByZXF1ZXN0OiA3LzkvMjAxOQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOzIgJm5ic3A7QUQgUmV2aWV3 cyBbOC8yLTkvMTAvMjAxOSwgWzEvMTctMS8yMy8yMDIwXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+MikgZHJhZnQtaWV0Zi1pZHItYmdwLWxzLXNlZ21lbnQtcm91dGluZy1tc2QtMDgu dHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb U2hlcGhlcmQ6IFN1c2FuIEhhcmVzXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU3RhdHVzOiAmbmJzcDszPHN1cD5yZDwvc3VwPiByb3VuZCBvZiBB RCByZXZpc2lvbnMgJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO0lFU0cgUHVibGljYXRpb24gcmVxdWVzdGVkOiAmbmJzcDsxMC8x NS8yMDE5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJRVRGIFdHIExDOiZuYnNwOyA2IGRheXMgJm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QUQgcmV2aWV3 IOKAkyBhdXRob3JzIG5lZWQgdG8gcmVzcG9uZA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjEpIDwvc3Bhbj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91bmQ6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMtMTQ8L3NwYW4+PC9hPiAtIHNlbnQgdG8g SUVTRw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gY2xhc3M9Ik1zb0h5cGVybGluayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Y29sb3I6IzNEMjJCMztiYWNrZ3JvdW5kOndoaXRlO3RleHQtZGVjb3JhdGlv bjpub25lIj5bV2FpdGluZyA0NyBkYXlzXQ0KPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iTXNv SHlwZXJsaW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjp3aW5kb3d0ZXh0 O2JhY2tncm91bmQ6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0aGlzIGRyYWZ0IHJlcXVpcmVzIGEgcmVzcG9uc2Ug ZnJvbSB0aGUgYXV0aG9ycyB0byBBbHZhcm8/IEl0IGhhc27igJl0IGdvbmUgdG8gZnVsbCBJRVNH IHlldCDigJMgcmlnaHQ/IFdlIGhhdmUgYSBjb3VwbGUgTFNSIGRyYWZ0cyB3aXRoIGEgbm9ybWF0 aXZlIHJlZmVyZW5jZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY2VlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjIpIGRyYWZ0LWlldGYtaWRyLWNhcGFiaWxp dGllcy1yZWdpc3RyeS1jaGFuZ2UtMDUudHh0DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W1dhaXRpbmcgNTcgZGF5 c10gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V0cgcGFzdCBXRyBMQyDigJMgc3R1Y2sgJm5ic3A7 d2FpdGluZyBmb3IgaW1wbGVtZW50YXRpb24gcmVwb3J0cyBvbiB3aWtpPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JlcG9ydGVk IHRvIGhhdmUgMiBpbXBsZW1lbnRhdGlvbnMsIGJ1dCBubyBkZXRhaWxzIG9uIHdpa2ldDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4xKSBkPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6Ymxh Y2s7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+cmFmdC1pZXRm LWlkci1leHQtb3B0LXBhcmFtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjIpIGRyYWZ0LWlkci1lYWctZGlzdHJpYnV0aW9uLTA5LnR4dA0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGU7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5EcmFmdHMg c3R1Y2sgcG9zdCBXRyBMQyDigJMgd2FpdGluZyBmb3IgbWlub3IgZWRpdHMNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjEpIDxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGU7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KZHJhZnQtaWV0Zi1pZHItcmZjODIwM2Jpcy4w PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMxRjQ5N0Q7YmFja2dy b3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+NTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4udHh0ICZuYnNwOy0NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPkZsb3cgc3BlY2lmaWNhdGlvbiBkcmFmdHMgaW4gV0cgTEMNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndo aXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZTttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+MSkNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5EcmFmdC1p ZXRmLWlkci1mbG93LXNwZWMtdjYtMTAudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOyZuYnNwOyBTdGF0dXM6IHJlc3RhcnRlZCBbNC84IHRvIDQvMjJdPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyBTdGF0dXM6IElFU0cgZGVzaXJlcywgYnV0IGlzIGl0 IHJlYWR5Pw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91 bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwO05l ZWRlZDombmJzcDsgaW1wbGVtZW50YXRpb24gcmVwb3J0cw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtiYWNr Z3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4yKQ0KPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncC1m bG93c3BlYy1vaWQvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIz O2JhY2tncm91bmQ6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaWRyLWJn cC1mbG93c3BlYy1vaWQtMTE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBTdGF0 dXM6ICZuYnNwOzMvMTMvIHRvIDQvMTMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U3Rh dHVzOiBsaWdodCByZXNwb25zZSwgcGxlYXNlIGNvbW1lbnQNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0F1dGhvcnM6Jm5ic3A7IFBsZWFzZSBmaWxsIG91dCBpbXBsZW1lbnRhdGlvbiBy ZXBvcnQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrO2Jh Y2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5k OndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tLS0tLS0tLS0tLTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndo aXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XRyBBZG9wdGlvbiBjYWxsczoNCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjaztiYWNrZ3Jv dW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7IDEpIERyYWZ0LWh1anVuLWlkci1iZ3AtaXBzZWM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFdHIGFkb3B0aW9uOiZuYnNwOyAzLzMwLTQvMTM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNoZXBoZXJk OiBTdXNhbiBIYXJlcw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2Jh Y2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NvbW1lbnQ6IG9ubHkgMSByZXNwb25z ZSwgaGVhZGluZyB0b3dhcmQg4oCcbm8gY29uc2Vuc3Vz4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtiYWNr Z3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4yKSBkcmFmdC1odWp1bi1p ZHItYmdwLWlwc2VjLXRyYW5zcG9ydC1tb2RlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXRyBBZG9wdGlvbjogMy8zMCDigJMgNC8xMzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2hlcGhl cmQ6IFN1c2FuIEhhcmVzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7 YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29tbWVudDogb25seSAxIHJlc3BvbnNlLCBoZWFkaW5nIHRvd2Fy ZCDigJxubyBjb25zZW5zdXPigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjMpIGRyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1t dHUtMDMudHh0DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dy b3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7V0cgYWRvcHRpb246IDMvMzAg4oCTIDQvMTMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTaGVwaGVyZDogU3VzYW4gSGFyZXMN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRl O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb21t ZW50OiBQb3NpdGl2ZSByZXNwb25zZTogSGVhZGluZyB0b3dhcmQgV0cgQWRvcHRpb24NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ UmVxdWVzdCBmb3IgaW5wdXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE O2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dy b3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ZHJhZnQtc2NoYXJmLXRjcG0t eWFuZy10Y3AtMDQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dy b3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPlByb3Bvc2VkIFdHIExDIGRyYWZ0cyBmb3IgZmxvdy1zcGVjaWZpY2F0 aW9uIHRoYXQgd2VyZSBvbiBob2xkOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+W0F1dGhvcnMgc2hvdWxkIGNvbnRhY3QgY2hhaXJzXQ0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4xKSAmbmJzcDtk cmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXQtMDUg4oCTDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+V0cgbm90ZXMgaW5kaWNhdGVkIHRoaXMgbWlnaHQgZ28gYWhlYWQgd2l0 aG91dCBmbG93LXNwZWNpZmljYXRpb24gdjINCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3 aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+MikgZHJhZnQtaWV0Zi1pZHItZmxvd3Nw ZWMtcGF0aC1yZWRpcmVjdC0xMCDigJMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XRyBk aXNjdXNzaW9uIG5lZWRzIHRvIG9jY3VyIG9uIHdoZXRoZXIgZmxvd3NwZWNpZmljYXRpb24NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91 bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlByb3Bvc2VkIFdHIExDcyAoMy8z MCBhbmQgNC84KQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tn cm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tLS0tLS0tLS0tLS0tLS08 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+MSkgZHJhZnQtaWV0Zi1pZHItYmdwLW9wZW4tcG9s aWN5LTA4IOKAkyBvbiBob2xkIHBlbmRpbmcmbmJzcDsgcmV2aXNpb24gLTA5PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjIpICZuYnNwO2RyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLWwydnBuLTEz IOKAkyBpbiBzbGlkZXMgZm9yIDQvODwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPlByb3Bvc2VkIEFkb3B0aW9uIGNhbGxzICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5k cmFmdC1jbC1pZHItYmdwLWV4dC1jb20tcmVnaXN0cnktdWRwYXRlLTAwLnR4dDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOndoaXRlO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0Q7YmFja2dyb3VuZDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrO2Jh Y2tncm91bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjojMUY0OTdEO2JhY2tncm91 bmQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DDB167A3977A4815AE9BC5D404816CAEciscocom_-- From nobody Wed Apr 8 06:27:37 2020 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 8B53A3A08AB for ; Wed, 8 Apr 2020 06:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA9fMzWFXMcD for ; Wed, 8 Apr 2020 06:27:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDB93A08AA for ; Wed, 8 Apr 2020 06:27:33 -0700 (PDT) Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8343B1A33B74C109CB61 for ; Wed, 8 Apr 2020 14:27:30 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Apr 2020 14:27:29 +0100 Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 8 Apr 2020 21:27:27 +0800 Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1713.004; Wed, 8 Apr 2020 21:27:27 +0800 From: Zhuangshunwan To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAHGzirQ Date: Wed, 8 Apr 2020 13:27:27 +0000 Message-ID: <2967637f61f849c5add76719fa07dd80@huawei.com> References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.191.209] Content-Type: multipart/alternative; boundary="_000_2967637f61f849c5add76719fa07dd80huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 13:27:36 -0000 --_000_2967637f61f849c5add76719fa07dd80huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Best Regards, Shunwan From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 8:36 PM To: 'IDR List' Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_2967637f61f849c5add76719fa07dd80huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Best Regards,

Shunwan

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

    SR-V6, = and SR-Policy.   

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_2967637f61f849c5add76719fa07dd80huaweicom_-- From nobody Wed Apr 8 06:57:01 2020 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 1B9E43A095B; Wed, 8 Apr 2020 06:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 nUX__Tmr2DH6; Wed, 8 Apr 2020 06:56:56 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2129.outbound.protection.outlook.com [40.107.244.129]) (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 66CF73A1012; Wed, 8 Apr 2020 06:55:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CQY7CB9Ze4Rl32JtanWF0r5iH2df1NPv97Zfx8Z7EEyX0dxqjcbi9Fsd8TFGm6OzyUvQTWf8COrHRtpxvjb2o1KZ0ZOKl+Exc1oh+6gi4xzfySvRvK/EKt3cEnSh6DH0bFoqRlhUu+T0REI6tbK7g4hnm4452kwIoZVPye1QbD8CUSEBE+Qr4w/byDfoJIiAgGUxKhLWTu4LQ18J28HZM/jhTkBRdZF6JSeWUmV+bEVG9Qkp7V+orARsqONHo1GnxV/pyNnerxNaFYhMxsG0R7A4pTev7onx3B+I2YHeZ+hEF0i6mncIdBhvhMoPF0THDVITpbNSLlyBqZwNQNjmoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IcH4rUjhu6QGtUcWLEaKexAk35uVKlwpOleQYfXbM2k=; b=cPfb2QTr8nUN5D4X054iYXg4JhPrPqhwfE7iK2VOapWYBZkqFVpJtfpqwEGA55X4ahOrddOG7U7onkxRaSxfe00AMKnoArBVsOfd54w96/A2dryca+iq1J7kl53QKMxG6a4Cf7vQLccK0fkB4wR67WNwvKlXGzZI+lfPuqLl6hPSIVpnGD4uNhH79KSBuJA4OVmQn4FpN3i2PjJCrhexVlUjkChdsPAZ5oA9ijmkXPuQfSF7MmpecIhH+b2CZPhEtSkBiVevWZQg0X5axqPC1ORfH1ePanjoqu2Kj7sgPAKGT4t3dPQ74QlpX+616trGYqWWTwYBwaWZl/SD4AyBeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IcH4rUjhu6QGtUcWLEaKexAk35uVKlwpOleQYfXbM2k=; b=je0hMpEcnVVi8CbkFJ7mzG5gy8zZN4qnyFR+QJ3uMkSmKkLtcdJj29W5MtVjJyasPB867/aaNkCDKK2GPGFz7Yl//8x/MuWLHnvKkt5qc7jslE60zn2APWJdoPFzIUS6tA+rx+W3EC6RRzAJfX1w/PiOT7zLvAna48DiFtVyaYI= Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB1903.namprd13.prod.outlook.com (2603:10b6:301:2d::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Wed, 8 Apr 2020 13:55:27 +0000 Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945%3]) with mapi id 15.20.2900.012; Wed, 8 Apr 2020 13:55:26 +0000 From: Linda Dunbar To: Susan Hares , "idr@ietf.org" CC: "draft-hujun-idr-bgp-ipsec@ietf.org" Thread-Topic: [Idr] status - incremental 4/8/2020 - Thread-Index: AdYNokgRyeOIrfLpRmOFOKAsBaX81gAClIpw Date: Wed, 8 Apr 2020 13:55:26 +0000 Message-ID: References: <008901d60da2$74031370$5c093a50$@ndzh.com> In-Reply-To: <008901d60da2$74031370$5c093a50$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ebcddc6-fa21-49b5-1fde-08d7dbc47dd0 x-ms-traffictypediagnostic: MWHPR1301MB1903: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1301MB2096.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(346002)(136003)(39840400004)(396003)(376002)(366004)(44832011)(55016002)(2906002)(66446008)(33656002)(9686003)(8676002)(66556008)(4326008)(86362001)(64756008)(71200400001)(66476007)(478600001)(5660300002)(6506007)(66946007)(53546011)(76116006)(7696005)(81156014)(99936003)(26005)(81166007)(8936002)(186003)(316002)(52536014)(66616009)(110136005); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mlFD7+uyHlUzB2jYuLBvQbNcx9BFZjDhUIjSwXIHE5+lPD7Q87KuO61Ood82PsIZKz5XWDrkmrcgJ/xhI5R6LXg0jL8oZzZhwWCNB542d3jDJ6jf2OVRCS+Ev9z3zmVpBjNkbVLyo18FsqUo+C/pcCvcEcUmsLmZe5c3Oc6xTXWd7/sz/f3AxFUseLaKsMWxkoJYLUWudj4I0HFSe7lLxu8n0NLYjgU/lSvspboreE7xxsxCMasI+P8CGFgBcPzX3qeSbBnJLynfaEUMm0OVRglJI707BA5WPjzxfRM9d7Sl46FFBlfTqmqderHn32oc+3rvNbV8pUkv6ppx96o7OE4QB9KZ0T1oWOuqYIr+oAVjC6pEevL3nWmHVYGZ4NZ+GtopXoygzekyLM+5gFAvIT5P+Q7+rFACR2gaVo5IeBuwdyUJjgIihZRvmiIWyVtyOz1P0koy9znx1eC7FMiDpzRtF80s9GzFxTMiER2Gbfyl9IauVq6FXubhFoQc8+mtVERWVxv0PsAqPw2Q89SOsw== x-ms-exchange-antispam-messagedata: ryHLSsB1MWT2Q9m21F/cu/XW1wBJbXSj9Som6/qlDzhL5XjD18BV8mcoef/sOE91CSOkU8rzm3wuFShZ//XESNuCFDF2Gjjzrg0qjnE6w1V/mvk4Yi7bCv3d3DuNifwkh4i1u596Buv+m90a1/hFag== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ebcddc6-fa21-49b5-1fde-08d7dbc47dd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 13:55:26.4630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ULm9bhi7eepcT37+q0iRWOOPdc67/ZcKYXJBbdzh2N4S8+zCZRiOuuT0cmL8tCVlCZPtnayl5n7jS84Xqpf1qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB1903 Archived-At: Subject: Re: [Idr] status - incremental 4/8/2020 - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 13:57:00 -0000 --_004_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_ Content-Type: multipart/alternative; boundary="_000_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_" --_000_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the Draft-hujun-idr-bgp-ipsec & draft-hujun-idr-bgp-ipsec-transport-mod= e waiting for WG adoption, I hope the authors can answer my questions (att= ached) which were sent last week. In particular: 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running be= tween IPsec peers? 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKE= v2 with the speaker without any configuration from the administer? If Node = B can only establish IPsec IKEv2 with another node C, does it matter if the= Node B receives or not receives the BGP update from the C? 2. How does the BGP UPDATE ease the IPsec configuration? Does it ease t= he configuration on the BGP UPDATE speaker? Or does it ease the configurati= on of the receiver? 3. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is = there still "Private Routing Instances"? 1. On Page 3, the draft states that only "Local Tunnel Endpoint address,= Public Routing Instance and CHILD SA traffic selector address range" are a= dvertised by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the no= de? Or can be a specific Ingress or egress port of the node sending out the= BGP UPDATE? Thank you very much. Linda Dunbar From: Idr On Behalf Of Susan Hares Sent: Wednesday, April 8, 2020 7:37 AM To: idr@ietf.org Subject: [Idr] status - incremental 4/8/2020 - IDR WG: A little status to read with your coffee this morning. We have an interim= at 13:00 UTC (9:00 EDT, 6:00 PDT, 21:00 Bejing time) Please let me know if I've missed any updates. Cheers, Sue --------- At IESG in IETF LC 1) draft-ietf-idr-rfc5575bis-19.txt - Shepherd: John Scudder Status: IETF LC ended, IESG telechat: 4/15 IESG Publication request: 7/9/2019 2 AD Reviews [8/2-9/10/2019, [1/17-1/23/2020] 2) draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt [Shepherd: Susan Hares] Status: 3rd round of AD revisions IESG Publication requested: 10/15/2019 IETF WG LC: 6 days -------------- AD review - authors need to respond 1) draft-ietf-idr-tunnel-encaps-14 - sent to IESG [Waiting 47 days] 2) draft-ietf-idr-capabilities-registry-change-05.txt [Waiting 57 days] ------------ WG past WG LC - stuck waiting for implementation reports on wiki [reported to have 2 implementations, but no details on wiki] 1) draft-ietf-idr-ext-opt-param 2) draft-idr-eag-distribution-09.txt --------- Drafts stuck post WG LC - waiting for minor edits 1) draft-ietf-idr-rfc8203bis.05.txt - ---- Flow specification drafts in WG LC 1) Draft-ietf-idr-flow-spec-v6-10.txt Status: restarted [4/8 to 4/22] Status: IESG desires, but is it ready? Needed: implementation reports 2) draft-ietf-idr-bgp-flowspec-oid-11 Status: 3/13/ to 4/13 Status: light response, please comment Authors: Please fill out implementation report ----------- WG Adoption calls: 1) Draft-hujun-idr-bgp-ipsec WG adoption: 3/30-4/13 Shepherd: Susan Hares Comment: only 1 response, heading toward "no consensus" 2) draft-hujun-idr-bgp-ipsec-transport-mode WG Adoption: 3/30 - 4/13 Shepherd: Susan Hares Comment: only 1 response, heading toward "no consensus" 3) draft-li-idr-sr-policy-path-mtu-03.txt WG adoption: 3/30 - 4/13 Shepherd: Susan Hares Comment: Positive response: Heading toward WG Adoption Request for input: ---------------------- draft-scharf-tcpm-yang-tcp-04 Proposed WG LC drafts for flow-specification that were on hold: ------------------------------------------- [Authors should contact chairs] 1) draft-ietf-idr-flowspec-interfaceset-05 - WG notes indicated this might go ahead without flow-specification v2 2) draft-ietf-idr-flowspec-path-redirect-10 - WG discussion needs to occur on whether flowspecification Proposed WG LCs (3/30 and 4/8) ---------------- 1) draft-ietf-idr-bgp-open-policy-08 - on hold pending revision -09 2) draft-ietf-idr-flowspec-l2vpn-13 - in slides for 4/8 Proposed Adoption calls ----------------------- draft-cl-idr-bgp-ext-com-registry-udpate-00.txt --_000_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the Draft-hujun-idr-bgp-ipsec & draft-hujun-= idr-bgp-ipsec-transport-mode waiting for WG adoption, I hope the authors ca= n  answer my questions (attached) which were sent last week. In partic= ular:

 

  1. Does  draft= -hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers= ?

 

  1. Does receiving the IPsec BGP UPDATE triggers a node to start the &nbs= p;IKEv2 with the speaker without any configuration from the administer? If = Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the = BGP update from the C?
  2. How does the BGP UPDATE ease the IPsec configuration?= Does  it ease the configuration on the BGP UPDATE speaker? Or does it= ease the configuration of the receiver?
  3. How to differentiate  Public Routing Instances? =  

If the payload packet wi= thin the IPsec tunnel are simple IP forwarding, is there still “Priva= te Routing Instances”?

 

  1. On Page 3, the draft states that only “Local Tunnel Endpoint ad= dress, Public Routing Instance and CHILD SA traffic selector address range&= #8221; are advertised by the BGP.

Is the Local Tunnel Endp= oint address same as the LOOPBACK address of the node? Or can be a specific= Ingress or egress port of the node sending out the BGP UPDATE?

 

 

Thank you very much.

 

Linda Dunbar

 

 

From: Idr <idr-bounces@ietf.org> On = Behalf Of Susan Hares
Sent: Wednesday, April 8, 2020 7:37 AM
To: idr@ietf.org
Subject: [Idr] status - incremental 4/8/2020 -

 

IDR WG:

 

A little status to rea= d with your coffee this morning.   We have an interim at 13:00 UT= C (9:00 EDT,  6:00 PDT, 21:00 Bejing time)

 

Please let me know if = I’ve missed any updates.

 

Cheers, Sue

 

---------

At IESG in IETF LC

1) draft-ietf-idr-rfc5575bis-19.txt &#= 8211;

    Shepherd: John= Scudder

    Status:  IETF = LC ended, IESG telechat: 4/15

    IESG Publicati= on request: 7/9/2019

   2  AD Reviews [= 8/2-9/10/2019, [1/17-1/23/2020]

   

2) draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt

     [Shepherd: Susan Hares]=

     Status:  3rd= round of AD revisions  

     IESG Publication reques= ted:  10/15/2019

     IETF WG= LC:  6 days  

 

--------------

AD review – authors need to respond

1) draft-ietf-= idr-tunnel-encaps-14 - sent to IESG

[Waiting 47 d= ays]

 

2) draft-ietf-idr-capabilities-registry-change-05.txt

[Waiting 57 days]

------------

WG past WG LC – stuck  waiting for implem= entation reports on wiki

[reported to have 2 implementations, but no details = on wiki]

 

1) draft-ietf-idr-ext-opt-param=

2) draft-idr-eag-distribution-09.txt

---------

Drafts stuck post WG LC – waiting for minor ed= its

1) draft-ietf-idr-rfc8203bis.05.tx= t  -

----

Flow specification drafts in WG LC

 

1) Draft-ietf-idr-flow-spec-v6-10.txt

   Status: restarted [4/8 to 4/22]

   Status: IESG desires, but is it ready?

   Needed:  implementation report= s

 

2) draft-ietf-idr-bgp-flowspec-oid-11

    Status:  3/13/ to 4/13 =

    Status: light response, plea= se comment

    Authors:  Please fill o= ut implementation report

 

-----------

WG Adoption calls:

 

   1) Draft-hujun-idr-bgp-ipsec<= /span>

       WG adoption:&nbs= p; 3/30-4/13

        Shepherd: = Susan Hares

        Comme= nt: only 1 response, heading toward “no consensus”

 

2) draft-hujun-idr-bgp-ipsec-transport-mode

     WG Adoption: 3/30 – 4/= 13

      Shepherd: Susan Hares

     Comment: only 1 respons= e, heading toward “no consensus”

 

3) draft-li-idr-sr-policy-path-mtu-03.txt

    WG adoption: 3/30 – 4/1= 3

     Shepherd: Susan Hares

    Comment: Positive response: H= eading toward WG Adoption

 

Request for input:

----------------------

draft-scharf-tcpm-yang-tcp-04

 

Proposed WG LC drafts for flow-specification that wer= e on hold:

-------------------------------------------

[Authors should contact chairs]

 

1)  draft-ietf-idr-flowspec-interfaceset-05 R= 11;

WG notes indicated this might go ahead without flow-s= pecification v2

 

2) draft-ietf-idr-flowspec-path-redirect-10 –

WG discussion needs to occur on whether flowspecifica= tion

 

 

Proposed WG LCs (3/30 and 4/8)

----------------

1) draft-ietf-idr-bgp-open-policy-08 – on hold = pending  revision -09

2)  draft-ietf-idr-flowspec-l2vpn-13 – in = slides for 4/8

 

 

Proposed Adoption calls  

-----------------------

draft-cl-idr-bgp-ext-com-registry-udpate-00.txt<= /o:p>

 

 

 

 

 

 

--_000_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_-- --_004_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 08 Apr 2020 13:55:25 GMT"; modification-date="Wed, 08 Apr 2020 13:55:25 GMT" From: Linda Dunbar To: Susan Hares , 'IDR List' Subject: Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Thread-Topic: Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Thread-Index: AdYJ88Fzwt+5o6y3SbatjJfErRQpEw== Date: Fri, 3 Apr 2020 20:24:09 +0000 Message-ID: Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ms-exchange-organization-originalclientipaddress: 2605:6000:1526:d41e:f8f2:b132:58a2:62db x-ms-exchange-organization-originalserveripaddress: 2603:10b6:301:34::35 x-ms-exchange-organization-submissionquotaskipped: False Content-Type: multipart/alternative; boundary="_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_" MIME-Version: 1.0 --_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jun, Need a few clarify questions for your draft. 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running be= tween IPsec peers? 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKE= v2 with the speaker without any configuration from the administer? If Node = B can only establish IPsec IKEv2 with another node C, does it matter if the= Node B receives or not receives the BGP update from the C? 2. How does the BGP UPDATE ease the IPsec configuration? Does it ease t= he configuration on the BGP UPDATE speaker? Or does it ease the configurati= on of the receiver? 3. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is = there still "Private Routing Instances"? 1. On Page 3, the draft states that only "Local Tunnel Endpoint address,= Public Routing Instance and CHILD SA traffic selector address range" are a= dvertised by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the no= de? Or can be a specific Ingress or egress port of the node sending out the= BGP UPDATE? Thank you very much. Linda Dunbar From: Idr On Behalf Of Susan Hares Sent: Monday, March 30, 2020 7:07 AM To: 'IDR List' Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and= draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 This begins a 2 week WG adoption call for two drafts BGP provisioned IPSEC= infrastructure 1) draft-hujun-idr-bgp-ipsec-02.txt: BGP Provisioned IPSEC Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/ 2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt: BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec-transport-mode/<= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=3D02= %7C01%7Clinda.dunbar%40futurewei.com%7Cdb1e68b21c294ff7e40f08d7d4a2e5e4%7C0= fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637211668440604245&sdata=3DXROXZN= 5YTy5GQEToYyAkFNHx71%2B%2FXnln1QJjMzeRQ6I%3D&reserved=3D0> These drafts were presented at IETF 104 and IETF 105. At IETF 105, there was a detailed discussion on the security issues. After IETF 105, the author modified his draft to take care of the Issues mentioned. Discussion during the WG Adoption should examine: 1) Has this draft addressed the necessary security issues to be adopted as IDR WG draft? 2) Is this useful generic IPSEC functionality for networks? The EVPN related to IPSEC continues in BESS. This draft is considered here as a general feature. 3) Are there any deployments of this draft? Stay safe and healthy... Sue --_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jun,

 

Need a few clarify questions for your draft.

 

  1. Does  draft= -hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers= ?

 

  1. Does receiving the IPsec BGP UPDATE triggers a node to start the &nbs= p;IKEv2 with the speaker without any configuration from the administer? If = Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the = BGP update from the C?
  2. How does the BGP UPDATE ease the IPsec configuration?= Does  it ease the configuration on the BGP UPDATE speaker? Or does it= ease the configuration of the receiver?
  3. How to differentiate  Public Routing Instances? =  

If the payload packet wi= thin the IPsec tunnel are simple IP forwarding, is there still “Priva= te Routing Instances”?

 

  1. On Page 3, the draft states that only “Local Tunnel Endpoint ad= dress, Public Routing Instance and CHILD SA traffic selector address range&= #8221; are advertised by the BGP.

Is the Local Tunnel Endp= oint address same as the LOOPBACK address of the node? Or can be a specific= Ingress or egress port of the node sending out the BGP UPDATE?

 

 

Thank you very much.

 

Linda Dunbar

 

From: Idr <idr-bounces@ietf.org> On = Behalf Of Susan Hares
Sent: Monday, March 30, 2020 7:07 AM
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.= txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020=

 

This begins a 2 week WG adoption call for  two = drafts BGP provisioned IPSEC infrastructure

 

1) draft-hujun-idr-bgp-ipsec-02.txt:

BGP Provisioned IPSEC Tunnel Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/<= o:p>

 

2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt:<= o:p>

BGP Provisioned IPsec Transport Mode Protected Tunne= l Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-= idr-bgp-ipsec-transport-mode/

 

These drafts were presented at IETF 104 and IETF 105= .

At IETF 105, there was a detailed discussion on the = security issues.

After IETF 105, the author modified his draft to tak= e care of the

Issues mentioned. 

 

Discussion during the WG Adoption should examine:

1) Has this draft addressed the necessary security i= ssues to

    be adopted as IDR WG draft?<= o:p>

 

2) Is this useful generic IPSEC functionality for ne= tworks?

 

   The EVPN related to IPSEC continue= s in BESS.

   This draft is considered here as a= general feature.

 

3) Are there any deployments of this draft?

 

 

Stay safe and healthy… Sue

 

--_000_MWHPR1301MB2096467F12809CB1041B467E85C70MWHPR1301MB2096_-- --_004_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_-- From nobody Wed Apr 8 07:03:51 2020 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 BCB2D3A0C5F for ; Wed, 8 Apr 2020 07:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 N6IzyN2rQKNe for ; Wed, 8 Apr 2020 07:03:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 36AB13A099B for ; Wed, 8 Apr 2020 07:03:45 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 038E349f042495; Wed, 8 Apr 2020 10:03:45 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 3091nuv7st-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Apr 2020 10:03:44 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038E3hat031553; Wed, 8 Apr 2020 10:03:43 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038E3a5q031351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2020 10:03:36 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 6E7C04009E66; Wed, 8 Apr 2020 14:03:36 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30484.vci.att.com (Service) with ESMTPS id 59D2B4009E65; Wed, 8 Apr 2020 14:03:36 +0000 (GMT) Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) by GAALPA1MSGHUBAD.ITServices.sbc.com (130.8.218.153) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 8 Apr 2020 10:03:35 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Apr 2020 10:03:35 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.1913.007; Wed, 8 Apr 2020 10:03:35 -0400 From: "UTTARO, JAMES" To: Susan Hares , "'IDR List'" Thread-Topic: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) Thread-Index: AdYGsjkGouveGy3sT42zRQgNbUUoFQG+68lg Date: Wed, 8 Apr 2020 14:03:35 +0000 Message-ID: <32e5358433ae47ee8c6217bc0f1a32fc@att.com> References: <00d101d606b2$7d036c50$770a44f0$@ndzh.com> In-Reply-To: <00d101d606b2$7d036c50$770a44f0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.132.73] Content-Type: multipart/alternative; boundary="_000_32e5358433ae47ee8c6217bc0f1a32fcattcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-07_10:2020-04-07, 2020-04-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 priorityscore=1501 mlxlogscore=999 impostorscore=0 phishscore=0 malwarescore=0 suspectscore=0 bulkscore=0 mlxscore=0 adultscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004080117 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 14:03:50 -0000 --_000_32e5358433ae47ee8c6217bc0f1a32fcattcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sue, Apologies I could not attend today's IDR meeting. As per our = conversation last week, AT&T has deployed the following services that dist= ribute flowspec updates/rules from a centralized controller that depend on = the flowspec-oid technology specification. Note these are all on demand. 1. Edge Blocking 2. DDOS Diversion 3. Traffic Rate Limiting Thanks, Jim Uttaro From: Idr On Behalf Of Susan Hares Sent: Monday, March 30, 2020 12:44 PM To: 'IDR List' Subject: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last = Call (3/30 to 4/13) This is a 2 week WG LC for draft-idr-bgp-flowspec-oid-1.txt. You may find the draft at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ Based on our discussion at the 3/30/2020 interim, Most Flow Specification implementations add this feature. 1) draft authors will send a response to this email with their IPR statemen= ts. 2) draft authors will update the IDR wiki page https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20imple= mentations 3) The WG will run a 2 week WG last call discussion During this discussion please indicate: a) What deployments you know about (3rd party information about an implementation is fine) b) Are there any issues with the implementations c) Is this specification ready for publication? Cheerily, Sue Hares --_000_32e5358433ae47ee8c6217bc0f1a32fcattcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Su= e,

 

&n= bsp;            = ; Apologies I could not attend today’s IDR meeting. As per our conver= sation last week,  AT&T has deployed the following services that d= istribute flowspec updates/rules from a centralized controller that depend on the flowspec-oid technology specification. Note = these are all on demand.

 

  1. Edge Blocking
  2. DDOS Diversion
  3. Traffic Rate Limiting=

 

Th= anks,

&n= bsp;            = ; Jim Uttaro

 

From: Idr <idr-bounces@ietf.org> On = Behalf Of Susan Hares
Sent: Monday, March 30, 2020 12:44 PM
To: 'IDR List' <idr@ietf.org>
Subject: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Grou= p Last Call (3/30 to 4/13)

 

This is a 2 week WG LC for  draft-idr-bgp-flows= pec-oid-1.txt.

You may find the draft at:

 

https://datatracker.ietf.or= g/doc/draft-ietf-idr-bgp-flowspec-oid/

 

Based on our discussion at the 3/30/2020 interim,

Most  Flow Specification implementations add th= is feature.

 

1) draft authors will send a response to this email = with their IPR statements.

2) draft authors will update the IDR wiki page =

 

https= ://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementa= tions

 

3) The WG will run a 2 week WG last call discussion =

 

During this discussion please indicate: <= /p>

 

a) What deployments you know about

  (3rd party information about = an implementation is fine)

 

b) Are there any issues with the implementations

 

c) Is this specification ready for publication?

 

Cheerily, Sue  Hares

 

 

--_000_32e5358433ae47ee8c6217bc0f1a32fcattcom_-- From nobody Wed Apr 8 07:07:50 2020 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 8ADF53A0CA4 for ; Wed, 8 Apr 2020 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 nfjYA36UU8hX for ; Wed, 8 Apr 2020 07:07:44 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 676273A0CA5 for ; Wed, 8 Apr 2020 07:07:44 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id v38so3665002qvf.6 for ; Wed, 08 Apr 2020 07:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Ess3x1nn24uESazm1YVUYg8ag3qie5qNB7/9dKCrjtY=; b=VdKFIYEaehgbcASM1PJzKcQZoiI/cBGLN4fAG/URsLe5jMnxT01IiQOd3+hGZzre6E iiGn7sUIAqoCx7jZmeKwImTp+Oymzty5ixM/hL536T9eRJnc27YLPR6EcHDqA/BKOHL8 umj2j3XCio75AWNfTnJZDPHSSAuy0zMGfbTiGB92q0MmqpaFt9UZo2GxI0hvC0gEtKfq J5I/fAmCpo2JbOpV91e0mqpyuBUYBIqj3yO6PSeHhSBRVAYC9byc9tqt0z+VFa9xOL6C giUniVWcfWUsKse0gEGP8DH61a1GmUGeaeyQCel4bR8Pssj5SdUbML+ecxXQD2lK+Mr5 x0Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Ess3x1nn24uESazm1YVUYg8ag3qie5qNB7/9dKCrjtY=; b=U9GbCy14D8VN8QjKlB5EorpCMBLWUcGMez37+Xj/3KlGXScP1bfFh8DWJA9s0kzFZA jI4oSlR9ORrMgm6IlOmnKKVqmsL5ChuTiuDq0eW+8+4A46DyDSliP0derqsShPI7ixwq 0NYUNfywywjYZy94+3Tt7R7mRg2djE/FbutGO/ISqS7RIOp6uOoKpfioFIijzSdC2afK zrvWZTYS/Xi5vs7jmKNWsG/rfpNbZ9oZCGex222n/0Uei4BfrasSQIm7ot5B5wYp7zWu i0iVsweJ7RFK5RXUsqUYVmZmvZ4zdVYosn+viWq+eQiyD5RAuzaJSQAxfZcExS6H27Ep BgUg== X-Gm-Message-State: AGi0PuYs1YITHTJpXYOXgXH+mixU8h3RMVTCbHCVa1CYJcp6gS7MD+Eb IzWVsSeWfbiBvFwZwQW4pl0Zuv8DdxMRWg== X-Google-Smtp-Source: APiQypKTXKho61oEGwDycxg9ZzZuRW8ZZ4E4jDha+ZCojPued1kc+1eQ0Dy6OtjhB9slv+hGSMQC1w== X-Received: by 2002:a0c:b905:: with SMTP id u5mr1142181qvf.125.1586354862890; Wed, 08 Apr 2020 07:07:42 -0700 (PDT) Received: from [192.168.1.241] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id h26sm629425qtp.93.2020.04.08.07.07.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 07:07:42 -0700 (PDT) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: multipart/alternative; boundary=Apple-Mail-375639F7-86E9-4646-A438-8094A208F3BE Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 10:07:41 -0400 Message-Id: <56156F31-7E95-4AC5-AF33-9EF9554CCC6F@gmail.com> References: <1C4FE3CA-DDF4-4736-9CD1-DE2296E73383@juniper.net> Cc: Hares Susan , "idr@ietf.org" In-Reply-To: <1C4FE3CA-DDF4-4736-9CD1-DE2296E73383@juniper.net> To: John Scudder X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [Idr] IDR second session - 4/8 13:00-15:00 UTC (9-11am EDT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 14:07:47 -0000 --Apple-Mail-375639F7-86E9-4646-A438-8094A208F3BE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you=20 I was able to call in but could not login to link since=20 I was prompted for password. Gyan Verizon Sent from my iPhone > On Apr 8, 2020, at 8:50 AM, John Scudder wrote: >=20 > =EF=BB=BF In case anyone needs the WebEx meeting number, it=E2=80=99s 647 9= 98 614 >=20 > =E2=80=94John >=20 >> On Apr 7, 2020, at 12:38 PM, Susan Hares wrote: >>=20 >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >> Our second interim is on Wednesday 4/8/2020. =20 >> =20 >> -------------------- >> WebEx: https://ietf.webex.com/webappng/sites/ietf/meeting/download/5FF4D3= 3B273CA952E0536284FC0AC72E >> Etherpad for note-taking: https://etherpad.ietf.org:9009/p/notes-ietf-int= erim-2020-idr-02?useMonospaceFont=3Dtrue >> =20 >> =20 >> Etherpad for virtual blue sheet:https://etherpad.ietf.org:9009/p/notes-ie= tf-107-idr-2-bluesheet >> jabber: idr@jabbert.ietf.org >> =20 >> =20 >> 1.Administrivia + Status 10 minutes >> Status: Feedback on interims =20 >> =20 >> 2. BGP YANG Model Status and Issues=20 >> Draft: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-08 >> =20 >> Presenter: Mahesh Jethanandani=20 >> Time period: 10 minutes =20 >> Chair=E2=80=99s questions for WG:=20 >> 1) Does it matter that this is only machine friendly?=20 >> 2) Are we ready for WG LC on this document?=20 >> =20 >> 3. Presentations =E2=80=93 new drafts or status updates >> 1) Flowspec for L2 and Tunneled Traffic >> Draft: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13 >> https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-08 >> Presenter: Donald Eastlake >> Time period: 20 minutes >> =20 >> Chair=E2=80=99s questions for WG/presenters:=20 >> 1) Are there implementations of draft-ietf-idr-flowspec-l2vpn-13.txt? >> 2) Are we ready for WG LC=20 >> 3) Is the revision draft-idr-flowspec-nv03-08.txt ready for early allocat= ion? >> =20 >> 2) BGP Well-known Large Communities >> Draft: https://tools.ietf.org/html/draft-heitz-idr-wklc-00 >> Presenter: Jakob Heitz >> Time period: 10 minutes >> =20 >> 4) BGP communities =E2=80=93 Research into Worms=20 >> Paper: https://archive.psg.com/181101.imc-communities.pdf >> Presenter: Randy Bush >> =20 >> 4) Large Discussion time: 15 minutes=20 >> 1) What are the operator needs?=20 >> 2) What about the issues raised BGP researcher? =20 >> =20 >> 5) BGP Extended Community Registries Update >> Draft: https://tools.ietf.org/html/draft-cl-idr-bgp-ext-com-registry-upda= te-00 >> Presenter: Christoph Loibl >> Time period: 10 minutes >> Question for WG: Should we adopt?=20 >> =20 >> 6) Open mic time=20 >> =20 >> Total time: ~1:15 minutes >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!= !NEt6yMaO-gk!Tw5vJvcG11G96WTJ-a2oQzh_p5qxQFyky5qQBbyu1pjYhg0LdyLcv1ZrEcvQfA$= >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-375639F7-86E9-4646-A438-8094A208F3BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thank you 

I was able to call in but could not login to link since 
I was prompted for password.

Gyan
Veri= zon

Sent from my iPhone

On Apr 8, 2020, at 8:50 AM, John Scudder <jgs=3D4= 0juniper.net@dmarc.ietf.org> wrote:

=EF=BB=BF In case anyone needs the WebEx meeting number, it=E2=80=99s 647 998 614
<= span style=3D"caret-color: rgb(31, 31, 31);" class=3D"">
=E2= =80=94John

On Apr 7, 2020, at 12:38 PM, Susan Hares <shares@ndzh.com> wrote:


[External Email. B= e cautious of content]


Our second interim is on Wednesday 4/8/2020.  
 
--------------------
WebEx: https://ietf.webex.com/webappng/sites/ietf/mee= ting/download/5FF4D33B273CA952E0536284FC0AC72E
Etherpad for note-taking: = https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-idr-02?= useMonospaceFont=3Dtrue
 
 
Etherpad for virtual blue sheet:https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-2-bl= uesheet
jabber:  idr@jabbert= .ietf.org
 
 
1.Administrivia + Status 10 minutes
  Status: Feedback on interims  
 
2. BGP YANG Model Status and Issues&nb= sp;
Draft: https:/= /tools.ietf.org/html/draft-ietf-idr-bgp-model-08
 
Presenter: Mahesh Jethanandani 
Time period: 10 minutes  
Chair=E2=80=99s questions for WG: = ;
1) Does it matter that this is only machine friendly? 
2) Are we ready for WG LC on this document? 
 
3. Presentations =E2=80=93 new drafts or status updates
1)      Flowspec for L2 and Tunneled Traffic
Draft: ht= tps://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13
        https://tools.ietf.org/html/draft-ietf-idr-= flowspec-nvo3-08
Presenter: Donald Eastlake
Time period: 20 minutes
 
Chair=E2=80=99s questions for WG/presenters: 
1) Are there implementations of draft-ietf-idr-flowspec-l2vpn-13.txt?
2) Are we ready for WG LC =
3) Is the revision draft-idr-flowspec-nv03-08.txt ready for early allocation= ?
 
2)      BGP Well-known Large Communities
Draft: https://tools.ietf.org/html/draft-heitz-idr= -wklc-00
Presenter: Jakob Heitz
Time period: 10 minutes
 
4)  BGP communities =E2=80=93 Research into Worms 
 Paper: https:= //archive.psg.com/181101.imc-communities.pdf
=
Presenter:  Randy Bush
 
4) Large Discussion time: 15 minutes&n= bsp;
1) What are the operator needs? <= /span>
2) What about the issues raised BGP researcher?  =
 
5)      BGP Extended Community Registries Update
Draft: https://tools.ietf.org/= html/draft-cl-idr-bgp-ext-com-registry-update-00
Presenter: Christoph Loibl
Time period: 10 minutes
Question for WG:  Should we adopt? 
 
6) Open mic time 
 
Total time: ~1:15 minutes
_______________________________________________
Idr mailing list
Idr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/l= istinfo/idr__;!!NEt6yMaO-gk!Tw5vJvcG11G96WTJ-a2oQzh_p5qxQFyky5qQBbyu1pjYhg0L= dyLcv1ZrEcvQfA$

_______________________________________________
Idr ma= iling list
Idr@ietf.org
https://www.ietf.org= /mailman/listinfo/idr
= --Apple-Mail-375639F7-86E9-4646-A438-8094A208F3BE-- From nobody Wed Apr 8 07:41:58 2020 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 BBD573A0DB1 for ; Wed, 8 Apr 2020 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTXm0Fn3se-I for ; Wed, 8 Apr 2020 07:41:54 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 5DFD53A0C94 for ; Wed, 8 Apr 2020 07:41:27 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id q204so114783oia.13 for ; Wed, 08 Apr 2020 07:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=UUw8Vqww9hVqyl/+RYvtotF8EgiPdziEe1wOsMzUSgg=; b=BUJke7L0QR5x/gjFj96UJlr5tFdWVyrp7SpHiuSaaGBFThhsBp8dYYBfKs6dgrPORs nsbLgoD23/E7+38dvPeyKQGfzJ1Lh0GtLEqBTkzF89Wz/wYLvJqtO2oUSodwpRv9/y0C lcng0DchTs5vkrFF1LWr6N0BVlGaeSHmVjgsYlRAm2hQVUnuyQ4KrVMYewU/z/SoCgaI dKcyp7CRsntAbfwJDfaLdHuqXxs5m+upN752fNYebDCcxxX6Y9Rhkp5W6JYtN/HZs300 Mwbocgg3DPiKhVwpoUpHFbdaV3PtWLxfcZyXlFpbYRuek+HU1zcuTh5/hv7fLxF0iP8u M4xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=UUw8Vqww9hVqyl/+RYvtotF8EgiPdziEe1wOsMzUSgg=; b=jL/2eN+k0d4nLnPRa331JpYKa4JnfWyMGNxjRNhsrKOWjii5fz+4Z/5A7fVK13HUFr qAGKnbYlsMScXyPC/+5BnB53D10JJ1mz/SH4SN8jCQXtzj+F3ZsxNaja67rOIPI/1KWf +Gg5rusEFe7qYXUufmKZb85msJ+YXSSM+sy1u44SAxgr51wnK8FfPK9XF+CAwYw/SDEm dVDBmsI67QxzhVA9NT60rqL5J6iKNFefZuKkjj3w0o6ZOAJEpPCLxGIwPED0Y0Q/EWJd ov+A4wdCDeObEUt2w7r/phfTkK0ZNT0Grv6+se429fku3dE2ghAF17BWml1YfkcMToSI m3bA== X-Gm-Message-State: AGi0PuZMM+s3xayqs9CMFi0Dw1wei24s/vUQ4x5TXobw0mrN+PbEoppx Lrq6phuAHNN5zOBgYFiibGNIFJJ3xFIi0rTdNtqZ3w== X-Google-Smtp-Source: APiQypIyGyPM9e/YbB5uNCsmNaCzU9Z7PYtw75jjMM0k5kQjZATt+14Eem/x04N4BBzdZRBhHve3Mot5mFXvWtzotOY= X-Received: by 2002:aca:5041:: with SMTP id e62mr2582692oib.146.1586356883990; Wed, 08 Apr 2020 07:41:23 -0700 (PDT) MIME-Version: 1.0 From: Robert Raszuk Date: Wed, 8 Apr 2020 16:41:12 +0200 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "idr@ietf. org" Content-Type: multipart/alternative; boundary="0000000000008ebc8005a2c87eab" Archived-At: Subject: [Idr] XXCs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 14:41:56 -0000 --0000000000008ebc8005a2c87eab Content-Type: text/plain; charset="UTF-8" Hey Jakob, So just an idea - if we are to redefine transitivity for XXC why don't we forget about all of this ASN reservations and simply instead of two transitive bits define three. Make 3rd bit to mean transitive only under set of ASes under same administrative control ? You still need a knob to know which ASNs are to be treated as same administration. And with that no change to community syntax is needed at all - LOCAL_ASN:NUMBER Done ! Thx, R. --0000000000008ebc8005a2c87eab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Jakob,=C2=A0

So just an = idea - if we are to redefine transitivity for XXC why don't we forget a= bout all of this ASN reservations and simply instead of two transitive bits= define three.=C2=A0

Make 3rd bit to mean tran= sitive only under set=C2=A0of=C2=A0ASes=C2=A0under same administrative=C2= =A0control ?=C2=A0

You still need a knob to know w= hich ASNs are to be treated as same administration. And with that no change= to community syntax=C2=A0 is needed at all - LOCAL_ASN:NUMBER
Done !=C2=A0

Thx,
R.
<= div>



--0000000000008ebc8005a2c87eab-- From nobody Wed Apr 8 07:53:41 2020 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 80FA33A0E09; Wed, 8 Apr 2020 07:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_6ni8IDNmF6; Wed, 8 Apr 2020 07:53:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 97CC83A0EB9; Wed, 8 Apr 2020 07:53:20 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 038EqIgE028917; Wed, 8 Apr 2020 10:53:19 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 3091nx4w1v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Apr 2020 10:53:19 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038ErF9h007091; Wed, 8 Apr 2020 10:53:18 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038Er9Bg006912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2020 10:53:09 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 7D9B94009E92; Wed, 8 Apr 2020 14:53:09 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30487.vci.att.com (Service) with ESMTPS id 66D6040002AB; Wed, 8 Apr 2020 14:53:09 +0000 (GMT) Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) by GAALPA1MSGHUBAF.ITServices.sbc.com (130.8.218.155) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 8 Apr 2020 10:53:08 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Apr 2020 10:53:08 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.1913.007; Wed, 8 Apr 2020 10:53:08 -0400 From: "UTTARO, JAMES" To: Robert Raszuk , "Jakob Heitz (jheitz)" CC: "idr@ietf. org" , BESS Thread-Topic: [Idr] XXCs Thread-Index: AQHWDbPmin7NOrnJA0mevIT3SnuJCahvTTiA Date: Wed, 8 Apr 2020 14:53:08 +0000 Message-ID: <1ab5b013e630448583d2e55179fa5c8c@att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.132.73] Content-Type: multipart/alternative; boundary="_000_1ab5b013e630448583d2e55179fa5c8cattcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-07_10:2020-04-07, 2020-04-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 suspectscore=0 spamscore=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 mlxlogscore=875 adultscore=0 bulkscore=0 clxscore=1011 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004080122 Archived-At: Subject: Re: [Idr] XXCs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 14:53:40 -0000 --_000_1ab5b013e630448583d2e55179fa5c8cattcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHN1cmUgaWYgdGhlIGludGVudGlvbiBoZXJlIGludGVyc2VjdHMgd2l0aCB3aGF0IEkgaGFk IGluIG1pbmQgaW4gMjAxMi4uIFByYWRvc2gsIFNhaWthdCBhbmQgSSBjcmVhdGVkIGEgZHJhZnQg dGhhdCBpbnRyb2R1Y2VkIHRoZSBub3Rpb24gb2YgT0FEICggT25lIEFkbWluaXN0cmF0aXZlIERv bWFpbiApLiBUaGUgY2hhbGxlbmdlIGZyb20gbXkgcG9pbnQgb2YgdmlldyB3YXMgYW5kIHN0aWxs IGlzIGhvdyB0byB0cmVhdCBub24tdHJhbnNpdGl2ZSBhdHRyaWJ1dGVzIGFzIHRyYW5zaXRpdmUg YWNyb3NzIHRoZSBzZXQgb2YgQVMgZG9tYWlucyB0aGF0IOKAnGJlbG9uZ+KAnSB0byB0aGUgc2Ft ZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4uIEFuIGV4YW1wbGUgb2YgdGhpcyBpcyB0aGUgYXBwbGlj YXRpb24gb2YgTG9jYWwtUHJlZiBhY3Jvc3MgYSBzZXQgb2YgZGlzcGFyYXRlIEFzIGRvbWFpbnMg dGhhdCBhIGN1c3RvbWVycyBWUE4gc3BhbnMuDQoNCldlIGFyZSB0YWNrbGluZyBhIHNpbWlsYXIg cHJvYmxlbSB3aGVuIHNwYW5uaW5nIEFTIGRvbWFpbnMgdGhhdCBhcmUgcmVmbGVjdGl2ZSBvZiBk aWZmZXJpbmcgc2VydmljZXMuLiBpLmUgIGEgY3VzdG9tZXIgVlBOIHNwYW5zIEVWUE4gYW5kIDI1 NDcgc2lnbmFsaW5nIGRvbWFpbnMuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC11dHRhcm8taWRyLW9hZC0wMQ0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1iZXNzLWV2cG4taXB2cG4taW50ZXJ3b3JraW5nLTAyDQoNClRoYW5rcywNCiAgICAgICAg ICAgICAgSmltIFV0dGFybw0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAyMCAx MDo0MSBBTQ0KVG86IEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPg0KQ2M6 IGlkckBpZXRmLiBvcmcgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFtJZHJdIFhYQ3MNCg0KSGV5 IEpha29iLA0KDQpTbyBqdXN0IGFuIGlkZWEgLSBpZiB3ZSBhcmUgdG8gcmVkZWZpbmUgdHJhbnNp dGl2aXR5IGZvciBYWEMgd2h5IGRvbid0IHdlIGZvcmdldCBhYm91dCBhbGwgb2YgdGhpcyBBU04g cmVzZXJ2YXRpb25zIGFuZCBzaW1wbHkgaW5zdGVhZCBvZiB0d28gdHJhbnNpdGl2ZSBiaXRzIGRl ZmluZSB0aHJlZS4NCg0KTWFrZSAzcmQgYml0IHRvIG1lYW4gdHJhbnNpdGl2ZSBvbmx5IHVuZGVy IHNldCBvZiBBU2VzIHVuZGVyIHNhbWUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCA/DQoNCllvdSBz dGlsbCBuZWVkIGEga25vYiB0byBrbm93IHdoaWNoIEFTTnMgYXJlIHRvIGJlIHRyZWF0ZWQgYXMg c2FtZSBhZG1pbmlzdHJhdGlvbi4gQW5kIHdpdGggdGhhdCBubyBjaGFuZ2UgdG8gY29tbXVuaXR5 IHN5bnRheCAgaXMgbmVlZGVkIGF0IGFsbCAtIExPQ0FMX0FTTjpOVU1CRVINCg0KRG9uZSAhDQoN ClRoeCwNClIuDQoNCg0KDQoNCg== --_000_1ab5b013e630448583d2e55179fa5c8cattcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojNzAzMEEwOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7DQoJZm9udC1z dHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjoj NzAzMEEwIj5Ob3Qgc3VyZSBpZiB0aGUgaW50ZW50aW9uIGhlcmUgaW50ZXJzZWN0cyB3aXRoIHdo YXQgSSBoYWQgaW4gbWluZCBpbiAyMDEyLi4gUHJhZG9zaCwgU2Fpa2F0IGFuZCBJIGNyZWF0ZWQg YSBkcmFmdCB0aGF0IGludHJvZHVjZWQgdGhlIG5vdGlvbiBvZiBPQUQgKCBPbmUgQWRtaW5pc3Ry YXRpdmUgRG9tYWluICkuIFRoZSBjaGFsbGVuZ2UNCiBmcm9tIG15IHBvaW50IG9mIHZpZXcgd2Fz IGFuZCBzdGlsbCBpcyBob3cgdG8gdHJlYXQgbm9uLXRyYW5zaXRpdmUgYXR0cmlidXRlcyBhcyB0 cmFuc2l0aXZlIGFjcm9zcyB0aGUgc2V0IG9mIEFTIGRvbWFpbnMgdGhhdCDigJxiZWxvbmfigJ0g dG8gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLiBBbiBleGFtcGxlIG9mIHRoaXMgaXMg dGhlIGFwcGxpY2F0aW9uIG9mIExvY2FsLVByZWYgYWNyb3NzIGEgc2V0IG9mIGRpc3BhcmF0ZSBB cyBkb21haW5zDQogdGhhdCBhIGN1c3RvbWVycyBWUE4gc3BhbnMuPG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjojNzAzMEEwIj5XZSBhcmUgdGFja2xpbmcgYSBzaW1pbGFyIHByb2JsZW0gd2hlbiBzcGFubmlu ZyBBUyBkb21haW5zIHRoYXQgYXJlIHJlZmxlY3RpdmUgb2YgZGlmZmVyaW5nIHNlcnZpY2VzLi4g aS5lICZuYnNwO2EgY3VzdG9tZXIgVlBOIHNwYW5zIEVWUE4gYW5kIDI1NDcgc2lnbmFsaW5nIGRv bWFpbnMuPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNzAzMEEwIj48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtdXR0YXJvLWlkci1vYWQtMDEiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC11dHRhcm8taWRyLW9hZC0wMTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6IzcwMzBBMCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtYmVzcy1ldnBuLWlwdnBuLWludGVyd29ya2luZy0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmVzcy1ldnBuLWlwdnBuLWludGVyd29ya2luZy0wMjwvYT4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjojNzAzMEEwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSmltIFV0dGFybzxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElkciAmbHQ7aWRyLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpSb2JlcnQgUmFzenVrPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMDgsIDIwMjAgMTA6NDEgQU08YnI+DQo8 Yj5Ubzo8L2I+IEpha29iIEhlaXR6IChqaGVpdHopICZsdDtqaGVpdHpAY2lzY28uY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gaWRyQGlldGYuIG9yZyAmbHQ7aWRyQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBbSWRyXSBYWENzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGV5IEpha29iLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBqdXN0IGFuIGlkZWEgLSBpZiB3ZSBhcmUgdG8gcmVkZWZp bmUgdHJhbnNpdGl2aXR5IGZvciBYWEMgd2h5IGRvbid0IHdlIGZvcmdldCBhYm91dCBhbGwgb2Yg dGhpcyBBU04gcmVzZXJ2YXRpb25zIGFuZCBzaW1wbHkgaW5zdGVhZCBvZiB0d28gdHJhbnNpdGl2 ZSBiaXRzIGRlZmluZSB0aHJlZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFrZSAzcmQgYml0IHRvIG1lYW4gdHJhbnNpdGl2ZSBv bmx5IHVuZGVyIHNldCZuYnNwO29mJm5ic3A7QVNlcyZuYnNwO3VuZGVyIHNhbWUgYWRtaW5pc3Ry YXRpdmUmbmJzcDtjb250cm9sID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IHN0aWxsIG5lZWQgYSBrbm9iIHRvIGtub3cgd2hp Y2ggQVNOcyBhcmUgdG8gYmUgdHJlYXRlZCBhcyBzYW1lIGFkbWluaXN0cmF0aW9uLiBBbmQgd2l0 aCB0aGF0IG5vIGNoYW5nZSB0byBjb21tdW5pdHkgc3ludGF4Jm5ic3A7IGlzIG5lZWRlZCBhdCBh bGwgLSBMT0NBTF9BU046TlVNQkVSPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkRvbmUgISZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaHgsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1ab5b013e630448583d2e55179fa5c8cattcom_-- From nobody Wed Apr 8 08:07:54 2020 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 447B73A0E84 for ; Wed, 8 Apr 2020 08:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfSqwZ_hNSTf for ; Wed, 8 Apr 2020 08:07:46 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::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 A8EB43A0E25 for ; Wed, 8 Apr 2020 08:07:28 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id a7so214510oid.7 for ; Wed, 08 Apr 2020 08:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YYXr3+3cLeraZNykdmjHCUp3f9kk/twwXITO+5QH48A=; b=QHD/7QrsYdlbitmO/bbI1Z2+oPI+MaWpK+EqT1h4wEu8LjLRYTPRVCqliCAjZySAai Qo7Pb7h5P9XFGasuvo5U6CdMlT1gfoxhTjq5MVPSOB/B13IbNquVGT7pYGwx29KpeH1h Y63OKKxO6IthxDw8S4fzF6JZxPT06N+YCn7IQC4Otg+FTalbnVnFP26vTLGA0Zyf7OGu y4jyvnmost7ZRI5nYoLpKbzP0WUsHsd9vkzf4xmt4b4KIgxPToW76iqQ/RQMMxjFLsZ1 xjhPibMoBpg/MqsoddQ6XDwM/cqhqSRIZnLOHNb0vbF9XB1F2sW7fLtxqaW+SP6w5nGi 7RjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YYXr3+3cLeraZNykdmjHCUp3f9kk/twwXITO+5QH48A=; b=ErxOoFbDqG1O2pODnYfTx+afuTsDBnPYiZnim6KIlIgc2ZRua7PDRJ7beGfsOjBZgG Wj4eTeUgzovBCfTjZpCjHRNh1uSzJ0WEdIlCkjeCwT2mI5Ibsyno7U4XMHMj86oyZYl7 xT3LG49KsGcNf61K7ma36lY83/AcCajVsr3i/ZhmMldR62nExmTwcxwTEPgBf4u6B8G1 AplBcwY1l/jxqsouB4co0es/vnaLB2Ji8nOPHXDMVHGXVfbfGJjab5/967O8o+4ODUve vFLaRszc4eTgbYsQzzAsUerJrz+T5Peunuwg5enKb2o9gCk0tDH4x3Wxyv+F3Rknrn4J O8mw== X-Gm-Message-State: AGi0Pua/OrSdeee6zaL502PRisaoJ2sVISyZwgQgIUXb5V1PPb1bDvA7 WNE1IrUKsi99G3Sv49bWkYSHzgz3owy4Jj0NiS+3Gw== X-Google-Smtp-Source: APiQypKmUnjcK6XCqMcCuJ5OpgeB4BqW/3NWA2ogG+lIn/5EIZ6PYfAiQCrq+BWkQurNIkeoacz2gB/ITNS2v9sW5lk= X-Received: by 2002:a05:6808:4e:: with SMTP id v14mr2808870oic.70.1586358445624; Wed, 08 Apr 2020 08:07:25 -0700 (PDT) MIME-Version: 1.0 References: <1ab5b013e630448583d2e55179fa5c8c@att.com> In-Reply-To: <1ab5b013e630448583d2e55179fa5c8c@att.com> From: Robert Raszuk Date: Wed, 8 Apr 2020 17:07:14 +0200 Message-ID: To: "UTTARO, JAMES" Cc: "Jakob Heitz (jheitz)" , "idr@ietf. org" , BESS Content-Type: multipart/alternative; boundary="000000000000a3634905a2c8db14" Archived-At: Subject: Re: [Idr] XXCs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 15:07:51 -0000 --000000000000a3634905a2c8db14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jim, Yes the topic is related to how multiple ASes under one administrative umbrella can operate BGP. But I must say that there are two fundamental approaches: a) the one as you described in the OAD draft defining the ATTR_SET_STACK attribute - sort of being an Eiffle Tower of what needs to be carried across. b) the other option is to decouple the problem into two sub functions: b.1 - make those ASNs operating under same administration aware of each other by cfg b.2 - make new transitive rule to allow passing under same administration. I just proposed b. Jakob proposed c) which is yet one more option to define set of reserved values (could be ASN or a prefix for easy ACL) to indicate within given attribute the scope of propagation when ingress policy allows. I find it much more complex and error prone as compared with (b) Thx, R. On Wed, Apr 8, 2020 at 4:53 PM UTTARO, JAMES wrote: > *Not sure if the intention here intersects with what I had in mind in > 2012.. Pradosh, Saikat and I created a draft that introduced the notion o= f > OAD ( One Administrative Domain ). The challenge from my point of view wa= s > and still is how to treat non-transitive attributes as transitive across > the set of AS domains that =E2=80=9Cbelong=E2=80=9D to the same administr= ative domain. An > example of this is the application of Local-Pref across a set of disparat= e > As domains that a customers VPN spans.* > > > > *We are tackling a similar problem when spanning AS domains that are > reflective of differing services.. i.e a customer VPN spans EVPN and 254= 7 > signaling domains.* > > > > *https://tools.ietf.org/html/draft-uttaro-idr-oad-01 > * > > > > *https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02 > = * > > > > *Thanks,* > > * Jim Uttaro* > > > > *From:* Idr *On Behalf Of * Robert Raszuk > *Sent:* Wednesday, April 08, 2020 10:41 AM > *To:* Jakob Heitz (jheitz) > *Cc:* idr@ietf. org > *Subject:* [Idr] XXCs > > > > Hey Jakob, > > > > So just an idea - if we are to redefine transitivity for XXC why don't we > forget about all of this ASN reservations and simply instead of two > transitive bits define three. > > > > Make 3rd bit to mean transitive only under set of ASes under same > administrative control ? > > > > You still need a knob to know which ASNs are to be treated as same > administration. And with that no change to community syntax is needed at > all - LOCAL_ASN:NUMBER > > > > Done ! > > > > Thx, > > R. > > > > > > > > > --000000000000a3634905a2c8db14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000074c94305a356f20d-- From nobody Wed Apr 15 11:36:46 2020 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 7B2253A002E; Wed, 15 Apr 2020 11:36:06 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158697576643.1557.921213587774121082@ietfa.amsl.com> Date: Wed, 15 Apr 2020 11:36:06 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-capabilities-registry-change-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 18:36:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Revision to Capability Codes Registration Procedures Author : John Scudder Filename : draft-ietf-idr-capabilities-registry-change-07.txt Pages : 5 Date : 2020-04-15 Abstract: This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Reserved for Private Use" is divided into three new ranges, respectively designated as "First Come First Served", "Experimental Use" and "Reserved". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-capabilities-registry-change-07 https://datatracker.ietf.org/doc/html/draft-ietf-idr-capabilities-registry-change-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-capabilities-registry-change-07 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 Apr 15 11:37:24 2020 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 9A7B23A0128; Wed, 15 Apr 2020 11:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=1PlYTiJh; dkim=pass (1024-bit key) header.d=juniper.net header.b=fI88xGue 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 NFM2en982zyD; Wed, 15 Apr 2020 11:36:24 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4463A041E; Wed, 15 Apr 2020 11:36:23 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03FIXNn0026092; Wed, 15 Apr 2020 11:36:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=Qos7X3Pd6e3a10bqMZdFtoJTXfydXAikrPwLfZ35u0k=; b=1PlYTiJhZ0YaW+PvDFTQUrIn4OkfxYdO3+XA4eiGxeJf8zUxEgK2CD0Lnsjk6pmqH2pX bea7wkE2zQM/VZTpC003AU2D6fRNZhI0So+8Odo749Zy4tQv2Ygj08T6P9IVImHNrGtP CBDQ82tDCfNsYizQFPCmHazy3DlIQ8g1IINycQ/gLh7n3cDKNn/+xbJLuptDNrNWpBmN 7ybEnxq3kHcfzGIQbbfgVNqu3fGRnAJe/0uUWzo49vDeSKflwBKGxIyLnR4zouZxN26n Y6qDBb2fLgbAnH0W522I75GB9nEye9zvrKjIC2epagDcfNSWku1RzKspw5oOy624Hee/ 2Q== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by mx0b-00273201.pphosted.com with ESMTP id 30dnb4sny0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Apr 2020 11:36:21 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PnBOwc41wvbtKTH2dFvjU5BcMd3JKdhxxTiKZxrti3o1LLxVyeLru2WFd8dOOZLzuY85Ll7qXtRcRzKXkeEweie/g6O6Li8rW/m9JbdmmzVtLreg0XTcwhjJfhqrOsTzpQrgJMf0iR/bPOqvcHiCHn9WSW8JnpgVEMWQAI4NkLdHoxgG1XKUJmw3arqbUcdhzy1yCbbutngEAi65kf1U5UDZ/mvCDiEu+bumEvGEBfC+9O0rOQB7Hch1o+icDHJi5YR7KVkyBCLo4PoPuNy1FUVQYQmGhySe7CxMQO44nnMePgEAdWTWgGNNNwcM8EQ4CmYX3bn6Nc+Ah64Vas2aRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qos7X3Pd6e3a10bqMZdFtoJTXfydXAikrPwLfZ35u0k=; b=lVsBF4tRkgNRN1KxWTvu8R6oiznIVDBeVKEUt+mu9LgRyVjVgjAISsy7nrAEJOciXJFkpyuYb6PuJtgLis4SAoLE5/hJhCp+j+uFu85zyrjYu4GhW17UCInO0YFZ4vNoKVQA0dxTdYqzjC+ArCTfA+vOK9ptfnhVzPVfLDEBmZ9diAeBNtysRailbkqcBtFrxVD1xoMoOlfmNqYfLrZmb7ylpO/tXrSFRoWOJ3469vWmEHZiRt6JYPwuysroDFS1tHik2ex4CGNqLAA5dZ3vPxgS4RAAVpGmDlNGCY+4vlvgkenmvi84e/vD/rF92F2YzlRE48gAJRjOYgO/Rci9DA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qos7X3Pd6e3a10bqMZdFtoJTXfydXAikrPwLfZ35u0k=; b=fI88xGueCTxRpSJjx6+laa5hJ95vmS1LXyyEPkt0/GLAh3JmPmcRUsf4vm6HkE8JiQxbZqHS756ne+kDmr5F+VWKFlqafRUFcR/FnZp3uUIOsk1WRy+Q1WWe0vUruCUSh5vs/DH3bzAeMEOtweEIYZQVyVzfBVNEdVoiDxix1S0= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB4865.namprd05.prod.outlook.com (2603:10b6:208:5d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.18; Wed, 15 Apr 2020 18:36:20 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 18:36:20 +0000 From: John Scudder To: Alvaro Retana CC: "draft-ietf-idr-capabilities-registry-change@ietf.org" , Hares Susan , idr-chairs , "idr@ietf. org" Thread-Topic: AD Review of draft-ietf-idr-capabilities-registry-change-06 Thread-Index: AQHV4PjML2ieUG5u9kyBFXTim0B1u6h6542A Date: Wed, 15 Apr 2020 18:36:19 +0000 Message-ID: <2593C5E1-0F7D-4B2C-9535-981052B2B06E@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-originating-ip: [2600:1700:37a0:3ca0:e133:e45c:a238:c10d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 90438568-ac01-4070-52eb-08d7e16be423 x-ms-traffictypediagnostic: BL0PR05MB4865: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(366004)(346002)(396003)(136003)(39860400002)(376002)(2616005)(86362001)(316002)(91956017)(53546011)(6512007)(8676002)(4326008)(6506007)(81156014)(8936002)(478600001)(66946007)(76116006)(186003)(6916009)(6486002)(33656002)(36756003)(2906002)(71200400001)(5660300002)(66476007)(66556008)(54906003)(64756008)(966005)(66446008); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pvPTW+cicNXAxb2ov+B+6Zbln8RqDxyRWp4ZaH5r0uNjLqm3wt1rZ2U0JvEU5Xy5fRGsCd24TYqs+2fMb/Fs/Nd+VJCgkMwVhrbR9owfFCrHwHynC3qUHbpzajFsV7yzwQA9pFEOHHW79gqYhyKKsu5pgpAAjBZPD7PsY2r3exF4ZTshB3RpKAvmwhd+dJWauL88KRBDjD+ggKiwH5yFRK8XxmY8pzK9cX9Dd7mMXsic9iGLgj26zBJFboPv5wKYvlwyeCEFkuB2g2R6aoy6ZlYEnPSdhYeTItgyn8QI8lZCKxfwXK465E3JDPDqEXEhoUyEmF9bSrTUzSJZr3AxgR2n9Q7PPbxw62+OlzVoBQZID9wOvqrVsACn5RVP/T8Gj5VVo5AN4CAsM/qVoHkq8bP5Rg5gblGE1TbZdusRRScQ/ZXWs+lm8Wm8EeftvcVe6qIzHZvQVGEAfI2o6cSMgIz6LHJpGONlabZwHmXNm6UTUJVg4c6Peq0+pRkp5L6JEMRQ827s9kiIDxUU1pnU6w== x-ms-exchange-antispam-messagedata: 2HkkEKh/06mLpXjKEsiKv0v4eS6zc3fNLPsND2WibKb4/sxKSkSipsac+AgsxjC9gPEF29OAloVCA8L9OShcrxjBrpXBvGS1tbftXAEXVtj3ur14S3EPc5nAUpXhE9snQs54YK5tIR9EoNYuWLSt/bnMhGaN1OlRcbk6KYFYPLJD47UPthTByzxdF+sFeRTjjxaJAZgnF8/rp04WvwuDlw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <00DDE3459A8BEE4BAA37F71FF56DBAD2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 90438568-ac01-4070-52eb-08d7e16be423 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 18:36:19.9955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zAS/gyJLEfUrDd7pMYRaUCWEXIZZcWEp6DoYLehPDAwZs15C5CbETgjrk3bVLfTZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4865 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-15_06:2020-04-14, 2020-04-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 spamscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 clxscore=1011 malwarescore=0 impostorscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004150136 Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-capabilities-registry-change-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 18:36:34 -0000 SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXchIEnigJl2ZSB1cGxvYWRlZCAtMDcg dG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRzLiBTb21lIHJlcGxpZXMgaW4gbGluZSBiZWxvdy4gDQoN CldHOiBQbGVhc2UgdGFrZSBub3RlIHRoaXMgYWRkcyB0aHJlZSBtb3JlIGRlcHJlY2F0ZWQgY29k ZSBwb2ludHMsIGZvciDigJxDaXNjbyBtdWx0aS1zZXNzaW9u4oCdLCDigJxjdW11bHVzIGhvc3Ru YW1l4oCdIGFuZCDigJxPcGVyYXRpb25hbCBtZXNzYWdl4oCdLCBzZWUgdGhlIGJvdHRvbSBvZiB0 aGlzIG1lc3NhZ2UuDQoNCuKAlEpvaG4NCg0KPiBPbiBGZWIgMTEsIDIwMjAsIGF0IDExOjMxIEFN LCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEpv aG46DQo+IA0KPiBIaSEgIFRoYW5rcyBmb3IgeW91ciB3b3JrIG9uIHRoaXMgZG9jdW1lbnQhDQo+ IA0KPiBJIGhhdmUgYSBjb3VwbGUgb2YgaW1wb3J0YW50IGl0ZW1zIHRoYXQgbmVlZCB0byBiZSBh ZGRyZXNzZWQgYmVmb3JlDQo+IG1vdmluZyB0aGlzIGRvY3VtZW50IGZvcndhcmQsIHNwZWNpZmlj YWxseSBhYm91dCBjaGFuZ2UgY29udHJvbCBhbmQgYQ0KPiBjb3VwbGUgbW9yZSB2YWx1ZXMgdGhh dCBzaG91bGQgYmUgZGVwcmVjYXRlZC4gIFBsZWFzZSBzZWUgaW4tbGluZS4NCj4gDQo+IEkgd2ls bCB3YWl0IGZvciBhbiB1cGRhdGUgYmVmb3JlIHN0YXJ0aW5nIHRoZSBJRVRGIExDLg0KPiANCj4g VGhhbmtzISENCj4gDQo+IEFsdmFyby4NCj4gDQo+IA0KPiANCj4gW0xpbmUgbnVtYmVycyBmcm9t IGlkbml0cy5dDQo+IA0KPiANCj4gLi4uDQo+IDExICAgIEFic3RyYWN0DQo+IA0KPiAxMyAgICAg ICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDU0OTIgYnkgbWFraW5nIGEgY2hhbmdlIHRvIHRo ZSByZWdpc3RyYXRpb24NCj4gMTQgICAgICAgcHJvY2VkdXJlcyBmb3IgQkdQIENhcGFiaWxpdHkg Q29kZXMuICBTcGVjaWZpY2FsbHksIHRoZSByYW5nZQ0KPiAxNSAgICAgICBmb3JtZXJseSBkZXNp Z25hdGVkICJSZXNlcnZlZCBmb3IgUHJpdmF0ZSBVc2UiIGlzIGRpdmlkZWQgaW50byB0aHJlZQ0K PiAxNiAgICAgICBuZXcgcmFuZ2VzLCByZXNwZWN0aXZlbHkgZGVzaWduYXRlZCBhcyAiRmlyc3Qg Q29tZSBGaXJzdCBTZXJ2ZWQiLA0KPiAxNyAgICAgICAiRXhwZXJpbWVudGFsIiBhbmQgIlJlc2Vy dmVkIi4NCj4gDQo+IFtuaXRdIHMvRXhwZXJpbWVudGFsL0V4cGVyaW1lbnRhbCBVc2UNCg0KRG9u ZS4NCg0KPiAuLi4NCj4gNjMgICAgMS4gIEludHJvZHVjdGlvbg0KPiANCj4gNjUgICAgICAgW1JG QzU0OTJdIGRlc2lnbmF0ZXMgdGhlIHJhbmdlIG9mIENhcGFiaWxpdHkgQ29kZXMgMTI4LTI1NSBh cw0KPiA2NiAgICAgICAiUmVzZXJ2ZWQgZm9yIFByaXZhdGUgVXNlIi4gIFN1YnNlcXVlbnQgZXhw ZXJpZW5jZSBoYXMgc2hvd24gdGhpcyB0bw0KPiA2NyAgICAgICBiZSBub3Qgb25seSB1c2VsZXNz LCBidXQgYWN0aXZlbHkgY29uZnVzaW5nIHRvIGltcGxlbWVudG9ycy4gIEJHUA0KPiA2OCAgICAg ICBDYXBhYmlsaXR5IENvZGVzIGRvIG5vdCBtZWV0IHRoZSBjcml0ZXJpYSBmb3IgIlByaXZhdGUg VXNlIiBkZXNjcmliZWQNCj4gNjkgICAgICAgaW4gW1JGQzgxMjZdIHNlY3Rpb24gNC4xLiAgQW4g ZXhhbXBsZSBvZiBhIGxlZ2l0aW1hdGUgInByaXZhdGUgdXNlIg0KPiA3MCAgICAgICBjb2RlIHBv aW50IG1pZ2h0IGJlIGEgQkdQIGNvbW11bml0eSBbUkZDMTk5N10gdmFsdWUgYXNzaWduZWQgZm9y IHVzZQ0KPiA3MSAgICAgICB3aXRoaW4gYSBnaXZlbiBBdXRvbm9tb3VzIFN5c3RlbSwgYnV0IG5v IGFuYWxvZ291cyB1c2Ugb2YNCj4gNzIgICAgICAgQ2FwYWJpbGl0aWVzIGV4aXN0cy4NCj4gDQo+ IFtuaXQvcG90ZW50aWFsIHJhdGhvbGVdIEkgZG9u4oCZdCBzZWUgd2h5IENhcGFiaWxpdGllcyBB ZHZlcnRpc2VtZW50DQo+IGNhbuKAmXQgbWVldCB0aGUg4oCcZm9yIHByaXZhdGUgb3IgbG9jYWwg dXNlIG9ubHnigJ0gY3JpdGVyaWEgaW4gcmZjODEyNi4gIEkNCj4gZ3Vlc3Mgd2UganVzdCBkb27i gJl0IGtub3cgb2YgYW55IGxvY2FsLW9ubHkgY2FwYWJpbGl0eSEgIDstKQ0KPiBTZXJpb3VzbHks IEnigJltIG5vdCBnb2luZyB0byBvYmplY3QgdGhlIGp1c3RpZmljYXRpb24sIG9yIHN0cm9uZ2x5 IGFzaw0KPiB5b3UgdG8gY2hhbmdlIGl0LCBidXQgb3RoZXJzIGluIHRoZSBJRVNHIG1pZ2h0LiAg U3VnZ2VzdGlvbjogTGVhdmUNCj4ganVzdCB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcy4NCg0KRG9u ZS4NCg0KPiAuLi4NCj4gODUgICAgMi4gIERpc2N1c3Npb24NCj4gLi4uDQo+IDEwMCAgICAgICBU aGUgcmVhc29uIGZvciBkZXNpZ25hdGluZyAiSUVTRyIgYXMgdGhlIGNoYW5nZSBjb250cm9sbGVy IGZvciBhbGwNCj4gMTAxICAgICAgIHJlZ2lzdHJhdGlvbnMgaXMgdGhhdCB3aGlsZSBpdCBzaG91 bGQgYmUgZWFzeSB0byBvYnRhaW4gYSBDYXBhYmlsaXR5DQo+IDEwMiAgICAgICBDb2RlLCBvbmNl IHJlZ2lzdGVyZWQgaXQncyBub3QgYSB0cml2aWFsIG1hdHRlciB0byBzYWZlbHkgYW5kDQo+IDEw MyAgICAgICBpbnRlcm9wZXJhYmx5IGNoYW5nZSB0aGUgdXNlIG9mIHRoYXQgY29kZSwgYW5kIHRo dXMgd29ya2luZyBncm91cA0KPiAxMDQgICAgICAgY29uc2Vuc3VzIHNob3VsZCBiZSBzb3VnaHQg YmVmb3JlIGNoYW5nZXMgYXJlIG1hZGUgdG8gZXhpc3RpbmcNCj4gMTA1ICAgICAgIHJlZ2lzdHJh dGlvbnMuDQo+IA0KPiBbbWlub3JdIEkgZG9u4oCZdCB0aGluayB0aGlzIHBhcmFncmFwaCBpcyBu ZWVkZWQgYmVjYXVzZSDigJxGb3IgcmVnaXN0cmllcw0KPiBjcmVhdGVkIGJ5IFJGQ3MgaW4gdGhl IElFVEYgc3RyZWFtLCBjaGFuZ2UgY29udHJvbCBmb3IgdGhlIHJlZ2lzdHJ5DQo+IGxpZXMgYnkg ZGVmYXVsdCB3aXRoIHRoZSBJRVRGLCB2aWEgdGhlIElFU0cu4oCdIFtyZmM4MTI2XQ0KPiANCj4g W10gSSB0aGluayBpdCBpcyBjb25mdXNpbmcgKGF0IGxlYXN0IHRvIG1lKSB0aGUgdGV4dCBhYm91 dCDigJx3b3JraW5nDQo+IGdyb3VwIGNvbnNlbnN1c+KAnSBpZiB0aGUgY2hhbmdlIGNvbnRyb2xs ZXIgaXMgdGhlIElFU0csIGFuZCB3ZSdyZQ0KPiBkZWFsaW5nIHdpdGggRkNGUy4gIEFnYWluLCBJ IGRvbuKAmXQgdGhpbmsgdGhpcyBwYXJhZ3JhcGggaXMgbmVlZGVkLg0KDQpEb25lLg0KDQo+IDEw NyAgICAgICBGaW5hbGx5LCB3ZSBpbnZpdGUgaW1wbGVtZW50b3JzIHdobyBoYXZlIHVzZWQgdmFs dWVzIGluIHRoZSByYW5nZQ0KPiAxMDggICAgICAgMTI4LTI1NSB0byBjb250cmlidXRlIHRvIHRo aXMgZHJhZnQsIHNvIHRoYXQgdGhlIHZhbHVlcyBjYW4gYmUNCj4gMTA5ICAgICAgIGluY2x1ZGVk IGluIHRoZSByZWdpc3RyeS4gIFZhbHVlcyB0aGF0IGhhdmUgYmVlbiByZXBvcnRlZCwgYXJlDQo+ IDExMCAgICAgICBpbmNsdWRlZC4NCj4gDQo+IFtuaXRdIFRoZSBpbnZpdGF0aW9uIGlzIG5vdCBu ZWVkZWQsIHNpbmNlIHRoZSBkcmFmdCBpcyBub3cg4oCcZG9uZeKAnSBhbmQNCj4gdGhlIHZhbHVl cyBhcmUgYWxyZWFkeSBpbmNsdWRlZC4uLg0KDQpEb25lLg0KDQo+IDExMiAgICAzLiAgSUFOQSBD b25zaWRlcmF0aW9ucw0KPiAuLi4NCj4gMTE5ICAgICAgIFJlZ2lzdHJ5IE93bmVyL0NoYW5nZSBD b250cm9sbGVyOiBJRVNHDQo+IA0KPiBbXSBTZWUgYWJvdmUuDQoNCkkgdGFrZSBpdCB0aGlzIGlz IGEgcmVxdWVzdCB0byByZW1vdmUgdGhlIGV4cGxpY2l0IGxpc3Rpbmcgb2YgSUVTRyBhcyBjaGFu Z2UgY29udHJvbGxlciwgYmVjYXVzZSBpdOKAmXMgdGhlIGRlZmF1bHQ/IE9LLCBkb25lLg0KDQo+ IDEyMSAgICAgICBSZWdpc3RyYXRpb24gcHJvY2VkdXJlczoNCj4gDQo+IDEyMyAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAxMjQg ICAgICAgICAgICAgICAgICAgICAgIHwgIFJhbmdlICB8IFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmVz IHwNCj4gMTI1ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQo+IDEyNiAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEtNjMgIHwgSUVU RiBSZXZpZXcgICAgICAgICAgICAgfA0KPiAxMjcgICAgICAgICAgICAgICAgICAgICAgIHwgIDY0 LTIzOCB8IEZpcnN0IENvbWUgRmlyc3QgU2VydmVkIHwNCj4gMTI4ICAgICAgICAgICAgICAgICAg ICAgICB8IDIzOS0yNTQgfCBFeHBlcmltZW50YWwgICAgICAgICAgICB8DQo+IDEyOSAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAN Cj4gW21pbm9yXSBQbGVhc2UgYWRkIEZpZ3VyZS9UYWJsZSBudW1iZXJzLg0KDQpEb25lLg0KDQo+ IDEzMSAgICAgICBOb3RlOiBhIHNlcGFyYXRlICJvd25lciIgY29sdW1uIGlzIG5vdCBwcm92aWRl ZCBiZWNhdXNlIHRoZSBvd25lciBvZg0KPiAxMzIgICAgICAgYWxsIHJlZ2lzdHJhdGlvbnMsIG9u Y2UgbWFkZSwgaXMgIklFU0ciLg0KPiANCj4gW21ham9yXSBUaGUgSUFOQSByZXZpZXcgKHdoaWNo IEkgbm93IG5vdGljZSB3YXMgb25seSBzZW50IHRvIFN1ZSBhbmQNCj4gbWUpLCBzYXlzOiAiU2lu Y2UgcGFydCBvZiB0aGUgcmVnaXN0cnkgd2lsbCBiZSBGaXJzdCBDb21lIEZpcnN0DQo+IFNlcnZl ZCwgd2UnbGwgYmUgYWRkaW5nIGEgY2hhbmdlIGNvbnRyb2xsZXIgY29sdW1uLCBwZXIgUkZDIDgx MjYuIg0KPiBbVGhhdCBpcyB0aGUgZnVsbCByZXZpZXcuLi5dICAiQ2hhbmdlIGNvbnRyb2xsZXIi IGFuZCAib3duZXIiIGFyZSB0aGUNCj4gc2FtZSB0aGluZzsgSSB0aGluayBpdCB3b3VsZCBiZSBv ayB0byByZW5hbWUgdGhlICJSZWZlcmVuY2UiIGNvbHVtbg0KPiAoYmVsb3cpIHRvICJSZWZlcmVu Y2UgLyBDaGFuZ2UgQ29udHJvbGxlciIuDQoNCknigJltIGEgbGl0dGxlIGNvbmZ1c2VkIGJ5IHRo aXMgYnV0IGl04oCZcyBubyBza2luIG9mZiBtZSBlaXRoZXIgd2F5OyBkb25lLg0KDQo+IDEzNCAg ICAgICBJQU5BIGlzIHJlcXVlc3RlZCB0byBwZXJmb3JtIHRoZSBmb2xsb3dpbmcgbmV3IGFsbG9j YXRpb25zIHdpdGhpbiB0aGUNCj4gMTM1ICAgICAgICJDYXBhYmlsaXR5IENvZGVzIiByZWdpc3Ry eToNCj4gDQo+IDEzNyAgICAgICArLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsNCj4gMTM4ICAgICAgIHwgVmFsdWUgfCBE ZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWZlcmVuY2Ug fA0KPiAxMzkgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rDQo+IDE0MCAgICAgICB8ICAxMjggIHwgUHJlc3Rh bmRhcmQgUm91dGUgUmVmcmVzaCAoZGVwcmVjYXRlZCkgICAgICAgIHwgKHRoaXMgICAgIHwNCj4g MTQxICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCBkb2N1bWVudCkgfA0KPiAxNDIgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rDQo+IDE0MyAg ICAgICB8ICAxMjkgIHwgUHJlc3RhbmRhcmQgT3V0Ym91bmQgUm91dGUgRmlsdGVyaW5nICAgICAg ICAgIHwgKHRoaXMgICAgIHwNCj4gMTQ0ICAgICAgIHwgICAgICAgfCAoZGVwcmVjYXRlZCksIHBy ZXN0YW5kYXJkIGRyYWZ0LWxpLWlkci0gICAgICAgfCBkb2N1bWVudCkgfA0KPiAxNDUgICAgICAg fCAgICAgICB8IGZsb3dzcGVjLXJwZC0wNCAoZGVwcmVjYXRlZCkgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICB8DQo+IDE0NiAgICAgICArLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsNCj4gMTQ3ICAgICAgIHwgIDEz MCAgfCBQcmVzdGFuZGFyZCBPdXRib3VuZCBSb3V0ZSBGaWx0ZXJpbmcgICAgICAgICAgfCAodGhp cyAgICAgfA0KPiAxNDggICAgICAgfCAgICAgICB8IChkZXByZWNhdGVkKSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IGRvY3VtZW50KSB8DQo+IDE0OSAgICAgICArLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LSsNCj4gMTUwICAgICAgIHwgIDI1NSAgfCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAodGhpcyAgICAgfA0KPiAxNTEgICAgICAgfCAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGRvY3VtZW50KSB8DQo+ IDE1MiAgICAgICArLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLSsNCj4gDQo+IFttYWpvcl0gVGhlcmUgaXMgbWVudGlvbiBp biB0aGUgbWFpbCBhcmNoaXZlIG9mIG90aGVyIHZhbHVlcyB0aGF0DQo+IHNob3VsZCBhbHNvIGJl IGRlcHJlY2F0ZWQgWzFdLg0KPiANCj4gLSAiMTMxIChDSVNDTyBtdWx0aS1zZXNzaW9uKSINCj4g LSAiMTg0LCBjdW11bHVzIGhvc3RuYW1lIGRyYWZ0Ig0KPiAtICIxODUsIG9wZXJhdGlvbmFsIGRy YWZ0Ig0KDQpPSywgdGhhbmtzLiBJIHRoaW5rIHRoZXNlIHdlcmUgYWxsIHJhaXNlZCBieSBUaG9t YXMgTWFuZ2luICh0aGFua3MsIFRob21hcykuIEhlcmXigJlzIGhvdyBJIHRoaW5rIHRoZXkgYXJl IHRvIGJlIGhhbmRsZWQ6DQoNCjEzMTogUmVsb2NhdGVkIHRvIDY4IG5vdyAodGhlIHN0YW5kYXJk aXplZCBjb2RlIHBvaW50KS4gRGVwcmVjYXRlZC4NCjE4NDogUmVsb2NhdGVkIHRvIDczICh0aGUg YXNzaWduZWQgY29kZSBwb2ludCkuIERlcHJlY2F0ZWQuDQoxODU6IFRoaXMgaXMgYSBsaXR0bGUg bW9yZSB0aG9ybnkuIFRoZSBkcmFmdCBpbiBxdWVzdGlvbiBpcyBkcmFmdC1pZXRmLWlkci1vcGVy YXRpb25hbC1tZXNzYWdlLTAwLiBJdOKAmXMgYSBXRyBkcmFmdCwgYnV0IGEgZGVhZCBvbmUgKEkg dGhpbmsgSeKAmWxsIGtpY2sgaXRzIHN0YXRlIHRvIOKAnGRlYWTigJ0gYWZ0ZXIgSeKAmXZlIHNl bnQgdGhpczsgaXQgaGFzbuKAmXQgYmVlbiB1cGRhdGVkIGluIDggeWVhcnMpLiBUaGVyZSBpcyBu byBhc3NpZ25lZCBjb2RlIHBvaW50LCBub3IgaXMgdGhlcmUgbGlrZWx5IHRvIGJlLiBJbiBub3Jt YWwgY291cnNlIG9mIGFmZmFpcnMgaWYgdGhpbmdzIGhhZCBnb25lIGRpZmZlcmVudGx5LCBtYXli ZSB3ZSB3b3VsZCBoYXZlIGVhcmx5LWFsbG9jYXRlZCBhIGNvZGUgcG9pbnQuIFRoZW4sIGJhc2Vk IG9uIHRoZSBkb2N1bWVudCBub3QgcHJvZ3Jlc3NpbmcsIHRoZSBjb2RlIHBvaW50IHdvdWxkIGhh dmUgYmVlbiByZWNsYWltZWQgYnkgSUFOQSBhbmQgbGlzdGVkIGFzIGRlcHJlY2F0ZWQuIFNvLCBJ 4oCZbSBnb2luZyB0byBhbHNvIGxpc3QgdGhpcyBvbmUgYXMgZGVwcmVjYXRlZCBldmVuIHRob3Vn aCB0aGVyZeKAmXMgbm8gc3RhbmRhcmRpemVkL2Fzc2lnbmVkIGNvZGUgcG9pbnQgZm9yIGl0Lg0K DQpJZiBhbnlvbmUgaGFzIG9iamVjdGlvbiB0byBhbnkgb2YgdGhlc2UgYWRkaXRpb25zLCBwbGVh c2UgbWFrZSBzb21lIG5vaXNlIG5vdy4gDQoNCj4gWzFdIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lkci9lSW9UQXozd1M2 ZEpNS0JvSXh3ckFrOThseE1fXzshIU5FdDZ5TWFPLWdrIVNSbEdfeWpCa1ROVkV2Tzk2bjVXMDdM Y0VuYWZ3c3l5UTZzc3FtVHlZb19kVE50VUVTSkNJeGJCaUM1UlN3JCANCg0KDQo= From nobody Wed Apr 15 12:12:20 2020 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 C70353A07A2; Wed, 15 Apr 2020 12:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9O5Nw_6ghV5i; Wed, 15 Apr 2020 12:12:16 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 12EA83A07A0; Wed, 15 Apr 2020 12:12:16 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id g12so1034282wmh.3; Wed, 15 Apr 2020 12:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=gZy9wQH8zSxd3p/P/hGUm0klI5qxEDgwNVlLR5bePTA=; b=E7STULMt7FU9bjyy0WN7feoTx9sUAgzr3iDHhlvXAEAjuBbWgYcjNosTE1i8RU2oT0 XXYWIkqynV2bxOGN4EEYod6jm5UE3wywBidwqqRspCmvhmZ+xinkx5ZktAIJXjkkMe1g wUcCEdCk8J03pTEaLQ61WUFG9ys924J1JcusgipOT628O//jytc+Y2cHHqpJ/ZJVTSOw uS8PjVJuvxzsCG5wlnkCPWJAry60BZ1nlHu4psJ1Zsttv886q5GRh5EaKmX9Zqx6A9Bg JLmtHNycrGtoM9vCrEFqmlPBXzEJXG8Zj8d9cAVMbwJRJKO8x6vXpCU9Ff4H5JVnLsz+ utMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=gZy9wQH8zSxd3p/P/hGUm0klI5qxEDgwNVlLR5bePTA=; b=LigYXEiNj/FSUc8jN9ML8HbJCu0MFO9m4kxR7vTvCt0oGnW2QaaqLG5w25XHn6aWAy drWnFo2mj+UYHjg2HfwyHKdMVhLVXhiCKj0p9eFEofDHfrgf6c3iQWMJwR0XrT7lJ1qt XjX7CNRmvRJJD+C28920+xN/VaAndJtct9iMG9KDZX+b1h2u1/27HF8OqJv0K+OQ/W9o 8fkmmQo4RH9HI1WHOuVOfbZXSL7VvgpVWI7FR1FeBY92vsrDwroV7ila2fKwvMOHrgRB +3P75/Aygmx5uV/usDhod94RlBFMuWUUtMMI9rH8ZchZA+2LxdngjANN1DOu7saWV9g8 cdYA== X-Gm-Message-State: AGi0PuaCQgBkd6au0v63ZI60rv+PrMcMfWpmyfNTxayjDuQmuFAd32OK xVNMd+EC21LdRWyCR0dyjGjsS7XywTyLki/evkY= X-Google-Smtp-Source: APiQypKQPbmnEYPRaGKwAr2ec6dNU1C7FFlhAgaN+VE9EzaXLXUNTbkNuVau+05IluDEhu9EgJ3pjf2YjXWvimi4OvA= X-Received: by 2002:a1c:4b16:: with SMTP id y22mr722473wma.170.1586977934600; Wed, 15 Apr 2020 12:12:14 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Apr 2020 12:12:13 -0700 From: Alvaro Retana In-Reply-To: <2593C5E1-0F7D-4B2C-9535-981052B2B06E@juniper.net> References: <2593C5E1-0F7D-4B2C-9535-981052B2B06E@juniper.net> MIME-Version: 1.0 Date: Wed, 15 Apr 2020 12:12:13 -0700 Message-ID: To: John Scudder Cc: Hares Susan , idr-chairs , "idr@ietf. org" , "draft-ietf-idr-capabilities-registry-change@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000eeded05a359186d" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-capabilities-registry-change-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 19:12:18 -0000 --0000000000000eeded05a359186d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks John! I=E2=80=99ve started the IETF LC. If anyone in the WG has comments about the additional code points, please make them during the IETF LC period (to end on Apr/30). Thanks! Alvaro. On April 15, 2020 at 2:36:22 PM, John Scudder (jgs@juniper.net) wrote: Thanks for the review! I=E2=80=99ve uploaded -07 to address your comments. = Some replies in line below. WG: Please take note this adds three more deprecated code points, for =E2=80=9CCisco multi-session=E2=80=9D, =E2=80=9Ccumulus hostname=E2=80=9D a= nd =E2=80=9COperational message=E2=80=9D, see the bottom of this message. --0000000000000eeded05a359186d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Thanks John!=C2=A0

I=E2=80=99ve started the IETF LC.

If anyone in the WG has comments = about the additional code points, please make them during the IETF LC perio= d (to end on Apr/30).

Thanks!
<= br>
Alvaro.<= /div>



On April 15, 2020 at 2:36:22 PM, John Scudder (jgs@juniper.net) wrote:

Thanks for the review! I=E2=80=99ve uploaded -07 to address your commen= ts. Some replies in line below.=C2=A0=

WG: Please take = note this adds three more deprecated code points, for =E2=80=9CCisco multi-= session=E2=80=9D, =E2=80=9Ccumulus hostname=E2=80=9D and =E2=80=9COperation= al message=E2=80=9D, see the bottom of this message.=C2=A0
--0000000000000eeded05a359186d-- From nobody Wed Apr 15 13:41:21 2020 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 A92543A0A1A; Wed, 15 Apr 2020 13:41:12 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158698327241.18861.17928066657295133304@ietfa.amsl.com> Date: Wed, 15 Apr 2020 13:41:12 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc8203bis-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 20:41:13 -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 : Extended BGP Administrative Shutdown Communication Authors : Job Snijders Jakob Heitz John Scudder Alexander Azimov Filename : draft-ietf-idr-rfc8203bis-06.txt Pages : 7 Date : 2020-04-15 Abstract: This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc8203bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc8203bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc8203bis-06 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 Apr 15 14:01:20 2020 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 208283A0764; Wed, 15 Apr 2020 14:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=GGO/PyXq; dkim=pass (1024-bit key) header.d=juniper.net header.b=UQD3PPVz 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 Flx34Fy2XhM8; Wed, 15 Apr 2020 14:01:15 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4446F3A064C; Wed, 15 Apr 2020 14:01:15 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03FKvnRs010638; Wed, 15 Apr 2020 14:01:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=ySxfEPKdL2zQae4CBdToWk1ejda5k0NTgu7Ykzq1qt0=; b=GGO/PyXqdwiJxjiBxA99WOg4x+e77n+O+u1FrqtmXQuIpqT6mjNyFUnRh98lVJysiuoS t00BIhfv4OYD23omTzq4IX9HxqQ7iKThAMSS5NjbWjr+YwXRwoiqWY2moAWDo0/hMgyI pxQKVyFIOJtiJO2/7jDZ4nGR5xRo0is7Jx9hmxCquV6oLBhfURLw43421yeK6/zhj1RM Qba6RekX7vaERa2wM58lRCWboU2btjjfGmFvdQhSBXomXZn3AJllV88FW9di2kC2EP9Z VfMVKZOTlI/XV1/hrwa9psmTMntvLyrTxWJgBq0+aDXGC7bInFbCmaO+qbOU7kh2H2fG 3A== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169]) by mx0a-00273201.pphosted.com with ESMTP id 30dnausw08-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Apr 2020 14:01:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S76ISDgthtRrsxsE8Enexag/oiU6WdhYsrfUrbvKey8cDCuwDYEp9niwBE2NrgzWFvlJnQu8X2TwVj2n/dB1VUGVl7+uzJprpgVUGZqNWoeX9Ol4r1p+yf8shtxRsz6IzFWr8UKHXBZqNjbRh7KzCWkNvlbi2n2TsoKJ656B34Ue8jJ/aHkdGpqSAx+FwyuIUWvnx4IVQSyHGbHz34yLqtL3kjMoczKqrsImOwdv+0Kvom1KpKXpyFZXtg+wMHkd0Jd8kyEF9ljCKucwllWMFgeM70rnDnggRswrzwSJ5HQG7rBUgfP5ZaHyI/elfkC4eJnVDmsbelNR6TkZjqlItA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ySxfEPKdL2zQae4CBdToWk1ejda5k0NTgu7Ykzq1qt0=; b=ieGjnaLrMnkDqpPt0ku1YjqTEfU+TvzYvmWtLyPbDnPaeR+hvfLmDWsnTGTJ7vpLNJMeD+KnyaRqzRVDLsWJWhdVu8hTvPEHMVj4nqUh3WylShIYng4mqsikByUxGEvkRLxty+m4W6RQyVw0CQPFhVLNUcecMpJufash6y65aGoDW12iStw2lzM/Q+0lQFGB0rD8ef45EwJZOiA7S0ESVYDpLIINmtskoOyxXIOxCA3tYbDlp0NMbPJ27pWJqe2bUiaYzy63Tcri4n85h7Wz8XXRzJ+7OM9omeKGaMATmM/+0IgJdblrR0aO9mGO7K9znIkBlDHrJpt16K2qpW8a+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ySxfEPKdL2zQae4CBdToWk1ejda5k0NTgu7Ykzq1qt0=; b=UQD3PPVz4sV7qj5eVkxuXufV4s8WaxDC2aJC/Q3mWhVA0fJIN9HYoWSPAU4y1pfUYJT4jnTzNeb69+2i9xuWSRn+ViB7swjBYWdTeqMQ4TRH1CuZIcRc5q8t6xYAcxq3LA2Wu515VQoggTwrLsJTQb1bl1XfbQBgcB+pQbeoma8= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB7188.namprd05.prod.outlook.com (2603:10b6:208:1cc::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.18; Wed, 15 Apr 2020 21:01:13 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 21:01:12 +0000 From: John Scudder To: Hares Susan CC: "idr@ietf.org" , "draft-ietf-idr-rfc8203bis@ietf.org" Thread-Topic: Shepherd initial report on RFC8203bis Thread-Index: AdUdxFK+5yu67cZcSua+jSTsHxRVSj1pKusA Date: Wed, 15 Apr 2020 21:01:12 +0000 Message-ID: References: <079f01d51dc6$00d6b9a0$02842ce0$@ndzh.com> In-Reply-To: <079f01d51dc6$00d6b9a0$02842ce0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-originating-ip: [2600:1700:37a0:3ca0:e133:e45c:a238:c10d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a9726019-b6c6-4066-975f-08d7e1802179 x-ms-traffictypediagnostic: BL0PR05MB7188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(376002)(396003)(346002)(136003)(39860400002)(366004)(6506007)(2616005)(81156014)(186003)(5660300002)(478600001)(4743002)(86362001)(4326008)(6486002)(966005)(54906003)(2906002)(8936002)(8676002)(6512007)(71200400001)(66446008)(66556008)(66946007)(53546011)(64756008)(66476007)(33656002)(6916009)(36756003)(316002)(76116006)(91956017); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u99rNp+9YBAqV/i70bFblA1Tn25+8WmIDw65BoWcBXVSYAY6VgjywlyuIXuc4n3TOYw1fBiGpDnZ/31kW65dfhAsVWS1W9urg1vSovC1YryuG+FCkyOwsfWuP/Kh7iYqzotx9VqZfI8hmUyT9rF5QwH+wqfA+JcwUWOswXge+9saRh3uWp2CqZ0ABrZXOHaX0jMZ3NirHA+m1+8n2BHHOkYRqmTgN4ZZQBa5u8POPrAefx7jdc0bF4nK421heQyqQ1WX8R7WpmhpM3KU6S9GhRb8nSELKEaMmNuLvIh4QKSn4Z4Eoud8uM3GT2LfAVRYuRIaFYpZHI6Fp5Mo4MXobgVvhlN0UzrZsOsE5vvST4f6g69vOKRSY5Avw4R8W4ryeJzZAHPjVoz0yKafG4FFHvkwOTWH2axn0W/bNvNkbtw9JiRZiGSWkbqy7hiLyzUnWHr8NaB9+gFgJCs4cCRWz3OcpGhyNWdRO3j2SOF7vImye5bf1KHp50NKNUX/UJYD44F8VwYQXygfcS69Hkj8MA== x-ms-exchange-antispam-messagedata: yiwpSbiDjzlafnvbify4AvbvfS+wBGoVX9cmQdVLf1WQHqjmzyKfcDBHOeN1VkDsdu4gfTnPPI/G8VfQnmCjDMYN9hr7pDYPFgxfhVxOdwccq40B02hVzRjgaI/XW+ChVUmcnMGHOKdlEkb96AlSitTWJAiBzbYuTziUiQUqnE0TjvE5Fp7cDga4tvFykDmhLee4Ey4rUKi1YYMcToO8Bw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D216609683554CB68C61791AB87B16EDjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a9726019-b6c6-4066-975f-08d7e1802179 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 21:01:12.8765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IftudGeNVSKPe3uFjKSdtXFVLZKu3pARaRFhGFvRn6lB07W67GmsSzVw64q3Bqg0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB7188 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-15_07:2020-04-14, 2020-04-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 phishscore=0 impostorscore=0 clxscore=1011 bulkscore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004150157 Archived-At: Subject: Re: [Idr] Shepherd initial report on RFC8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 21:01:17 -0000 --_000_D216609683554CB68C61791AB87B16EDjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KENvYXV0aG9yIGhhdCBvbikNCg0KSGkgU3VlLA0KDQpJ4oCZdmUgdXBsb2FkZWQgLTA2IHdoaWNo IEkgdGhpbmsgcmVzb2x2ZXMgeW91ciBpc3N1ZXMuIFRoZSBpZG5pdHMgaXNzdWUgaXMgYSBsaXR0 bGUgaW52b2x2ZWQgYnV0IHRoZSBzdW1tYXJ5IGlzIOKAnGlkbml0cyBpcyBiZWluZyB0b28gcGlj a3nigJ0sIEkgZ28gaW50byBtb3JlIGRldGFpbCBiZWxvdy4NCg0KT24gSnVuIDgsIDIwMTksIGF0 IDI6NDcgQU0sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpo LmNvbT4+IHdyb3RlOg0KDQpTdGF0dXM6ICBBbG1vc3QgcmVhZHksICAzIHJlcXVpcmVkIGVkaXRv cmlhbCBhbmQgbmVlZCBmb3IgaW1wbGVtZW50YXRpb24gcmVwb3J0IHJldmlzaW9uLg0KDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1yZmM4MjAzYmlzL3No ZXBoZXJkd3JpdGV1cC88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEaWRyLTJE cmZjODIwM2Jpc19zaGVwaGVyZHdyaXRldXBfJmQ9RHdNRkFnJmM9SEFrWXVoNjNyc3VocjZTY2Jm aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPWhMdDVpREpwdzd1a3FJQ2MwaG9UN0EmbT0tZU1p SGdPN2daMnJ4QXhZUlMzYm05WjVueHBfODJ3Y1dURDNGMFN0cVVBJnM9VXFhT3NGbkJwSTVuanFn LWI5NUNVLXJXWHQ2LThQNE9NeGtEUjdWX3ZtbyZlPT4NCg0KSXNzdWVzOiAga2V5IGVkaXRvcmlh bCB0aGluZ3MgZm9yIElFU0cgc3VibWlzc2lvbiBuZWVkIHRvIGJlIGFkZHJlc3NlZDoNCg0KMSkg ICAgICBSRkM4MjAzIG11c3QgYmUgbWVudGlvbmVkIGluIHRoZSBpbnRyb2R1Y3Rpb24gYXMgd2Vs bCBhcyBjdXJyZW50IHJlZmVyZW5jZXMgKHRvcCBvZiBmcm9udCBwYWdlLCBBYnN0cmFjdCkNCg0K RG9uZS4NCg0KMikgICAgICBOSVRTIG5lZWQgdG8gYmUgcmVzb2x2ZWQNCg0KICBmb3VuZDogTmVl ZCBmb3IgZGlmZmVyZW50IGJvaWxlciBwbGF0ZSBvciByZXNvbHV0aW9uIG9uIGdlbmVyYXRpb24N Cg0KICAtLSBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gbGFjayBhIGRpc2NsYWltZXIgZm9yIHByZS1S RkM1Mzc4IHdvcmssIGJ1dCBtYXkNCiAgICAgaGF2ZSBjb250ZW50IHdoaWNoIHdhcyBmaXJzdCBz dWJtaXR0ZWQgYmVmb3JlIDEwIE5vdmVtYmVyIDIwMDguICBJZiB5b3UNCiAgICAgaGF2ZSBjb250 YWN0ZWQgYWxsIHRoZSBvcmlnaW5hbCBhdXRob3JzIGFuZCB0aGV5IGFyZSBhbGwgd2lsbGluZyB0 byBncmFudA0KICAgICB0aGUgQkNQNzggcmlnaHRzIHRvIHRoZSBJRVRGIFRydXN0LCB0aGVuIHRo aXMgaXMgZmluZSwgYW5kIHlvdSBjYW4gaWdub3JlDQogICAgIHRoaXMgY29tbWVudC4gIElmIG5v dCwgeW91IG1heSBuZWVkIHRvIGFkZCB0aGUgcHJlLVJGQzUzNzggZGlzY2xhaW1lci4NCiAgICAg KFNlZSB0aGUgTGVnYWwgUHJvdmlzaW9ucyBkb2N1bWVudCBhdA0KICAgICBodHRwczovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvIGZvciBtb3JlIGluZm9ybWF0aW9uLikNCg0KSWYgdGhp cyBpcyBpbiBlcnJvciBhbmQgeW91IGFyZSB1c2luZyBYTUwgY29udmVyc2lvbiwgcGxlYXNlIGlu cXVpcmUgb24geG1sMnJmYyB0b29sIGxpc3QuDQoNCkkgZG9u4oCZdCB0aGluayB0aGVyZeKAmXMg YSBCQ1AgNzggcHJvYmxlbSBhbmQgSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBhbiB4bWwycmZj IHByb2JsZW0uIChUaGVyZeKAmXMga2luZCBvZiBhbiBpZG5pdHMgcHJvYmxlbSwgc2VlIG5leHQg cGFyYWdyYXBoLikgTGV0IG1lIGV4cGxhaW4sIGFsdGhvdWdoIHBsZWFzZSBpbWFnaW5lIGEgY2hv cnVzIGNoYW50aW5nIOKAnEkgYW0gbm90IGEgbGF3eWVyIGFuZCB0aGlzIGlzIG5vdCBsZWdhbCBh ZHZpY2XigJ0gaW4gdGhlIGJhY2tncm91bmQuIEJDUCA3OCBzYXlzIHdlICh0aGUgYXV0aG9ycykg Z3JhbnQgdGhlIElFVEYgVHJ1c3QgdmFyaW91cyByaWdodHMsIGluY2x1ZGluZyB0byBwcm9kdWNl IGRlcml2YXRpdmUgd29ya3MsIGJsYWggYmxhaC4gTm93LCBpZiBvdXIgZG9jdW1lbnQgd2FzIGl0 c2VsZiBhIG1vZGlmaWNhdGlvbiBvZiBhIHByZXZpb3VzIGRvY3VtZW50LCB3ZSBtaWdodCBub3Qg YmUgdGhlIG9ubHkgYXV0aG9ycyBhbmQgbWlnaHQgbm90IGhhdmUgYXV0aG9yaXR5IHRvIGdyYW50 IHRob3NlIHJpZ2h0cy4gQnV0LCBhbHRob3VnaCBvdXIgaGVhZGVyIHNheXMg4oCcVXBkYXRlczog NDQ4NuKAnSBpdCBkb2VzbuKAmXQgYWN0dWFsbHkgaW5jbHVkZSB0ZXh0IGZyb20gUkZDIDQ0ODYs IGNlcnRhaW5seSBub3QgdGV4dCBiZXlvbmQgdGhhdCB3aGljaCB3b3VsZCBiZSBhbGxvd2VkIGJ5 IGZhaXIgdXNlLiBBcyBzdWNoLCBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCBFbmtlIG9yIFZpbmNl bnQgdG8gc2lnbiBvZmYuIEkgdGhpbmsgaXTigJlzIGFsc28gdGhlIGNhc2UgdGhhdCB0aGlzIGRl dGVybWluYXRpb24gaXMgb24gdXMgYXMgYXV0aG9ycyB0byBtYWtlLCBub3Qgb24gdGhlIElFVEYu DQoNCkFjdHVhbGx5IEnigJltIG5vdCBzdXJlIHdoeSBpZG5pdHMgYXBwbGllcyB0aGUgQkNQIDc4 IGNoZWNrIGFnYWluc3QgdGhlIHVwZGF0ZWQgZG9jdW1lbnRzLiBJ4oCZdmUgcmFpc2VkIHRoaXMg d2l0aCBIZW5yaWssIGJ1dCBJIGRvbuKAmXQgdGhpbmsgaXQgbmVlZHMgdG8gaG9sZCB1cCBwcm9n cmVzcyBvZiBvdXIgZG9jdW1lbnQg4oCUIGEgZGlsaWdlbnQgZG9jdW1lbnQgc2hlcGhlcmQgbWln aHQgYXNrIHRoZSBhdXRob3JzIOKAnGFyZSB5b3Ugc3VyZT/igJ0gd2hpY2ggeW914oCZdmUgbm93 IGRvbmUsIGFuZCB0aGFuayB5b3UgZm9yIHRoYXQuIEksIGZvciBvbmUsIGFtIHN1cmUuIEFzIHdl IGJvdGgga25vdywgaWRuaXRzIGlzIGp1c3QgYSBzdWdnZXN0aW9uLCBpdOKAmXMgbm90IHJlcXVp cmVkIHRvIHJ1biBjbGVhbiwgaXTigJlzIGd1aWRhbmNlIGZvciB0aGUgc2hlcGhlcmQuDQoNCkJ5 IHRoZSB3YXksIGZvciBzb21lIHJlYXNvbiBpZG5pdHMgcnVucyBjbGVhbiB3aGVuIEkgc3VibWl0 IHRoZSBkb2N1bWVudCwgYnV0IGlmIEkgcnVuIHN0YW5kYWxvbmUgaWRuaXRzIGl0IHRocm93cyB0 aGUgZXJyb3IgeW914oCZdmUgbWVudGlvbmVkLiBOb3Qgc3VyZSB3aHkgdGhhdCBpcy4gTWF5YmUg dGhlIHN1Ym1pc3Npb24gbW9kZSBzdXBwcmVzc2VzIG1pc2NlbGxhbmVvdXMgd2FybmluZ3MsIG9y IG1heWJlIGl04oCZcyBhIGJ1Zy4NCg0KMykgICAgICBJTiBzZWN0aW9uOiA1LiAgSUFOQSBDb25z aWRlcmF0aW9ucw0KDQogICAgICAgIE9sZDogIC9DZWFzZSBOb3RpZmljYXRpb24gbWVzc2FnZSBz dWJjb2Rlcy8NCiAgICAgICBOZXc6IC9CR1AgQ2Vhc2UgTk9USUZJQ0FUSU9OIG1lc3NhZ2Ugc3Vi Y29kZXMvDQoNCiAgICBUaGUgYWN0dWFsIHJlZ2lzdHJ5IG5hbWUgaXMgaW4gdGhlIG5ldyB0ZXh0 Lg0KDQpEb25lLg0KDQo0KSAgICAgIEltcGxlbWVudGF0aW9uIHJlcG9ydCBmb3IgT1BFTkJTRCBh bmQgQklSRCBuZWVkIHRvIGJlIGNvbXBsZXRlZCBvciBleHBsYWluZWQuDQooeWVzL25vKSBpbiBl YWNoIGNhdGVnb3J5IGlzIG5vdCB1bmRlcnN0YW5kYWJsZS4NCg0KSSByZW1vdmVkIHRoZSBpbXBs ZW1lbnRhdGlvbiBzZWN0aW9uIGVudGlyZWx5LCBzaW5jZSBpdCB3YXMgc3VwcG9zZWQgdG8gYmUg cmVtb3ZlZCBieSB0aGUgUkZDIEVkaXRvciBhbnl3YXkgYW5kIHNpbmNlIHdlIGhhdmUgYW4gaW1w bGVtZW50YXRpb24gcmVwb3J0IGF2YWlsYWJsZSBhdCBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy9pZHIvd2lraS9kcmFmdC1pZXRmLWlkci1yZmM4MjAzYmlzDQoNClRoYW5rcywNCg0K4oCUSm9o bg0K --_000_D216609683554CB68C61791AB87B16EDjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <1ECF61CB7D02BA40B76438C4ED7A4D09@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCihDb2F1dGhvciBoYXQgb24pDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IaSBTdWUsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZdmUg dXBsb2FkZWQgLTA2IHdoaWNoIEkgdGhpbmsgcmVzb2x2ZXMgeW91ciBpc3N1ZXMuIFRoZSBpZG5p dHMgaXNzdWUgaXMgYSBsaXR0bGUgaW52b2x2ZWQgYnV0IHRoZSBzdW1tYXJ5IGlzIOKAnGlkbml0 cyBpcyBiZWluZyB0b28gcGlja3nigJ0sIEkgZ28gaW50byBtb3JlIGRldGFpbCBiZWxvdy48YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gSnVuIDgsIDIwMTksIGF0IDI6NDcgQU0sIFN1c2FuIEhhcmVzICZsdDs8YSBocmVm PSJtYWlsdG86c2hhcmVzQG5kemguY29tIiBjbGFzcz0iIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KU3RhdHVzOiZuYnNwOyBBbG1vc3QgcmVhZHks Jm5ic3A7IDMgcmVxdWlyZWQgZWRpdG9yaWFsIGFuZCBuZWVkIGZvciBpbXBsZW1lbnRhdGlvbiBy ZXBvcnQgcmV2aXNpb24uPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNr ZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGlkci0yRHJmYzgyMDNiaXNfc2hlcGhlcmR3 cml0ZXVwXyZhbXA7ZD1Ed01GQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5k YjN2b0RUWGNXem9DSSZhbXA7cj1oTHQ1aURKcHc3dWtxSUNjMGhvVDdBJmFtcDttPS1lTWlIZ083 Z1oycnhBeFlSUzNibTlaNW54cF84MndjV1REM0YwU3RxVUEmYW1wO3M9VXFhT3NGbkJwSTVuanFn LWI5NUNVLXJXWHQ2LThQNE9NeGtEUjdWX3ZtbyZhbXA7ZT0iIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLXJmYzgyMDNiaXMvc2hlcGhlcmR3cml0ZXVw LzwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJ c3N1ZXM6Jm5ic3A7IGtleSBlZGl0b3JpYWwgdGhpbmdzIGZvciBJRVNHIHN1Ym1pc3Npb24gbmVl ZCB0byBiZSBhZGRyZXNzZWQ6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHRleHQtaW5kZW50OiAtMC4y NWluOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4xKTxzcGFuIHN0eWxlPSJmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OzsiIGNsYXNzPSIiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIiBjbGFzcz0i Ij48L3NwYW4+UkZDODIwMw0KIG11c3QgYmUgbWVudGlvbmVkIGluIHRoZSBpbnRyb2R1Y3Rpb24g YXMgd2VsbCBhcyBjdXJyZW50IHJlZmVyZW5jZXMgKHRvcCBvZiBmcm9udCBwYWdlLCBBYnN0cmFj dCk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KRG9uZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgdGV4dC1pbmRl bnQ6IC0wLjI1aW47IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHRleHQtaW5kZW50OiAtMC4yNWluOyIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4yKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQt c3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OzsiIGNsYXNzPSIiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIiBjbGFzcz0iIj48L3Nw YW4+TklUUw0KIG5lZWQgdG8gYmUgcmVzb2x2ZWQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtmb3VuZDogTmVlZCBmb3IgZGlmZmVy ZW50IGJvaWxlciBwbGF0ZSBvciByZXNvbHV0aW9uIG9uIGdlbmVyYXRpb248c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7LS0gVGhlIGRvY3VtZW50IHNlZW1zIHRv IGxhY2sgYSBkaXNjbGFpbWVyIGZvciBwcmUtUkZDNTM3OCB3b3JrLCBidXQgbWF5PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhdmUgY29udGVudCB3aGljaCB3YXMgZmly c3Qgc3VibWl0dGVkIGJlZm9yZSAxMCBOb3ZlbWJlciAyMDA4LiZuYnNwOyBJZiB5b3U8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGF2ZSBjb250YWN0ZWQgYWxsIHRoZSBv cmlnaW5hbCBhdXRob3JzIGFuZCB0aGV5IGFyZSBhbGwgd2lsbGluZyB0byBncmFudDxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgQkNQNzggcmlnaHRzIHRvIHRoZSBJ RVRGIFRydXN0LCB0aGVuIHRoaXMgaXMgZmluZSwgYW5kIHlvdSBjYW4gaWdub3JlPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgY29tbWVudC4mbmJzcDsgSWYgbm90 LCB5b3UgbWF5IG5lZWQgdG8gYWRkIHRoZSBwcmUtUkZDNTM3OCBkaXNjbGFpbWVyLjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoU2VlIHRoZSBMZWdhbCBQcm92aXNpb25zIGRv Y3VtZW50IGF0PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9y Zy9saWNlbnNlLWluZm88L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPmZvciBtb3JlIGluZm9ybWF0aW9uLik8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQpJZiB0aGlzIGlzIGluIGVycm9yIGFuZCB5b3UgYXJlIHVzaW5nIFhNTCBjb252 ZXJzaW9uLCBwbGVhc2UgaW5xdWlyZSBvbiB4bWwycmZjIHRvb2wgbGlzdC48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkkgZG9u4oCZdCB0 aGluayB0aGVyZeKAmXMgYSBCQ1AgNzggcHJvYmxlbSBhbmQgSSBkb27igJl0IHRoaW5rIHRoZXJl 4oCZcyBhbiB4bWwycmZjIHByb2JsZW0uIChUaGVyZeKAmXMga2luZCBvZiBhbiBpZG5pdHMgcHJv YmxlbSwgc2VlIG5leHQgcGFyYWdyYXBoLikgTGV0IG1lIGV4cGxhaW4sIGFsdGhvdWdoIHBsZWFz ZSBpbWFnaW5lIGEgY2hvcnVzIGNoYW50aW5nIOKAnEkgYW0gbm90IGEgbGF3eWVyIGFuZCB0aGlz IGlzIG5vdCBsZWdhbCBhZHZpY2XigJ0gaW4gdGhlIGJhY2tncm91bmQuDQogQkNQIDc4IHNheXMg d2UgKHRoZSBhdXRob3JzKSBncmFudCB0aGUgSUVURiBUcnVzdCB2YXJpb3VzIHJpZ2h0cywgaW5j bHVkaW5nIHRvIHByb2R1Y2UgZGVyaXZhdGl2ZSB3b3JrcywgYmxhaCBibGFoLiBOb3csIGlmIG91 ciBkb2N1bWVudCB3YXMgaXRzZWxmIGEgbW9kaWZpY2F0aW9uIG9mIGEgcHJldmlvdXMgZG9jdW1l bnQsIHdlIG1pZ2h0IG5vdCBiZSB0aGUgb25seSBhdXRob3JzIGFuZCBtaWdodCBub3QgaGF2ZSBh dXRob3JpdHkgdG8gZ3JhbnQNCiB0aG9zZSByaWdodHMuIEJ1dCwgYWx0aG91Z2ggb3VyIGhlYWRl ciBzYXlzIOKAnFVwZGF0ZXM6IDQ0ODbigJ0gaXQgZG9lc27igJl0IGFjdHVhbGx5IGluY2x1ZGUg dGV4dCBmcm9tIFJGQyA0NDg2LCBjZXJ0YWlubHkgbm90IHRleHQgYmV5b25kIHRoYXQgd2hpY2gg d291bGQgYmUgYWxsb3dlZCBieSBmYWlyIHVzZS4gQXMgc3VjaCwgSSBkb27igJl0IHRoaW5rIHdl IG5lZWQgRW5rZSBvciBWaW5jZW50IHRvIHNpZ24gb2ZmLiBJIHRoaW5rIGl04oCZcyBhbHNvIHRo ZQ0KIGNhc2UgdGhhdCB0aGlzIGRldGVybWluYXRpb24gaXMgb24gdXMgYXMgYXV0aG9ycyB0byBt YWtlLCBub3Qgb24gdGhlIElFVEYuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5BY3R1YWxseSBJ4oCZbSBub3Qgc3VyZSB3aHkgaWRuaXRzIGFwcGxpZXMgdGhl IEJDUCA3OCBjaGVjayBhZ2FpbnN0IHRoZSB1cGRhdGVkIGRvY3VtZW50cy4gSeKAmXZlIHJhaXNl ZCB0aGlzIHdpdGggSGVucmlrLCBidXQgSSBkb27igJl0IHRoaW5rIGl0IG5lZWRzIHRvIGhvbGQg dXAgcHJvZ3Jlc3Mgb2Ygb3VyIGRvY3VtZW50IOKAlCBhIGRpbGlnZW50IGRvY3VtZW50IHNoZXBo ZXJkIG1pZ2h0IGFzayB0aGUgYXV0aG9ycyDigJxhcmUgeW91IHN1cmU/4oCdIHdoaWNoDQogeW91 4oCZdmUgbm93IGRvbmUsIGFuZCB0aGFuayB5b3UgZm9yIHRoYXQuIEksIGZvciBvbmUsIGFtIHN1 cmUuIEFzIHdlIGJvdGgga25vdywgaWRuaXRzIGlzIGp1c3QgYSBzdWdnZXN0aW9uLCBpdOKAmXMg bm90IHJlcXVpcmVkIHRvIHJ1biBjbGVhbiwgaXTigJlzIGd1aWRhbmNlIGZvciB0aGUgc2hlcGhl cmQuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5CeSB0aGUgd2F5LCBm b3Igc29tZSByZWFzb24gaWRuaXRzIHJ1bnMgY2xlYW4gd2hlbiBJIHN1Ym1pdCB0aGUgZG9jdW1l bnQsIGJ1dCBpZiBJIHJ1biBzdGFuZGFsb25lIGlkbml0cyBpdCB0aHJvd3MgdGhlIGVycm9yIHlv deKAmXZlIG1lbnRpb25lZC4gTm90IHN1cmUgd2h5IHRoYXQgaXMuIE1heWJlIHRoZSBzdWJtaXNz aW9uIG1vZGUgc3VwcHJlc3NlcyBtaXNjZWxsYW5lb3VzIHdhcm5pbmdzLCBvciBtYXliZSBpdOKA mXMgYSBidWcuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgdGV4dC1pbmRlbnQ6IC0wLjI1 aW47IiBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjMpPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg Zm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7OyIgY2xhc3M9IiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiIGNsYXNzPSIi Pjwvc3Bhbj5JTg0KIHNlY3Rpb246IDUuJm5ic3A7IElBTkEgQ29uc2lkZXJhdGlvbnM8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgT2xkOiZuYnNwOyAvQ2Vhc2UgTm90aWZpY2F0aW9uIG1lc3NhZ2Ugc3Vi Y29kZXMvPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE5ldzogL0JHUCBDZWFzZSBOT1RJRklDQVRJT04gbWVzc2FnZSBzdWJjb2Rlcy88bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsgVGhlIGFjdHVhbCBy ZWdpc3RyeSBuYW1lIGlzIGluIHRoZSBuZXcgdGV4dC4gJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpEb25lLjwvZGl2Pg0KPGRp dj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTFwdDsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9 InBhZ2U6IFdvcmRTZWN0aW9uMTsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHRleHQtaW5kZW50OiAtMC4yNWluOyIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj40KTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQt c3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OzsiIGNsYXNzPSIiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIiBjbGFzcz0iIj48L3Nw YW4+SW1wbGVtZW50YXRpb24NCiByZXBvcnQgZm9yIE9QRU5CU0QgYW5kIEJJUkQgbmVlZCB0byBi ZSBjb21wbGV0ZWQgb3IgZXhwbGFpbmVkLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQooeWVzL25vKSBpbiBlYWNoIGNh dGVnb3J5IGlzIG5vdCB1bmRlcnN0YW5kYWJsZS4mbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJIHJlbW92ZWQgdGhlIGltcGxlbWVudGF0aW9u IHNlY3Rpb24gZW50aXJlbHksIHNpbmNlIGl0IHdhcyBzdXBwb3NlZCB0byBiZSByZW1vdmVkIGJ5 IHRoZSBSRkMgRWRpdG9yIGFueXdheSBhbmQgc2luY2Ugd2UgaGF2ZSBhbiBpbXBsZW1lbnRhdGlv biByZXBvcnQgYXZhaWxhYmxlIGF0Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItcmZjODIwM2JpcyIgY2xhc3M9IiI+aHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItcmZjODIwM2Jpczwv YT48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj7igJRKb2hu PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D216609683554CB68C61791AB87B16EDjunipernet_-- From nobody Wed Apr 15 14:06:30 2020 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 DF62F3A079B; Wed, 15 Apr 2020 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=tmZ3SWKj; dkim=pass (1024-bit key) header.d=juniper.net header.b=Wz8FgaYj 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 SNRCXNFAGr7T; Wed, 15 Apr 2020 14:06:27 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D5F3A079A; Wed, 15 Apr 2020 14:06:26 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03FL3ikQ032236; Wed, 15 Apr 2020 14:06:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Ex6IsXuvlFGip+Slm0wthXcb8Y83ixAXnPzMTqvV1SI=; b=tmZ3SWKj2E5SEWm+eb7KotZ/WhGvApvSkD0xsahwSmXiPYuKUaRKEHEjO5cnDvUBEmNa bln1wqu/g5yZoWWvGgpVm7hluiyB3+1SHEctaxM/c7lUk96tYtOR2nQl8VTY9iVO1eSq dINiiYoD7M9HQZ++ASQntNwdvIythoqcH23AJDxTlcizSIL+CQn2XwVYIJPK+CTSYSzg hlkPtaUIVgeqKxK0J/FRts1+Byd6oOj5U9HWziL6/ct6u8P0osT2yfDFeKalOqiNfbeD ZP8td6jrXEXhlv3dCdTwFDj0JqlBfkP8q79nrWeHK69fH1gai41lI0Wf4CXjmRriZLkk Sw== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by mx0a-00273201.pphosted.com with ESMTP id 30dnbj1vue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Apr 2020 14:06:26 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A7RxIXd7rPko329F2qis+dqFTcOaTVFcAFs3uM9+RxW4gq+sFOKSHPbqgBVOGXP8V251sUk/sZZr86jvGyWTYRA25jwr4LInzz8cyYlklbhSyeLUQiEy3qQWf+1LPCjJpmcv+tUbsmCW7p/8EYZUtnskHb7zqFheM1088JZiYLvIwQgocgBhBa+K8JYqTz98u8VGqKfA/2ebuayKqEO903aiJtpH/iYY4Tsjetjr6POPT2mVkaTbHa6vH0oOrSXbO8by+F0O6zuTfSJyJFcBhN8Tqs0/YN/uk89cGr+aO5ELMcj2vPnvKoowEshpMCTg791XsuGxt45zozW3KgsLXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ex6IsXuvlFGip+Slm0wthXcb8Y83ixAXnPzMTqvV1SI=; b=EQoxXuXbpU0f6Qmf9R3OD2ovPefvKYaSkS/I0G4qLVkcy3/K2ausQ5pM4ZGgl6c9weVkxI5nIN8Cdu7GKNKBbZyRBNiKi75qsM/NZcsm5UPqeM5umc+wTpt90UyNcPnsxQk/w1D0vuHj7eYI0q8H7udmcK1x2Cq4utHOWSbYSjG7Ns2hTKAr0gO7nQP4HFF/U35h4Fo+RnewN1HwWJxt75h41sVwidJGEHnvQpqn0ex32tln9WvppKnr7GqOw8LH/7dDVeSOwLzryTyBjRvEvN5pCIi5InxEVS4QGgrF/fUuiOs7Ll9jzhGo/NsYZbVtYmB1R1k/aCoZWmiNFqsekQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ex6IsXuvlFGip+Slm0wthXcb8Y83ixAXnPzMTqvV1SI=; b=Wz8FgaYjsd+RSXNRXUmeGv9n8RAhwWmWihDMWsby6DSFVGZgR4fGTy+AByhmq2mhJfoiLBYhZPf1//3QDlJX51ZiNhc6+wMZjv5hGPRsRqXFRJHeA1j0UM6tTXut4CGOLpJhIzCbjNQ7y299EX4oDOGc52WbJ9BoWTupVXJ46Pc= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB5539.namprd05.prod.outlook.com (2603:10b6:208:6b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.18; Wed, 15 Apr 2020 21:06:23 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 21:06:23 +0000 From: John Scudder To: Hares Susan CC: "idr@ietf.org" , "draft-ietf-idr-rfc8203bis@ietf.org" Thread-Topic: Shepherd initial report on RFC8203bis Thread-Index: AdUdxFK+5yu67cZcSua+jSTsHxRVSj1pKusAAAAuMQA= Date: Wed, 15 Apr 2020 21:06:23 +0000 Message-ID: References: <079f01d51dc6$00d6b9a0$02842ce0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-originating-ip: [2600:1700:37a0:3ca0:e133:e45c:a238:c10d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9547ef3d-7ece-4b44-ae1a-08d7e180da58 x-ms-traffictypediagnostic: BL0PR05MB5539: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(366004)(136003)(376002)(39860400002)(346002)(396003)(4743002)(316002)(71200400001)(2906002)(91956017)(8676002)(53546011)(81156014)(6506007)(478600001)(6486002)(36756003)(4326008)(8936002)(33656002)(76116006)(2616005)(66446008)(66556008)(6916009)(86362001)(5660300002)(64756008)(66476007)(6512007)(4744005)(54906003)(186003)(66946007); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8bN3TL8ECiKpLyMdBmKj+vMM8fotHkC5wMJBjh8XFwBwc92v+BwgQdatev5I9x5b69hL1kmWLtSK+YGdpR8FrUnZ0s0ZQ8vDCZhVDmnEVk/jEpf64HictKtTdef+lkbg5cuWQo9VvUIOGqd1b/jqCmTzpXDAIT2PxYnciG797QY9AHsR/49Fg0B/JNZATig0fyEr0AvmyP1M1UxbNHznwT/eEEKdXgA9m+7pCHYodZD8T5vrzRwP5xgfzWEFCjpvbDDKTc7HVfuzXHg+GqFDVUmkkRuHqfvGM57+KaSNjiVbDx8e5a3Oo7bLh5Ec6Gnuxp36LRBHprF38jU10DbIpuSUkcnCLQI/XE8fVqipqFKzS6vSh/q0p6731IdO8mqRxqawNqdxFoAdnMr9ztABdCZQaRPnRumO8sRbGyVk1E6AK6h3O3adINUz6FrFmAMf x-ms-exchange-antispam-messagedata: T2rXsmQhifsAV5xG3q1N/LUusj6HKozBm43q9OuW4fzu46B9MJ0eT3Hzf+Fw66GA4WowEON5oulWiJR5c6pdUAHHtbzVObYu9zqHXwXTnP2lTZpLKqZE5+P3HI7ln8ODF365GQvCMbN4BQs0ulgTnyKMspo9Dtkk2CLN4QLxjYLpRrytZtsq/72nt/bMbX3RgMHwvnl6/O0PCm+d+mXTIQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FD0D1290B65141DE823938C883774DFBjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9547ef3d-7ece-4b44-ae1a-08d7e180da58 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 21:06:23.0473 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8/3udx/mRiFPke9vW34hZnMYT1nB9tfKApfk22rSCEidBR8P+4mKjjxkfLGpn3Zq X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5539 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-15_07:2020-04-14, 2020-04-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 impostorscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 mlxscore=0 spamscore=0 suspectscore=0 clxscore=1015 mlxlogscore=614 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004150158 Archived-At: Subject: Re: [Idr] Shepherd initial report on RFC8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 21:06:29 -0000 --_000_FD0D1290B65141DE823938C883774DFBjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJvYmxlbSBzb2x2ZWQhDQoNCk9uIEFwciAxNSwgMjAyMCwgYXQgNTowMSBQTSwgSm9obiBTY3Vk ZGVyIDxqZ3NAanVuaXBlci5uZXQ8bWFpbHRvOmpnc0BqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpJ IGRvbuKAmXQgdGhpbmsgdGhlcmXigJlzIGEgQkNQIDc4IHByb2JsZW0NCg0KSm9iIHJlbWluZGVk IG1lIHRoYXQgd2UgYWxyZWFkeSB0b29rIGNhcmUgb2YgdGhpcyBwcm9ibGVtIGluIFJGQyA4MjAz LCB3aGljaCBpbmNsdWRlcyB0aGUgdGV4dDoNCg0KICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRv IHRoYW5rIEVua2UgQ2hlbiBhbmQgVmluY2VudCBHaWxsZXQgZm9yDQogIHRoZWlyIHdvcmsgb24g W1JGQzQ0ODZdIGFuZCBncmFudGluZyB0aGUgcmVsYXRlZCByaWdodHMgdG8gdGhlIElFVEYNCiAg VHJ1c3QgcGVyIEJDUCA3OC4NCg0KSW4gb3RoZXIgd29yZHMsIEVua2UgYW5kIFZpbmNlbnQgaGF2 ZSBhbHJlYWR5IGdyYW50ZWQgdGhvc2UgcmlnaHRzLiBTbyB0aGlzIGlzIDEwMCUgY3V0LWFuZC1k cmllZC4gV2hldyENCg0KUmVnYXJkcywNCg0K4oCUSm9obg0K --_000_FD0D1290B65141DE823938C883774DFBjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClByb2JsZW0gc29sdmVkITxiciBjbGFzcz0iIj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPk9uIEFwciAxNSwgMjAyMCwgYXQgNTowMSBQTSwgSm9obiBTY3VkZGVyICZs dDs8YSBocmVmPSJtYWlsdG86amdzQGp1bmlwZXIubmV0IiBjbGFzcz0iIj5qZ3NAanVuaXBlci5u ZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi PkkNCiBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBhIEJDUCA3OCBwcm9ibGVtPC9zcGFuPjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkpv YiByZW1pbmRlZCBtZSB0aGF0IHdlIGFscmVhZHkgdG9vayBjYXJlIG9mIHRoaXMgcHJvYmxlbSBp biBSRkMgODIwMywgd2hpY2ggaW5jbHVkZXMgdGhlIHRleHQ6PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsmbmJzcDtUaGUgYXV0 aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEVua2UgQ2hlbiBhbmQgVmluY2VudCBHaWxsZXQgZm9y PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7dGhlaXIgd29yayBvbiBbUkZDNDQ4Nl0gYW5kIGdy YW50aW5nIHRoZSByZWxhdGVkIHJpZ2h0cyB0byB0aGUgSUVURjxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwO1RydXN0IHBlciBCQ1AgNzguPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBvdGhlciB3b3Jkcywg RW5rZSBhbmQgVmluY2VudCBoYXZlIGFscmVhZHkgZ3JhbnRlZCB0aG9zZSByaWdodHMuIFNvIHRo aXMgaXMgMTAwJSBjdXQtYW5kLWRyaWVkLiBXaGV3ITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlEpvaG48L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FD0D1290B65141DE823938C883774DFBjunipernet_-- From nobody Wed Apr 15 14:18:01 2020 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 24A573A0814; Wed, 15 Apr 2020 14:17:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk CC: Susan Hares , shares@ndzh.com, idr@ietf.org, aretana.ietf@gmail.com, idr-chairs@ietf.org, draft-ietf-idr-capabilities-registry-change@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158698546099.28250.9860009472463637912@ietfa.amsl.com> Date: Wed, 15 Apr 2020 14:17:41 -0700 Archived-At: Subject: [Idr] Last Call: (Revision to Capability Codes Registration Procedures) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 21:17:42 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Revision to Capability Codes Registration Procedures' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-04-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Reserved for Private Use" is divided into three new ranges, respectively designated as "First Come First Served", "Experimental Use" and "Reserved". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Apr 16 02:02:27 2020 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 08F2D3A1288; Thu, 16 Apr 2020 02:02:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <158702773500.19221.16668128443031707230@ietfa.amsl.com> Date: Thu, 16 Apr 2020 02:02:15 -0700 Archived-At: Subject: [Idr] Murray Kucherawy's No Objection on draft-ietf-idr-rfc5575bis-20: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 09:02:21 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-idr-rfc5575bis-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I hope all routing documents are this easy to follow. All I have are minor nits: Section 1: * "... manually as well as automatically. The latter by systems that ..." -- change ". The" to ", the", because the second half of this isn't a sentence by itself. Just join them. Section 7.2: The "TBD" here feels like it's dangling. I realize it's dealt with in the IANA considerations, which is Section 11.3, but I had to jump around to make sure. I imagine I'm more accustomed to an RFC Editor note or some such when I run into these. You might consider saying in Section 11.3 that this is the thing described in Section 7.2, or vice versa. Appendix A: Should the copyright date be updated? From nobody Thu Apr 16 03:41:40 2020 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 6C2173A140B; Thu, 16 Apr 2020 03:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.447 X-Spam-Level: * X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 LV3vfJ2Ojhun; Thu, 16 Apr 2020 03:41:36 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 4BD053A1410; Thu, 16 Apr 2020 03:41:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'John Scudder'" Cc: , References: <079f01d51dc6$00d6b9a0$02842ce0$@ndzh.com> In-Reply-To: Date: Thu, 16 Apr 2020 06:41:31 -0400 Message-ID: <002001d613db$97eb63c0$c7c22b40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01D613BA.10DB9880" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK/uSZT6gTRrFPcyfzZCbml8vb+ZQKO2WhKppPN8QA= Content-Language: en-us X-Antivirus: AVG (VPS 200415-0, 04/15/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Shepherd initial report on RFC8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 10:41:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01D613BA.10DB9880 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable John: =20 Thank you for the changes. This draft is ready to go.=20 =20 Sue Hares=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder Sent: Wednesday, April 15, 2020 5:01 PM To: Hares Susan Cc: idr@ietf.org; draft-ietf-idr-rfc8203bis@ietf.org Subject: Re: [Idr] Shepherd initial report on RFC8203bis =20 (Coauthor hat on)=20 =20 Hi Sue, =20 I=E2=80=99ve uploaded -06 which I think resolves your issues. The idnits = issue is a little involved but the summary is =E2=80=9Cidnits is being = too picky=E2=80=9D, I go into more detail below. =20 On Jun 8, 2019, at 2:47 AM, Susan Hares wrote: =20 Status: Almost ready, 3 required editorial and need for implementation = report revision.=20 =20 = = https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/shepherdwriteu= p/ =20 Issues: key editorial things for IESG submission need to be addressed:=20 =20 1) RFC8203 must be mentioned in the introduction as well as current = references (top of front page, Abstract) =20 Done. 2) NITS need to be resolved =20 found: Need for different boiler plate or resolution on generation=20 =20 -- The document seems to lack a disclaimer for pre-RFC5378 work, but = may have content which was first submitted before 10 November 2008. If = you have contacted all the original authors and they are all willing to = grant the BCP78 rights to the IETF Trust, then this is fine, and you can = ignore this comment. If not, you may need to add the pre-RFC5378 = disclaimer.=20 (See the Legal Provisions document at = https://trustee.ietf.org/license-info for more information.) =20 If this is in error and you are using XML conversion, please inquire on = xml2rfc tool list.=20 =20 I don=E2=80=99t think there=E2=80=99s a BCP 78 problem and I = don=E2=80=99t think there=E2=80=99s an xml2rfc problem. (There=E2=80=99s = kind of an idnits problem, see next paragraph.) Let me explain, although = please imagine a chorus chanting =E2=80=9CI am not a lawyer and this is = not legal advice=E2=80=9D in the background. BCP 78 says we (the = authors) grant the IETF Trust various rights, including to produce = derivative works, blah blah. Now, if our document was itself a = modification of a previous document, we might not be the only authors = and might not have authority to grant those rights. But, although our = header says =E2=80=9CUpdates: 4486=E2=80=9D it doesn=E2=80=99t actually = include text from RFC 4486, certainly not text beyond that which would = be allowed by fair use. As such, I don=E2=80=99t think we need Enke or = Vincent to sign off. I think it=E2=80=99s also the case that this = determination is on us as authors to make, not on the IETF.=20 =20 Actually I=E2=80=99m not sure why idnits applies the BCP 78 check = against the updated documents. I=E2=80=99ve raised this with Henrik, but = I don=E2=80=99t think it needs to hold up progress of our document = =E2=80=94 a diligent document shepherd might ask the authors = =E2=80=9Care you sure?=E2=80=9D which you=E2=80=99ve now done, and thank = you for that. I, for one, am sure. As we both know, idnits is just a = suggestion, it=E2=80=99s not required to run clean, it=E2=80=99s = guidance for the shepherd. =20 By the way, for some reason idnits runs clean when I submit the = document, but if I run standalone idnits it throws the error = you=E2=80=99ve mentioned. Not sure why that is. Maybe the submission = mode suppresses miscellaneous warnings, or maybe it=E2=80=99s a bug. 3) IN section: 5. IANA Considerations =20 Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ =20 The actual registry name is in the new text. =20 =20 Done. =20 4) Implementation report for OPENBSD and BIRD need to be completed = or explained.=20 (yes/no) in each category is not understandable. =20 =20 I removed the implementation section entirely, since it was supposed to = be removed by the RFC Editor anyway and since we have an implementation = report available at = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis =20 Thanks, =20 =E2=80=94John ------=_NextPart_000_0021_01D613BA.10DB9880 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

John:

 

Thank you for the changes.=C2=A0 This draft is ready to go. =

 

Sue Hares

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of John = Scudder
Sent: Wednesday, April 15, 2020 5:01 PM
To: = Hares Susan
Cc: idr@ietf.org; = draft-ietf-idr-rfc8203bis@ietf.org
Subject: Re: [Idr] Shepherd = initial report on RFC8203bis

 

(Coauthor = hat on)

 

Hi Sue,

 

I=E2=80=99ve uploaded -06 which I think resolves your = issues. The idnits issue is a little involved but the summary is = =E2=80=9Cidnits is being too picky=E2=80=9D, I go into more detail = below.

 

On Jun 8, 2019, at 2:47 AM, Susan Hares <shares@ndzh.com> = wrote:

 

Status:&nbs= p; Almost ready,  3 required editorial and need for implementation = report revision. 

 =

 =

Issues:&nbs= p; key editorial things for IESG submission need to be addressed: 

 =

1)      RFC8203 = must be mentioned in the introduction as well as current references (top = of front page, = Abstract)

 

Done.



2)      NITS need = to be resolved

 =

  = ;found: Need for different boiler plate or resolution on generation 

  = ;

  = ;-- The document seems to lack a disclaimer for pre-RFC5378 work, but = may

  = ;   have content which was first submitted before 10 November = 2008.  If you

  = ;   have contacted all the original authors and they are all = willing to grant

  = ;   the BCP78 rights to the IETF Trust, then this is fine, and = you can ignore

  = ;   this comment.  If not, you may need to add the = pre-RFC5378 disclaimer. 

  = ;   (See the Legal Provisions document = at

  = ;   https://trustee.ietf.org/license-info for more = information.)

 =

If this is = in error and you are using XML conversion, please inquire on xml2rfc = tool list. 

 

I don=E2=80=99t think there=E2=80=99s a BCP 78 problem = and I don=E2=80=99t think there=E2=80=99s an xml2rfc problem. = (There=E2=80=99s kind of an idnits problem, see next paragraph.) Let me = explain, although please imagine a chorus chanting =E2=80=9CI am not a = lawyer and this is not legal advice=E2=80=9D in the background. BCP 78 = says we (the authors) grant the IETF Trust various rights, including to = produce derivative works, blah blah. Now, if our document was itself a = modification of a previous document, we might not be the only authors = and might not have authority to grant those rights. But, although our = header says =E2=80=9CUpdates: 4486=E2=80=9D it doesn=E2=80=99t actually = include text from RFC 4486, certainly not text beyond that which would = be allowed by fair use. As such, I don=E2=80=99t think we need Enke or = Vincent to sign off. I think it=E2=80=99s also the case that this = determination is on us as authors to make, not on the = IETF. 

 

Actually I=E2=80=99m not sure why idnits applies the = BCP 78 check against the updated documents. I=E2=80=99ve raised this = with Henrik, but I don=E2=80=99t think it needs to hold up progress of = our document =E2=80=94 a diligent document shepherd might ask the = authors =E2=80=9Care you sure?=E2=80=9D which you=E2=80=99ve now done, = and thank you for that. I, for one, am sure. As we both know, idnits is = just a suggestion, it=E2=80=99s not required to run clean, it=E2=80=99s = guidance for the shepherd.

 

By the way, for some reason idnits runs clean when I = submit the document, but if I run standalone idnits it throws the error = you=E2=80=99ve mentioned. Not sure why that is. Maybe the submission = mode suppresses miscellaneous warnings, or maybe it=E2=80=99s a = bug.



3)      IN = section: 5.  IANA Considerations

 =

  = ;      Old:  /Cease Notification message = subcodes/

  = ;     New: /BGP Cease NOTIFICATION message = subcodes/

 =

  = ;  The actual registry name is in the new text. =  

 

Done.

 

4)      Implementat= ion report for OPENBSD and BIRD need to be completed or explained. 

(yes/no) = in each category is not understandable.  

 

I removed the implementation section entirely, since = it was supposed to be removed by the RFC Editor anyway and since we have = an implementation report available at ht= tps://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis

 

Thanks,

 

=E2=80=94John

------=_NextPart_000_0021_01D613BA.10DB9880-- From nobody Thu Apr 16 03:53:38 2020 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 412773A1442; Thu, 16 Apr 2020 03:53:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Cc: shares@ndzh.com, idr-chairs@ietf.org, Susan Hares , iesg-secretary@ietf.org, idr@ietf.org Message-ID: <158703441724.14133.4893936733187347383@ietfa.amsl.com> Date: Thu, 16 Apr 2020 03:53:37 -0700 Archived-At: Subject: [Idr] Publication has been requested for draft-ietf-idr-rfc8203bis-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 10:53:37 -0000 Susan Hares has requested publication of draft-ietf-idr-rfc8203bis-06 as Proposed Standard on behalf of the IDR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/ From nobody Thu Apr 16 14:02:38 2020 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 EC39F3A10C9; Thu, 16 Apr 2020 14:01:47 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158707090790.17830.7054617596304673976@ietfa.amsl.com> Date: Thu, 16 Apr 2020 14:01:47 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-21.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:01:49 -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 : Dissemination of Flow Specification Rules Authors : Christoph Loibl Susan Hares Robert Raszuk Danny McPherson Martin Bacher Filename : draft-ietf-idr-rfc5575bis-21.txt Pages : 37 Date : 2020-04-16 Abstract: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. Other applications (ie. centralized control of traffic in a SDN or NFV context) are also possible. Other documents may specify Flow Specification extensions. The information is carried via BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. This document obsoletes both RFC5575 and RFC7674. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-21 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-21 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 Apr 16 14:11:24 2020 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 6FA4C3A110E for ; Thu, 16 Apr 2020 14:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 DaoaudbKmBZf for ; Thu, 16 Apr 2020 14:11:16 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 EA8763A110B for ; Thu, 16 Apr 2020 14:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=Date:To:References:Message-Id:Subject:Mime-Version:Content-Type: From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OdkazJFXZSsw+diaR5OjjLFbP7ZChwUXpHsz2I2p9xc=; b=FNV/X22sVSnopgnIqcJgSQ0Jjk +YLRtBmdu5HVUJZbPa00t6CIaJdD5T5ptmMU+VU7uS+/Cj2jaaj7rTbfB6E8xungXIej6J4QtZNVA Lvqow5uHhNRgSmJadDYPnCwyIJ5zgS3lxEoLEujVLrr2tfqfB7DJGywJpvokj5K06n2AW7rFOK081 O3JcD5cYBzp1YRioK8FEfJtIINxqzmsxNHYGs4buu8MFvhYSkML5hUz6koOnLGHn9bZSop0WV9Qau LepiAnybp41pyVlFqQ5DrNldPqKeLyqzkc47Cg3DIbdittW49XLkUFYBM5TPQJZMndKXBnKVBUpbS sc2pObdQ==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPBmx-000OGX-8W for idr@ietf.org; Thu, 16 Apr 2020 23:11:13 +0200 From: Christoph Loibl Content-Type: multipart/alternative; boundary="Apple-Mail=_BB95CB6B-9AB0-4C00-A22A-7D4F5188592B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: References: <158707090832.17830.2874378176498907427@ietfa.amsl.com> To: IDR List Date: Thu, 16 Apr 2020 23:11:09 +0200 X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Thu, 16 Apr 2020 23:11:11 +0200 Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-ietf-idr-rfc5575bis-21.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:11:24 -0000 --Apple-Mail=_BB95CB6B-9AB0-4C00-A22A-7D4F5188592B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IDR,=20 I just uploaded the -21(!) revision of the rfc5575bis draft to correct = the nits pointed out by the latest reviews. A new version of I-D, draft-ietf-idr-rfc5575bis-21.txt has been successfully submitted by Christoph Loibl and posted to the IETF repository. Name: draft-ietf-idr-rfc5575bis Revision: 21 Title: Dissemination of Flow Specification Rules Document date: 2020-04-16 Group: idr Pages: 37 URL: = https://www.ietf.org/internet-drafts/draft-ietf-idr-rfc5575bis-21.txt = Status: = https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ = Htmlized: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-21 = Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis = Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc5575bis-21 = Cheers=20 Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_BB95CB6B-9AB0-4C00-A22A-7D4F5188592B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii IDR, 

I just uploaded the -21(!) revision of the rfc5575bis draft = to correct the nits pointed out by the latest reviews.

A new version of I-D, = draft-ietf-idr-rfc5575bis-21.txt
has been successfully submitted by = Christoph Loibl and posted to the
IETF repository.

Name: draft-ietf-idr-rfc5575bis
Revision: 21
Title: Dissemination of Flow Specification = Rules
Document = date: 2020-04-16
Group: idr
Pages: 37
URL: =            <= a = href=3D"https://www.ietf.org/internet-drafts/draft-ietf-idr-rfc5575bis-21.= txt" class=3D"" style=3D"font-family: Menlo-Regular; font-size: = 11px;">https://www.ietf.org/internet-drafts/draft-ietf-idr-rfc5575bis-21.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/
Htmlized: =       https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-21
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc5575bis-21

Cheers 
Christoph

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



= --Apple-Mail=_BB95CB6B-9AB0-4C00-A22A-7D4F5188592B-- From nobody Thu Apr 16 14:17:03 2020 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 C85A43A111C for ; Thu, 16 Apr 2020 14:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xYS9H1rQXlCN for ; Thu, 16 Apr 2020 14:17:00 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 744533A111B for ; Thu, 16 Apr 2020 14:17:00 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id f13so214492wrm.13 for ; Thu, 16 Apr 2020 14:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=opJXvh+FBwFRnAUcleHeitEz9qlQfmsn7+Ue8q757L8=; b=h9fZkLI0ILQ0RxhJ7G+oDnqtOs4u6+GgkDSAf6gN8FTroiD2byxTa/2HGIluZWs/Mn VKKR8ooPeG+mvrNb0d93Gm2FQ3bM8zJ55tzTXVQc+iFkCZTeU6lemnItfvJMPWE+1icW h97TXJDlgsFh201X+VrY8UNC5tz+AlsXHuF8RpfSLpRgP2m0CVfaGTwjhiTs7jm3zxnN Ugsd3LjSTn+j0kGmhfu80xdPFvVZARNB/RqdxRNQNxWX40j3MCeMTeB1Y4yKWndKPfoA jMAYW15IK+VsY05niVVBMCOKianirT/uIIIxSkO9xRCeW0Ayp7M980GIsfW2bJDD3HoS Y/Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=opJXvh+FBwFRnAUcleHeitEz9qlQfmsn7+Ue8q757L8=; b=Xibm9QsKKB1VoYEoBImDkdykZf2A134KjTv5vgJozgd9boI1ftK7fTr8M6ssVTSVx7 5i/DGLkmiXSsi9KUFi1VOtAXmb+LzZM8JE+QX3DvReclmRbgwXB9UcRDGZW8Qpx9B/JV blWpxk0xHjStonh5XYFEseUELWHCOo9c18TgnhsW15C4uUaKFYP3gvaWmvl0NOZAe7zM cBy3seWH7X1S541xPnkegd9kc+/bYMjtXBFu+yBzTVUb8op7ajFnrZsAObMkrLoMPbjN wpH3dUC5NKDpKz+Jek1fu2rZXtqyiC2Y9SJGIy2hgZ9OEgBt8s5XnzV2Y/qcbg8M9uhp HEpw== X-Gm-Message-State: AGi0PuaRFhuqDLau7UHX1Cb2pHCO7ofuW4/FZMscfZOcacTqAM+CGnVn pq+goGtv+oDTBfIF8yVnYKIXQh6wBSbekplYg0wxK1VD X-Google-Smtp-Source: APiQypJgNTYqahYFK3kt4kdayAwGayr8xspAkHntZ6N3bEBqrR37fYNVw8cp2pRopnfR6oIQMeMFDlUnk+w52Lk95/g= X-Received: by 2002:a5d:6b86:: with SMTP id n6mr160992wrx.113.1587071818401; Thu, 16 Apr 2020 14:16:58 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Apr 2020 14:16:57 -0700 From: Alvaro Retana In-Reply-To: References: <158707090832.17830.2874378176498907427@ietfa.amsl.com> MIME-Version: 1.0 Date: Thu, 16 Apr 2020 14:16:57 -0700 Message-ID: To: IDR List , Christoph Loibl Content-Type: multipart/alternative; boundary="000000000000f80d4d05a36ef396" Archived-At: Subject: Re: [Idr] Fwd: New Version Notification for draft-ietf-idr-rfc5575bis-21.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:17:02 -0000 --000000000000f80d4d05a36ef396 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! Just a counter-nit. In =C2=A77, the reference to rfc4360 (where the extended communities are defined) shouldn=E2=80=99t have changed to rfc7153 (a reorganization of the registries). Perhaps s/standardizes as BGP extended community values [RFC7153]/standardizes as BGP extended communities [RFC4360] Thanks! Alvaro. On April 16, 2020 at 5:11:44 PM, Christoph Loibl (c@tix.at) wrote: I just uploaded the -21(!) revision of the rfc5575bis draft to correct the nits pointed out by the latest reviews. --000000000000f80d4d05a36ef396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!

Just a counter-nit.

In =C2=A77, the reference to rfc4360 (where the extended commu= nities are defined) shouldn=E2=80=99t have changed to rfc7153 (a reorganiza= tion of the registries).

Perhaps s/standardizes as BGP extended community values [RFC7153]/sta= ndardizes as BGP extended communities [RFC4360]


Thanks!

Alvaro.

On April 16, 2020 at 5= :11:44 PM, Christoph Loibl (c@tix.at) wrote= :

I just uploaded the -21(!) revision of the rfc55= 75bis draft to correct the nits pointed out by the latest reviews.
--000000000000f80d4d05a36ef396-- From nobody Thu Apr 16 14:29:21 2020 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 D197C3A1133 for ; Thu, 16 Apr 2020 14:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 HDDIwbOyyL2u for ; Thu, 16 Apr 2020 14:29:17 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 E65A83A0A8E for ; Thu, 16 Apr 2020 14:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ejcAX+oUYWe5OsiTqnoHr22PIX+ScTL2CgAo/eWumwI=; b=EqY3kQz9MoXNy2zjmpJYgXZpcu +SaX3xZaWSn/pVSwDUWvFrYOf9jiS+xjPCVoKhfUl1agZl7JfxGWC5QDkwmIkjq91KZ9mu+AzcCEW M4nrzPNPF7ZT60Col1CPIYjcnQolJENoR06M3bpfhx5I2wU7IjNIUyVDY8ztltncRDtDA8mbGC5kN ZrSYzbVxuK71MD1K3nYHd2fdEBFHIREtzhFeY1ucPVi8CdqJstWrD9zihL5Hh+OYnTNXy13UO3EzU Qjotld5WDxNnia8DVIP7/uNPPSB1lU1NZ0HyqdGmn8rz4uGG+thKXltN3dZVwJt7RRT2SVrEYq4hi njl5EKmw==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPC4M-000PiH-VZ; Thu, 16 Apr 2020 23:29:14 +0200 From: Christoph Loibl Message-Id: <1D2BE75C-A806-4641-BB54-C268DF9ECF30@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D8890DC-0A06-4BC1-886F-DA54C59B998A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Thu, 16 Apr 2020 23:29:09 +0200 In-Reply-To: Cc: IDR List To: Alvaro Retana References: <158707090832.17830.2874378176498907427@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Thu, 16 Apr 2020 23:29:11 +0200 Archived-At: Subject: Re: [Idr] New Version Notification for draft-ietf-idr-rfc5575bis-21.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:29:20 -0000 --Apple-Mail=_9D8890DC-0A06-4BC1-886F-DA54C59B998A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alvaro, I have taken some notes about this change in github which I did not send = out yet: The original suggestion for this change this was from: Reviewer: Gyan Mishra Nits/editorial comments: 7. Traffic Filtering Actions This document defines a minimum set of Traffic Filtering Actions that it standardizes as BGP extended community values [RFC4360] Any mention of [RFC4360] should be updated with [RFC7153] IANA = Registries for BGP Extended Communities. This is from the notes on github that will go with the changes = (tomorrow): Since the paragraph is about the value not the BGP extended community = itself I think this is feasible. However there is another Section 7.4. = with a reference to RFC 4360 this is about technical aspects and = encoding into the extended community values (pointing directly to = sections of RFC 4360). I think this reference should not be changed. However I have no strong opinion about the change in section 7. both = documents are closely related one about the technical aspects (this is = why I did not change section 7.4) and the other about organisation of = the codepoints/values. I can revert this reverence to point to RFC4360 again (which it = initially did). Cheers=20 Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 16.04.2020, at 23:16, Alvaro Retana wrote: >=20 > Hi! >=20 > Just a counter-nit. >=20 > In =C2=A77, the reference to rfc4360 (where the extended communities = are defined) shouldn=E2=80=99t have changed to rfc7153 (a reorganization = of the registries). >=20 > Perhaps s/standardizes as BGP extended community values = [RFC7153]/standardizes as BGP extended communities [RFC4360] >=20 >=20 > Thanks! >=20 > Alvaro. >=20 > On April 16, 2020 at 5:11:44 PM, Christoph Loibl (c@tix.at = ) wrote: >=20 >> I just uploaded the -21(!) revision of the rfc5575bis draft to = correct the nits pointed out by the latest reviews. --Apple-Mail=_9D8890DC-0A06-4BC1-886F-DA54C59B998A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alvaro,

I have taken = some notes about this change in github which I did not send out = yet:

The = original suggestion for this change this was from:

Reviewer: Gyan Mishra

Nits/editorial comments:
7. Traffic Filtering = Actions
This document = defines a minimum set of Traffic Filtering Actions that
it standardizes as BGP = extended community values [RFC4360]

Any mention = of [RFC4360] should be updated with [RFC7153] IANA Registries for BGP = Extended Communities.

This is from the notes on github that will go with the = changes (tomorrow):

Since the paragraph is = about the value not the BGP extended community = itself I think this is feasible. However there is another Section 7.4. = with a reference to RFC 4360 this is about technical aspects and = encoding into the extended community values (pointing directly to = sections of RFC 4360). I think this reference should not be = changed.

However I have no strong opinion about the change in section = 7. both documents are closely related one about the technical aspects = (this is why I did not change section 7.4) and the other about = organisation of the codepoints/values.

I can revert this reverence to point to = RFC4360 again (which it initially did).

Cheers 
Christoph

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



On 16.04.2020, at 23:16, Alvaro Retana <aretana.ietf@gmail.com> wrote:

Hi!

Just a counter-nit.

In =C2=A77, the reference to rfc4360 = (where the extended communities are defined) shouldn=E2=80=99t have = changed to rfc7153 (a reorganization of the registries).

Perhaps s/standardizes as BGP = extended community values [RFC7153]/standardizes as BGP extended = communities [RFC4360]


Thanks!

Alvaro.

On April 16, 2020 at 5:11:44 PM, Christoph Loibl = (c@tix.at) = wrote:

I just uploaded the -21(!) revision of the = rfc5575bis draft to correct the nits pointed out by the latest = reviews.

= --Apple-Mail=_9D8890DC-0A06-4BC1-886F-DA54C59B998A-- From nobody Thu Apr 16 14:37:19 2020 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 147AA3A1159; Thu, 16 Apr 2020 14:37:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen via Datatracker To: Cc: last-call@ietf.org, draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158707303702.29618.1988434087474669117@ietfa.amsl.com> Reply-To: Jouni Korhonen Date: Thu, 16 Apr 2020 14:37:17 -0700 Archived-At: Subject: [Idr] Genart last call review of draft-ietf-idr-bgp-ls-segment-routing-msd-16 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:37:18 -0000 Reviewer: Jouni Korhonen Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-idr-bgp-ls-segment-routing-msd-?? Reviewer: Jouni Korhonen Review Date: 2020-04-16 IETF LC End Date: 2020-04-17 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as a standards track document. Major issues: none. Minor issues: none. Nits/editorial comments: IDnits complain about lines too long i.e. the table in the IANA considerations section. That should be corrected and I checked there is enough space to cut the required 8 chars. From nobody Thu Apr 16 15:18:36 2020 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 3CD313A1237 for ; Thu, 16 Apr 2020 15:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nlzyGN6dl_GO for ; Thu, 16 Apr 2020 15:18:34 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 C317F3A1236 for ; Thu, 16 Apr 2020 15:18:33 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id d77so641621wmd.3 for ; Thu, 16 Apr 2020 15:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=pUEt5HHLczKSaj1uqnyqzD+9l9GdvrxGfDi7eXM8GJA=; b=QcQHNVr/9kakQ/p7JCxk/oAHxemtNfWiX2dGcmJCSRIx2VXzsaSCR9Int5qcsBdama QssoxhQJdHPTIlMv6fHGuq+WXi5nkJx5YpatotZ0dbqCqQBAapF76wTZSKKVNAwz5mWj S+E9BzjJKKHR11l7D8Ri8IAhS1eEtVlwmA5fv/qHpy83kZ4qN6OcEMpeGuwO72jcxT2I dlk7CA1NR7tIT0+zU7MFsa7FVuDskXD1Z1GGZ3MmwLLvQpZoj7gqi84T8F5c1WHqjKjq 7yAIcF2dTZzSSxY/L68wRW735k+ybIhMlqvztHiAQEIa9C5P9vap3h2V+CPvqGHl2mIj p2Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=pUEt5HHLczKSaj1uqnyqzD+9l9GdvrxGfDi7eXM8GJA=; b=j43HLuUe4Odvr0nSALP+nc0u7lCZhzzMG4rHKq9tAMbX0BfC9L5he/vdbJYu4nJ7P2 XRFXtBcs9gYh0Cw4++YegDT2NFZNpUnvwF4ueUMW3t3arpddIFdvo0LTKwgVO3OORju/ YC1I/u18Jp7IQ9whFi9q6y0oYIdm0x+xGd2oKDe2JP5+mlRJt8FHzHtIFioMetNxwJtI Vl0xPlXnSmqI3o0OSJvZ9qmeIGPDmCkcXu9m5glTUA+uVnFlPh0ANkpr4/oQ96Z5CwSS S7YniJk+7jCiyMwYTe/I92MVUa5AJ60ML6dcCNGTBCevoYjUvKv1PeeGnDV8Rr0IbLx/ 0YUA== X-Gm-Message-State: AGi0Puai5N2plVG5yLQVYa+MuMTF1ypf45azxPyhQ68zBQ6WXCHU/DyD OUqikvoVHiSVGc3otd7O7GifPgVHPpNJVoAeTsM4IBm9 X-Google-Smtp-Source: APiQypJmnjFYCWNCaaGzihV2zWL17/er7bqde5lPGC9MQsYG4IrDl0H76JoryuthkxsXeXBhv46C7oSPI/KohV5Xewo= X-Received: by 2002:a7b:c755:: with SMTP id w21mr52590wmk.120.1587075512054; Thu, 16 Apr 2020 15:18:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Apr 2020 15:18:31 -0700 From: Alvaro Retana In-Reply-To: <1D2BE75C-A806-4641-BB54-C268DF9ECF30@tix.at> References: <158707090832.17830.2874378176498907427@ietfa.amsl.com> <1D2BE75C-A806-4641-BB54-C268DF9ECF30@tix.at> MIME-Version: 1.0 Date: Thu, 16 Apr 2020 15:18:31 -0700 Message-ID: To: Christoph Loibl Cc: IDR List Content-Type: multipart/alternative; boundary="00000000000020c73505a36fd05f" Archived-At: Subject: Re: [Idr] New Version Notification for draft-ietf-idr-rfc5575bis-21.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 22:18:35 -0000 --00000000000020c73505a36fd05f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah=E2=80=A6that=E2=80=99s why I suggested this change: s/standardizes as = BGP extended community values [RFC7153]/standardizes as BGP extended communities [RFC4360] We=E2=80=99re standardizing the Traffic Filtering actions as ECs, not as va= lues.. Thanks! Alvaro. On April 16, 2020 at 5:29:15 PM, Christoph Loibl (c@tix.at) wrote: Since the paragraph is about the value not the BGP extended community itself I think this is feasible. However there is another Section 7.4. with a reference to RFC 4360 this is about technical aspects and encoding into the extended community values (pointing directly to sections of RFC 4360). I think this reference should not be changed. --00000000000020c73505a36fd05f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Yeah=E2=80=A6that=E2=80=99s why I suggested this= change: s/standardizes as BGP extended community values [RFC7153]/standard= izes as BGP extended communities [RFC4360]

We=E2=80=99re standardizing the Traffic Filtering a= ctions as ECs, not as values..=C2=A0

Thanks!

Alvaro.

On April 16, 2020 at 5:29:= 15 PM, Christoph Loibl (c@tix.at) wrote:

Sin= ce the paragraph is about the=C2=A0value=C2=A0not the BGP extended community itself I think this is f= easible. However there is another Section 7.4. with a reference to RFC 4360= this is about technical aspects and encoding into the extended community v= alues (pointing directly to sections of RFC 4360). I think this reference s= hould not be changed.

<= /div>
--00000000000020c73505a36fd05f-- From nobody Fri Apr 17 00:17:13 2020 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 29E593A0F64; Fri, 17 Apr 2020 00:16:55 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158710781510.26505.10504635703920675387@ietfa.amsl.com> Date: Fri, 17 Apr 2020 00:16:55 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-22.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:16:55 -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 : Dissemination of Flow Specification Rules Authors : Christoph Loibl Susan Hares Robert Raszuk Danny McPherson Martin Bacher Filename : draft-ietf-idr-rfc5575bis-22.txt Pages : 37 Date : 2020-04-17 Abstract: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. Other applications (ie. centralized control of traffic in a SDN or NFV context) are also possible. Other documents may specify Flow Specification extensions. The information is carried via BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. This document obsoletes both RFC5575 and RFC7674. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-22 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-22 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 Fri Apr 17 00:24:08 2020 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 C99D93A0F88 for ; Fri, 17 Apr 2020 00:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=tix.at 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 53X9vrBBYQrP for ; Fri, 17 Apr 2020 00:23:57 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 929E93A0F84 for ; Fri, 17 Apr 2020 00:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=Message-Id:In-Reply-To:To:References:Date:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=embqzWG48wzh/HxIVI0s8bDZGm1ArTBH+K3IZKFP6Hg=; b=EEmB0QMmUi2h/sxchb97XzOZ/B 4nMj73JkdPTDYdfcklCdERm3rjnbctf6g+D0niScliG/BULsk6Ddr/Foojalsz0/JhRM9C0PR1vZQ 2FrLMHtXo17W4cVXZK/2syaeM6Baho/ZQYHAUoMtidtG3jaseVIj1jPYh9CofHZV2k5YN95Qq+djN AHLVUem5SHs+bx/k2tShl57UehfuKnhKIjhzWo5RAPtB8sYs1SwXpbbzxzfAO2UNXRNgz0ieVlGqo MHKH5nV9zWp9uode2Rq9Ow1Ig6paGfDAl1giy9l1Py+23MZ9BeZpO5naZvmAPzfwavPfsfdihrhXz Xp2TkKuQ==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPLLM-000Ph8-VJ for idr@ietf.org; Fri, 17 Apr 2020 09:23:21 +0200 From: Christoph Loibl Content-Type: multipart/alternative; boundary="Apple-Mail=_C4534E4E-B52B-4E1A-A0DB-D514E2DDBB3A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 17 Apr 2020 09:23:15 +0200 References: <158710781510.26505.10504635703920675387@ietfa.amsl.com> To: idr@ietf.org In-Reply-To: <158710781510.26505.10504635703920675387@ietfa.amsl.com> Message-Id: <6A6DFA52-A782-4D53-8AC3-E3376FBE1745@tix.at> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 17 Apr 2020 09:23:21 +0200 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-22.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:24:07 -0000 --Apple-Mail=_C4534E4E-B52B-4E1A-A0DB-D514E2DDBB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I uploaded the -22 solving the nit from Alvaro: > On 17.04.2020, at 00:18, Alvaro Retana wrote: >=20 > Yeah=E2=80=A6that=E2=80=99s why I suggested this change: = s/standardizes as BGP extended community values [RFC7153]/standardizes = as BGP extended communities [RFC4360] >=20 The changes are tracked on Github: https://github.com/stoffi92/rfc5575bis = I also moved the python source of flowspec-cmp to the same repo so that = the work on the draft and the source of flowspec-cmp are in a single = repo, which seems more natural. Cheers=20 Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 17.04.2020, at 09:16, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Dissemination of Flow Specification Rules > Authors : Christoph Loibl > Susan Hares > Robert Raszuk > Danny McPherson > Martin Bacher > Filename : draft-ietf-idr-rfc5575bis-22.txt > Pages : 37 > Date : 2020-04-17 >=20 > Abstract: > This document defines a Border Gateway Protocol Network Layer > Reachability Information (BGP NLRI) encoding format that can be used > to distribute traffic Flow Specifications. This allows the routing > system to propagate information regarding more specific components = of > the traffic aggregate defined by an IP destination prefix. >=20 > It also specifies BGP Extended Community encoding formats, that can > be used to propagate Traffic Filtering Actions along with the Flow > Specification NLRI. Those Traffic Filtering Actions encode actions = a > routing system can take if the packet matches the Flow = Specification. >=20 > Additionally, it defines two applications of that encoding format: > one that can be used to automate inter-domain coordination of = traffic > filtering, such as what is required in order to mitigate > (distributed) denial-of-service attacks, and a second application to > provide traffic filtering in the context of a BGP/MPLS VPN service. > Other applications (ie. centralized control of traffic in a SDN or > NFV context) are also possible. Other documents may specify Flow > Specification extensions. >=20 > The information is carried via BGP, thereby reusing protocol > algorithms, operational experience, and administrative processes = such > as inter-provider peering agreements. >=20 > This document obsoletes both RFC5575 and RFC7674. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-22 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-22 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc5575bis-22 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_C4534E4E-B52B-4E1A-A0DB-D514E2DDBB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = uploaded the -22 solving the nit from Alvaro:

On 17.04.2020, at 00:18, Alvaro Retana = <aretana.ietf@gmail.com> wrote:

Yeah=E2=80=A6that=E2=80=99s why I suggested this change: = s/standardizes as BGP extended community values [RFC7153]/standardizes = as BGP extended communities [RFC4360]


The changes are tracked on = Github:

https://github.com/stoffi92/rfc5575bis


I also moved the python source of flowspec-cmp to the same = repo so that the work on the draft and the source of flowspec-cmp are in = a single repo, which seems more natural.

Cheers 
Christoph

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



On 17.04.2020, at 09:16, internet-drafts@ietf.org wrote:


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 =           : = Dissemination of Flow Specification Rules
=        Authors =         : Christoph Loibl
=             &n= bsp;           &nbs= p;Susan Hares
=             &n= bsp;           &nbs= p;Robert Raszuk
=             &n= bsp;           &nbs= p;Danny McPherson
=             &n= bsp;           &nbs= p;Martin Bacher
Filename =        : = draft-ietf-idr-rfc5575bis-22.txt
Pages =           : 37
= Date =            : = 2020-04-17

Abstract:
=   This document defines a Border Gateway Protocol Network = Layer
  Reachability Information (BGP NLRI) = encoding format that can be used
  to = distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more = specific components of
  the traffic aggregate = defined by an IP destination prefix.

=   It also specifies BGP Extended Community encoding formats, = that can
  be used to propagate Traffic = Filtering Actions along with the Flow
=   Specification NLRI.  Those Traffic Filtering Actions = encode actions a
  routing system can take if = the packet matches the Flow Specification.

=   Additionally, it defines two applications of that encoding = format:
  one that can be used to automate = inter-domain coordination of traffic
=   filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a = second application to
  provide traffic = filtering in the context of a BGP/MPLS VPN service.
=   Other applications (ie. centralized control of traffic in a = SDN or
  NFV context) are also possible. =  Other documents may specify Flow
=   Specification extensions.

=   The information is carried via BGP, thereby reusing = protocol
  algorithms, operational experience, = and administrative processes such
  as = inter-provider peering agreements.

=   This document obsoletes both RFC5575 and RFC7674.


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

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-22
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis= -22

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc5575bis-2= 2


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

= --Apple-Mail=_C4534E4E-B52B-4E1A-A0DB-D514E2DDBB3A-- From nobody Fri Apr 17 00:38:56 2020 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 21C513A0FA6; Fri, 17 Apr 2020 00:38:54 -0700 (PDT) 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 McgVUi0I6NyR; Fri, 17 Apr 2020 00:38:49 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD933A0FA3; Fri, 17 Apr 2020 00:38:49 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3FD819EA79965F75B384; Fri, 17 Apr 2020 08:38:47 +0100 (IST) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 17 Apr 2020 08:38:46 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.249]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Fri, 17 Apr 2020 15:38:42 +0800 From: Mach Chen To: "" CC: "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , 'IDR List' Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt Thread-Index: AdYUgufIha3uMI7HSMyOkGGdwgKyaQ== Date: Fri, 17 Apr 2020 07:38:41 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:38:54 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRp bmctbXNkLTE2LnR4dA0KUmV2aWV3ZXI6IE1hY2ggQ2hlbg0KUmV2aWV3IERhdGU6IEFwcmlsIDE3 LCAyMDIwIA0KSUVURiBMQyBFbmQgRGF0ZTogDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU cmFjaw0KDQpTdW1tYXJ5Og0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBk b2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlv bi4NCg0KQ29tbWVudHM6DQpUaGlzIGRvY3VtZW50IGlzIGNsZWFybHkgd3JpdHRlbiBhbmQgZWFz eSB0byB1bmRlcnN0YW5kLg0KDQpNYWpvciBJc3N1ZXM6DQpObyBtYWpvciBpc3N1ZXMgZm91bmQu DQoNCk1pbm9yIElzc3VlczoNClRoZSBOb2RlIE1TRCBUTFYgYW5kIExpbmsgTVNEIFRMViBhcmUg ZGVzaWduZWQgdG8gYmUgYWJsZSB0byBjYXJyeSBtdWx0aXBsZSBNU0RzLiBJIGd1ZXNzIHRoaXMg aXMgZGVzaWduZWQgZm9yIGZ1dHVyZSBleHRlbnNpYmlsaXR5LCB3aGVyZSBhIE5vZGUgbWF5IGhh dmUgbXVsdGlwbGUgdHlwZXMgb2YgTVNELCByaWdodD8gQnV0IGZvciBlYWNoIHR5cGUsIGlzIGl0 IGFsbG93ZWQgdG8gY2FycnkgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIE1TRC1UeXBlL01TRC1WYWx1 ZSBwYWlyIG9yIG9ubHkgb25lIGluc3RhbmNlPyBGb3Igd2hpY2hldmVyIGNhc2UsIHRoZXJlIG5l ZWQgc29tZSB0ZXh0IHRvIGRlc2NyaWJlIHRoZSBydWxlIGFib3V0IHRoZSBzZW5kaW5nIGFuZCBy ZWNlaXZpbmcgcHJvY2VkdXJlcy4gRm9yIGV4YW1wbGUsIHdoZW4gbXVsdGlwbGUgaW5zdGFuY2Vz IGFsbG93ZWQsIGhvdyBkb2VzIGEgbm9kZSBkZWNpZGUgd2hpY2ggaW5zdGFuY2UgdGFrZXMgZWZm ZWN0OyBpZiBvbmx5IG9uZSBpbnN0YW5jZSBhbGxvd2VkIGFuZCBtdWx0aXBsZSBpbnN0YW5jZXMg cmVjZWl2ZWQsIGhvdyB0byBoYW5kbGUgdGhpcywgZGlzY2FyZCB0aGUgd2hvbGUgVExWLCBvciBv bmx5IHRoZSBmaXJzdCBpbnN0YW5jZSB0YWtlcyBlZmZlY3QgYW5kIHRoZSByZXN0IGlnbm9yZWQu ICANCg0KTml0czoNCjEuIA0KU2VjdGlvbiAxLA0Kcy9sZWFybi9sZWFybnMNCg0KMi4NClNlY3Rp b24gMyBhbmQgU2VjdGlvbiA0Og0KVGhlIFRMViBmb3JtYXQgb2YgTm9kZS9MaW5rIE1TRCBpcyBk ZWZpbmVkIGFzIGZvbGxvd3M6DQogICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgfCAgICAgICAgICAgICAgVHlwZSAgICAgICAgICAgICB8ICAgICAgICAgICAgIExl bmd0aCAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBNU0QtVHlwZSAgIHwg IE1TRC1WYWx1ZSAgICB8ICBNU0QtVHlwZS4uLiAgfCAgTVNELVZhbHVlLi4uIHwNCiAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCg0KU2luY2UgdGhlIE1TRC1UeXBlL01TRC1WYWx1ZSBwYWlycyBhcmUgdmFyaWFibGUg aW4gbGVuZ3RoLCB0aGUgYWJvdmUgZGVmaW5pdGlvbiBkb2VzIG5vdCByZWZsZWN0IHRoaXMsIHN1 Z2dlc3QgdG8gY2hhbmdlIHRoZSBmaWd1cmUgYXMgYmVsb3c6DQogICAgICAwICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDENCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgVHlwZSAgICAgICAgICAg ICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg Ly8gICAgTVNELVR5cGUgICB8ICBNU0QtVmFsdWUgICAgfCAgTVNELVR5cGUuLi4gIHwgIE1TRC1W YWx1ZS4uLiAvLw0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCg== From nobody Fri Apr 17 00:43:23 2020 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 610483A0FD1; Fri, 17 Apr 2020 00:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 pQZmKB76J9oy; Fri, 17 Apr 2020 00:43:18 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 20DD13A0FB8; Fri, 17 Apr 2020 00:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dguKkT6L0tRJg3kunZwNmQknMaJTBKin7B10aaGWBVI=; b=e7+SfkoI/ZFkEAWq6m3CUTus/g MRgURoxg07BnVD+/4xyPAtqPigO3iL3emBZ2lMXKDNFiSmqcx60tXvwL2CLyO3qJ6M8PYmmsvyB49 jB343HTslCgCZVGCUJmHUgsO01iPlrvFcQE5C+1aT6PAukp1ncUldOyUOWkD7b4vJObR51Dvco1mc tJ3TtaQ6HjNv3D2vk8cUsDSxxS5ltTkoXsjN6MnBH4oT1vu5Rwfx2EHRYYNUdCfeULh8LXg9H3q1h 4vVS91NM0prrv/bgitv8DHOMXyijKa31ja1ESd4PH76a0kSHP86LUeFu991r/HUyUieLANA0Eh5K/ xD4+kw3w==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPLec-0001M5-0o; Fri, 17 Apr 2020 09:43:14 +0200 From: Christoph Loibl Message-Id: <42014AE1-D058-486E-9E17-475D07A91885@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_28C4CD40-E6D6-437F-8AFF-EDA123E64E81" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 17 Apr 2020 09:43:12 +0200 In-Reply-To: <158629580378.13606.6350807287790835622@ietfa.amsl.com> Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org, IDR List To: Gyan Mishra References: <158629580378.13606.6350807287790835622@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 17 Apr 2020 09:43:14 +0200 Archived-At: Subject: Re: [Idr] Genart last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:43:22 -0000 --Apple-Mail=_28C4CD40-E6D6-437F-8AFF-EDA123E64E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Gyan, Thanks for your review. According to your review I made the following = changes to the document which is available now as revision -22: > On 07.04.2020, at 23:43, Gyan Mishra via Datatracker = wrote: >=20 > Reviewer: Gyan Mishra > Review result: Ready with Nits >=20 > Reviewer: Gyan Mishra > Review result: Ready with Minor Issues >=20 > Minor issues: > I am familiar with BGP Flow specification and would like to recommend = some > verbiage that may help in the introduction as far as explaining how = BGP flow > spec works. Ssince the introduction has been re-written with this = update, this > could be a possible addition to the draft. >=20 > This could be placed at the end of the introduction if desired. > BGP flow specification is a client-server model that allows for a more = granular > approach to DDOS mitigation than its predecessor, =E2=80=9CRemotely = Triggered Blackhole > (RTBF) which tagged a prefix with a community and sent it do a discard = next > hop. BGP flow spec has two main components, the =E2=80=9Ccontroller=E2=80= =9D being the BGP > speaker device which acts as the server side, which injects the new = flowspec > entry, and the client side which is the BGP speaker devices that = receives the > flowspec NLRI and acts on the instruction to match a particular flow = with Layer > 3 and Layer 4 parameters and then implements the hardware forwarding = action > requested. <--=20 Tracked via issue #163: = https://github.com/stoffi92/rfc5575bis/issues/163 I do not agree that BGP flowspec is a client-server model -only-. We can = propagate this NLRI over administrative domain borders as we do with IP = routing information, it follows the same mechanisms. We see such = solutions being deployed in the internet as inter provider DDoS = solutions. We actually had a paragraph in the darft that was explaining the = advantages over other approaches like RTBF but this has been removed = because it was pointed out that it is not relevant to the spec to = justify a well deployed technology. --> > Nits/editorial comments: > 7. Traffic Filtering Actions > This document defines a minimum set of Traffic Filtering Actions = that > it standardizes as BGP extended community values [RFC4360] >=20 > Any mention of [RFC4360] should be updated with [RFC7153] IANA = Registries > for BGP Extended Communities. >=20 <--=20 Tracked via issue #164: = https://github.com/stoffi92/rfc5575bis/issues/164 Commits mentions: = https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa2750fd376dc= 148d7a590369 = https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7d5c1822070b= 862247dfaead Removed the "values" statement (as suggested by Alvaro) from the draft = to make clear we are not talking about particular values but about = Extended Communities as specified in RFC4360. s/standardizes as BGP extended community values [RFC4360]/standardizes = as BGP extended communities [RFC4360]/ --> Cheers=20 Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_28C4CD40-E6D6-437F-8AFF-EDA123E64E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Gyan,

Thanks for your = review. According to your review I made the following changes to the = document which is available now as revision -22:

On 07.04.2020, at 23:43, Gyan Mishra via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Gyan Mishra
Review result: Ready with = Nits

Reviewer: Gyan Mishra
Review result: Ready with Minor Issues

Minor issues:
I am familiar with BGP Flow = specification and would like to recommend some
verbiage = that may help in the introduction as far as explaining how BGP flow
spec works.  Ssince the introduction has been re-written = with this update, this
could be a possible addition to the = draft.

This could be placed at the end of = the introduction if desired.
BGP flow specification is a = client-server model that allows for a more granular
approach= to DDOS mitigation than its predecessor, =E2=80=9CRemotely Triggered = Blackhole
(RTBF) which tagged a prefix with a community = and sent it do a discard next
hop.  BGP flow spec has = two main components, the =E2=80=9Ccontroller=E2=80=9D being the BGP
speaker device which acts as the server side, which injects = the new flowspec
entry, and the client side which is the = BGP speaker devices that receives the
flowspec NLRI and = acts on the instruction to match a particular flow with Layer
3 and Layer 4 parameters and then implements the hardware = forwarding action
requested.

<-- 
Tracked via issue #163: = https://github.com/stoffi92/rfc5575bis/issues/163

I do not agree that BGP flowspec is a = client-server model -only-. We can propagate this NLRI over = administrative domain borders as we do with IP routing information, it = follows the same mechanisms. We see such solutions being deployed in the = internet as inter provider DDoS solutions.

We= actually had a paragraph in the darft that was explaining the = advantages over other approaches like RTBF but this has been removed = because it was pointed out that it is not relevant to the spec to = justify a well deployed technology.
-->


Nits/editorial = comments:
7.  Traffic Filtering Actions
=   This document defines a minimum set of Traffic Filtering = Actions that
  it standardizes as BGP extended = community values [RFC4360]

  Any = mention of [RFC4360] should be updated with [RFC7153] IANA Registries
  for BGP Extended Communities.


<-- 
Tracked via issue #164: = https://github.com/stoffi92/rfc5575bis/issues/164
Commits mentions:
    https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa= 2750fd376dc148d7a590369
    https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7= d5c1822070b862247dfaead

Removed the = "values" statement (as suggested by Alvaro) from the draft to make clear = we are not talking about particular values but about  Extended = Communities as specified in RFC4360.
s/standardizes as BGP = extended community values [RFC4360]/standardizes as BGP extended = communities [RFC4360]/

-->

Cheers 
Christoph

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



= --Apple-Mail=_28C4CD40-E6D6-437F-8AFF-EDA123E64E81-- From nobody Fri Apr 17 00:45:22 2020 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 005F43A0FB8; Fri, 17 Apr 2020 00:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 Fz11rBjUN89L; Fri, 17 Apr 2020 00:45:17 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 018EB3A103B; Fri, 17 Apr 2020 00:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=3AksEctf0aAkRec7xX1ZqOXb0an0sQxFB0KOHRewg5s=; b=hX8HweVbSPvS0tiEZdfqmIw72c pzMeyc3/mT+XOyHz1SkC0lsyKs3znRN8IRKJcxNkX5HZ9aTjhGAa2RHbkZ5bMy6tjF6Lbi1gsuI3+ dZujCAG3Sar1iTwHZCYBlCIviRs5hTQxyAbZQ4i3fJBC/hs3DHTUKo5+PYH0ZnaQkn7h72CW8Qetv oP51BHLEwev0Ipuz9AE4qE0L4sFYipNIaSGHnwL0Y4XuBTlfbqXG5JtZmx4pIkqlqnVmWvkSMkAHD /ncaFDnsjTo98oMOOZH1MtO1vRUsmjEPBQGUu93p89FuBCfxgk6WeZXhGe0/xmboxK2a79MXGiqe6 wJ5PfR4w==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPLfj-0001T1-Kz; Fri, 17 Apr 2020 09:44:23 +0200 From: Christoph Loibl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 17 Apr 2020 09:44:21 +0200 In-Reply-To: <158643250722.20996.2687173728603121972@ietfa.amsl.com> Cc: secdir@ietf.org, last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org To: Yoav Nir References: <158643250722.20996.2687173728603121972@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 17 Apr 2020 09:44:23 +0200 Archived-At: Subject: Re: [Idr] [BULK] Secdir last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:45:21 -0000 --Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yoav, Thank you for your review. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 09.04.2020, at 13:41, Yoav Nir via Datatracker = wrote: >=20 > Reviewer: Yoav Nir > Review result: Ready >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. These = comments > were written primarily for the benefit of the security area directors.=20= > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > This one is ready, and the Security Considerations section is = remarkably > well-written. >=20 >=20 --Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Yoav,

Thank you for = your review.

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



On 09.04.2020, at 13:41, Yoav Nir via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Yoav Nir
Review result: Ready

I have reviewed this document as part of the = security directorate's ongoing
effort to review all IETF = documents being processed by the IESG. These comments
were = written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments = just like any other
last call comments.

This one is ready, and the Security Considerations section is = remarkably
well-written.



= --Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E-- From nobody Fri Apr 17 00:49:44 2020 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 57F003A0FC9; Fri, 17 Apr 2020 00:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 d4JLap4Wcnvu; Fri, 17 Apr 2020 00:49:37 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 70B413A0FC4; Fri, 17 Apr 2020 00:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yV3ICeLj5vrJjWVG9pVTOfuoc9FaeYpkNk1I9+E7wSY=; b=qnFw0PAeUs1f6ntRTJYWMHwe9L +d68/4LxSbYcLtuAAdqUgQuEnMNxMFJ3/j+N6C3j6mxHSLQNRzbhqPeW2VXlbMNWORcekScOF4Oqm eThRUnVvxTXdLuVeqApZJm0zvBB/2HjBJW5wpHnUu7NkoBBAFdymRqbIR9FCVdpe/SDAdwwwg1H02 jg8mBF/hqpiml+IjOHYqwsJWZ9CIfZADfKX8zZTV46WTLITQC7MkPCSsnWMuwbdaBE+3Q0rmAj0Y6 8svVnV4yf55qhzG1bbBIzr18tcJKYTi7GjYecrQLMvnw9ODe4/c+4OXd+kfJ481uExvbo2YXLiMID qrZ2tNIA==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPLkk-0001tJ-5C; Fri, 17 Apr 2020 09:49:35 +0200 From: Christoph Loibl Message-Id: <84E0C985-EC91-47B3-B0C2-62819F017C2F@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 17 Apr 2020 09:49:32 +0200 In-Reply-To: <158696856575.24074.9062191460091207808@ietfa.amsl.com> Cc: rtg-dir@ietf.org, idr@ietf.org, last-call@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org To: Ines Robles References: <158696856575.24074.9062191460091207808@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 17 Apr 2020 09:49:34 +0200 Archived-At: Subject: Re: [Idr] [BULK] Rtgdir telechat review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:49:40 -0000 --Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ines, Thanks for your review. According to your review I made the following = changes to the document which is available now as revision -22: > On 15.04.2020, at 18:36, Ines Robles via Datatracker = wrote: >=20 > Reviewer: Ines Robles > Review result: Has Nits >=20 > Review type: rtgdir - Telechat review > Requested version for review: 20 > Deadline: 2020-04-15 > Reviewer: Ines Robles >=20 ... > Nits: >=20 > 1- In the Introduction, it would be nice to mention how this draft = obsoletes > RFC7674 and point to appendix B when referring obsoleting RFC5575. >=20 > For example, This document obsoletes "Dissemination of Flow = Specification > Rules" [RFC5575], whose differences can be found in Appendix B. This = document > obsoletes also "Clarification of the Flowspec Redirect Extended > Community"[RFC7674] due to this document includes..... >=20 > - please expand iBGP --> Internal BGP (iBGP) >=20 <--=20 Tracked via issue #165: = https://github.com/stoffi92/rfc5575bis/issues/165 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd53111bf3787b50= 16503431a173 Introduction modified as suggested: ``` This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], the differences can be found in Appendix B. This document also obsoletes "Clarification of the Flowspec Redirect Extended Community" [RFC7674] since it incorporates the encoding of the BGP Flow Specification Redirect Extended Community in Section 7.4. ``` iBGP - changed as suggested. --> > 2- Section 4.2.1.1 >=20 > in "a - AND bit:..." > 2.1 - "the previous term" refers to a component? > 2.2 -nit: "...unset and and MUST..." =3D> "...unset and MUST..." >=20 <--=20 Tracked via issue #166: = https://github.com/stoffi92/rfc5575bis/issues/166 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b5375828e8b758e6ee1= a11bc2a59994 ad 2.1.: Actually it is the result of the previous {op, value} pair = (within a component). Usually components (defined in the next section) = are a list of muliple {op, value} pairs. The new changed text makes it a = little clearer: ``` a - AND bit: If unset, the result of the previous {op, value} pair is logically ORed with the current one. If set, the operation is a logical AND. =20 ``` --> > 3-nit Section 5: "...this draft specifies..." if it becomes RFC it = would be > nice to read "..this document specifies.." <--=20 Tracked via issue #167: = https://github.com/stoffi92/rfc5575bis/issues/167 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/6762310b2f3035b12a82e3bf15f7= 78a15ad969fa Solved as suggested --> Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Ines,

Thanks for your review. According to your review I made the = following changes to the document which is available now as revision = -22:


On 15.04.2020, at 18:36, Ines Robles via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Ines Robles
Review result: Has = Nits

Review type: rtgdir - Telechat = review
Requested version for review: 20
Deadline: 2020-04-15
Reviewer: Ines Robles

...

 Nits:

1- In the = Introduction, it would be nice to mention how this draft obsoletes
RFC7674 and point to appendix B when referring obsoleting = RFC5575.

For example, This document = obsoletes "Dissemination of Flow Specification
Rules" = [RFC5575], whose differences can be found in Appendix B. This = document
obsoletes also "Clarification of the Flowspec = Redirect Extended
Community"[RFC7674] due to this document = includes.....

- please expand iBGP --> = Internal BGP  (iBGP)


<-- 
Tracked via issue #165: = https://github.com/stoffi92/rfc5575bis/issues/165
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd531= 11bf3787b5016503431a173

Introduction = modified as suggested:
```
   This = document obsoletes "Dissemination of Flow Specification Rules"
   [RFC5575], the differences can be found in = Appendix B.  This document
   also = obsoletes
   "Clarification of the Flowspec = Redirect Extended Community" [RFC7674]
   since = it incorporates the encoding of the BGP Flow Specification
   Redirect Extended Community in Section 7.4.
```

iBGP - changed as = suggested.

-->

2- Section 4.2.1.1

in "a -  AND bit:..."
2.1 - = "the previous term" refers to a component?
2.2 -nit: = "...unset and and MUST..." =3D> "...unset and MUST..."


<-- 
Tracked via issue #166: = https://github.com/stoffi92/rfc5575bis/issues/166
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b5375828= e8b758e6ee1a11bc2a59994

ad 2.1.: = Actually it is the result of the previous {op, value} pair (within a = component). Usually components (defined in the next section) are a list = of muliple {op, value} pairs. The new changed text makes it a little = clearer:

```
   a - =  AND bit: If unset, the result of the previous {op, value} pair
      is logically ORed with the current one. =  If set, the operation is
      a = logical AND.  
```
-->

3-nit Section 5: "...this = draft specifies..." if it becomes RFC it would be
nice to = read "..this document specifies.."

<-- 
Tracked via issue #167: https://github.com/stoffi92/rfc5575bis/issues/167
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/6762310b2f3035b12= a82e3bf15f778a15ad969fa

Solved as = suggested
-->

Cheers

Christoph

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


= --Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA-- From nobody Fri Apr 17 01:03:29 2020 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 080C73A1000; Fri, 17 Apr 2020 01:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 1xtP2TE9g8jd; Fri, 17 Apr 2020 01:03:16 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 2081F3A100D; Fri, 17 Apr 2020 01:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+x1hYecLvi0ciPZfKbLLECjf+SENtVmjJpVxjztRoJc=; b=WrYXmQ3ayB7WMRLccJHPLl1XPH RVWha+qgHeaxonKfxvWuRgGdz3223MdUsHEkLHOQCfDEY+CJWI/mL/1+5P5QzYsQnZIlsZH7YnkB3 1pvs3b23Owf9Su3i5HUgSFzbY/U1rQqNQy0K0uafRyybyUPiA6v0Ap1tPTlPHZNzlST0CFJCPC9nJ QlztgF6y3lihj/bCFl+ebWdidlDV/UwkRoLlMZpDcePVXFlBJiGR7bRW0UqpfnCjRbr299yhmBF3I J7LAROiG1DzcoLAEAyMAuFoFGOyKlLLs7nOTfxZKKLRubMF6Diasi07Fg/PkXqLt5NJ1xGMTJyKGH OeDzs1uQ==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPLxr-00034V-0S; Fri, 17 Apr 2020 10:03:08 +0200 From: Christoph Loibl Message-Id: <615B5ACA-7AD2-459B-BE5E-8619B49D9053@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_6DEDBB54-456F-433B-9CE8-C1C48C871162" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 17 Apr 2020 10:03:05 +0200 In-Reply-To: <158702773500.19221.16668128443031707230@ietfa.amsl.com> Cc: The IESG , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com To: Murray Kucherawy References: <158702773500.19221.16668128443031707230@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 17 Apr 2020 10:03:07 +0200 Archived-At: Subject: Re: [Idr] [BULK] Murray Kucherawy's No Objection on draft-ietf-idr-rfc5575bis-20: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:03:23 -0000 --Apple-Mail=_6DEDBB54-456F-433B-9CE8-C1C48C871162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Thank you for the review. A new -22 is available that addresses the nits = you pointed out. > On 16.04.2020, at 11:02, Murray Kucherawy via Datatracker = wrote: >=20 > Murray Kucherawy has entered the following ballot position for > draft-ietf-idr-rfc5575bis-20: No Objection <..> > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I hope all routing documents are this easy to follow. All I have are = minor > nits: >=20 > Section 1: > * "... manually as well as automatically. The latter by systems that = ..." -- > change ". The" to ", the", because the second half of this isn't a = sentence by > itself. Just join them. <--=20 Tracked via issue #168: = https://github.com/stoffi92/rfc5575bis/issues/168 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/b6e78d9748a8d15b58f90bf97cbb= 831ec1fe854b Resolved as suggested. --> > Section 7.2: > The "TBD" here feels like it's dangling. I realize it's dealt with in = the IANA > considerations, which is Section 11.3, but I had to jump around to = make sure.=20 > I imagine I'm more accustomed to an RFC Editor note or some such when = I run > into these. You might consider saying in Section 11.3 that this is = the thing > described in Section 7.2, or vice versa. <--=20 Tracked via issue #169: = https://github.com/stoffi92/rfc5575bis/issues/169 I tried a couple of options, and all of them will result in = significantly more changes during final edit (since we need to remove = those cross references again later) and were not very satisifying. Since = it is only a single codepoint that needs to be assigned and TBD has only = 3 mentions which seem very clear I avoided making any changes. =20 --> > Appendix A: > Should the copyright date be updated? <--=20 Tracked via issue #170: = https://github.com/stoffi92/rfc5575bis/issues/170 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/f11639d8e578cc160083a5c2ea28= e439e7fec86e Updated this and also updated the original file in the referenced github = repo.=20 --> Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_6DEDBB54-456F-433B-9CE8-C1C48C871162 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

Thank = you for the review. A new -22 is available that addresses the nits you = pointed out.

On 16.04.2020, at 11:02, Murray Kucherawy via = Datatracker <noreply@ietf.org> wrote:

Murray Kucherawy has = entered the following ballot position for
draft-ietf-idr-rfc5575bis-20: No Objection

<..>

The document, along with other ballot = positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/=

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I hope all routing documents are = this easy to follow.  All I have are minor
nits:

Section 1:
* "... manually as = well as automatically.  The latter by systems that ..." --
change ". The" to ", the", because the second half of this = isn't a sentence by
itself.  Just join them.

<-- 
Tracked via issue #168: https://github.com/stoffi92/rfc5575bis/issues/168
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/b6e78d9748a8d15b5= 8f90bf97cbb831ec1fe854b

Resolved as = suggested.
-->

Section 7.2:
The "TBD" here feels like it's = dangling.  I realize it's dealt with in the IANA
considerations, which is Section 11.3, but I had to jump = around to make sure. 
I imagine I'm more accustomed = to an RFC Editor note or some such when I run
into these. =  You might consider saying in Section 11.3 that this is the = thing
described in Section 7.2, or vice versa.

<-- 
Tracked via issue #169: https://github.com/stoffi92/rfc5575bis/issues/169


I tried a couple of options, = and all of them will result in significantly more changes during final = edit (since we need to remove those cross references again later) and = were not very satisifying. Since it is only a single codepoint that = needs to be assigned and TBD has only 3 mentions which seem very clear I = avoided making any changes.
 
-->

Appendix A:
Should = the copyright date be updated?

<-- 
Tracked via issue #170: https://github.com/stoffi92/rfc5575bis/issues/170
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/f11639d8e578cc160= 083a5c2ea28e439e7fec86e

Updated this = and also updated the original file in the referenced github = repo. 
-->

Cheers
Christoph

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




= --Apple-Mail=_6DEDBB54-456F-433B-9CE8-C1C48C871162-- From nobody Fri Apr 17 01:08:10 2020 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 DF7A03A0FFE; Fri, 17 Apr 2020 01:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 wDP5MZ0JreaM; Fri, 17 Apr 2020 01:08:05 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 6B4453A101A; Fri, 17 Apr 2020 01:07:52 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id c23so354540vkc.0; Fri, 17 Apr 2020 01:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=26wMrjmiS/AHCVcBLqU5eSjUVBprvNjKeRY5Wd2TWFo=; b=VJD9uLAcLbYqYnEG+3YNdE1FwflwnFByrfXxxUo2365PwVpYRrvglugBZwusdNUoyX HUGW1AJ7zD4oD62WmVI1ypwzHS4DOOhdfsqPtYXY9HnF3W662MTYPX7GVAAh5pnKYdle A7zjF0cMJQzv/UrTQxLBP5BaBPikRw3jFCQS13uGOJdcaTw3JOBHN83Yheycx2HGPBkS GbxSZ2CncZOBRheDGfpZua9lO9o1mA18zslf+NfsPTTG6VO6dYHtFJ3jtJUDJGfY28Wg tf9L7UBGGuRU4lsAs0emIOL2dC1MhYT6lkJY1hkqwoy6uDiJ/0VzN6tbMYGzCMMgvYHj BE3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=26wMrjmiS/AHCVcBLqU5eSjUVBprvNjKeRY5Wd2TWFo=; b=L6t6E3m3r4K4qs/jmb1Fil+Z0oyO+e+OChigjuwiJbjw3/Kw+b6jnNQk/9+hBub6nA KuXFCKa0xOpqidKhMnl6NNnQlj34fHg3/DSu0LmVvRRT+8KbQlK3Pp6WytFWGY2FV8zl cT+pYcSdKqmwYtko7oIGzqfR+3iI5lRC5n+n5cBcHGZ7I5TIUZ4zFNqtMzBGv3E7MUCf Il0fdbUfsZcCZlCe20B+04N9SJy+jgAFFm7Jkmmy2J2s5OOA064zoqhqmg1uvflMWAO3 ryYTzDk2tsMs7vmmORfpu8wldLmsYVAk+DyvNCSVeS7eaBLbdecD2GrFvs3qDYamDdB+ wk5g== X-Gm-Message-State: AGi0PuYmPkDzxneOzGtxl+SJ9kjpGjsuwlCykQSiYyhP95q+EK106zv3 HIArfL8GWRlETJIrn5pVG1H7w7OmUcnFHzI+VDiOXFsK X-Google-Smtp-Source: APiQypLHvpjr247fkOHJ9h73lArsnDGOhTk+vXDu2Vp+8ZgnnO21tX8H+hObEx958n9HJ1ZCl/6+0Ptzt8S2BvSfksI= X-Received: by 2002:a1f:2a87:: with SMTP id q129mr1485976vkq.90.1587110871307; Fri, 17 Apr 2020 01:07:51 -0700 (PDT) MIME-Version: 1.0 References: <158696856575.24074.9062191460091207808@ietfa.amsl.com> <84E0C985-EC91-47B3-B0C2-62819F017C2F@tix.at> In-Reply-To: <84E0C985-EC91-47B3-B0C2-62819F017C2F@tix.at> From: Ines Robles Date: Fri, 17 Apr 2020 11:07:15 +0300 Message-ID: To: Christoph Loibl Cc: rtg-dir@ietf.org, idr@ietf.org, last-call@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000b4182505a3780bd1" Archived-At: Subject: Re: [Idr] [BULK] Rtgdir telechat review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:08:08 -0000 --000000000000b4182505a3780bd1 Content-Type: text/plain; charset="UTF-8" Thank you very much Christoph for addressing my comments. Have a nice day, Ines. On Fri, Apr 17, 2020 at 10:49 AM Christoph Loibl wrote: > Hi Ines, > > Thanks for your review. According to your review I made the following > changes to the document which is available now as revision -22: > > > On 15.04.2020, at 18:36, Ines Robles via Datatracker > wrote: > > Reviewer: Ines Robles > Review result: Has Nits > > Review type: rtgdir - Telechat review > Requested version for review: 20 > Deadline: 2020-04-15 > Reviewer: Ines Robles > > ... > > Nits: > > 1- In the Introduction, it would be nice to mention how this draft > obsoletes > RFC7674 and point to appendix B when referring obsoleting RFC5575. > > For example, This document obsoletes "Dissemination of Flow Specification > Rules" [RFC5575], whose differences can be found in Appendix B. This > document > obsoletes also "Clarification of the Flowspec Redirect Extended > Community"[RFC7674] due to this document includes..... > > - please expand iBGP --> Internal BGP (iBGP) > > > <-- > Tracked via issue #165: https://github.com/stoffi92/rfc5575bis/issues/165 > Commit mention: > https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd53111bf3787b5016503431a173 > > Introduction modified as suggested: > ``` > This document obsoletes "Dissemination of Flow Specification Rules" > [RFC5575], the differences can be found in Appendix B. This document > also obsoletes > "Clarification of the Flowspec Redirect Extended Community" [RFC7674] > since it incorporates the encoding of the BGP Flow Specification > Redirect Extended Community in Section 7.4. > ``` > > iBGP - changed as suggested. > > --> > > 2- Section 4.2.1.1 > > in "a - AND bit:..." > 2.1 - "the previous term" refers to a component? > 2.2 -nit: "...unset and and MUST..." => "...unset and MUST..." > > > <-- > Tracked via issue #166: https://github.com/stoffi92/rfc5575bis/issues/166 > Commit mention: > https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b5375828e8b758e6ee1a11bc2a59994 > > ad 2.1.: Actually it is the result of the previous {op, value} pair > (within a component). Usually components (defined in the next section) are > a list of muliple {op, value} pairs. The new changed text makes it a little > clearer: > > ``` > a - AND bit: If unset, the result of the previous {op, value} pair > is logically ORed with the current one. If set, the operation is > a logical AND. > ``` > --> > > 3-nit Section 5: "...this draft specifies..." if it becomes RFC it would be > nice to read "..this document specifies.." > > > <-- > Tracked via issue #167: https://github.com/stoffi92/rfc5575bis/issues/167 > Commit mention: > https://github.com/stoffi92/rfc5575bis/commit/6762310b2f3035b12a82e3bf15f778a15ad969fa > > Solved as suggested > --> > > Cheers > > Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > --000000000000b4182505a3780bd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much Christoph for addressing my comments.<= div>
Have a nice day,

Ines.

On = Fri, Apr 17, 2020 at 10:49 AM Christoph Loibl <c@tix.at> wrote:
Hi Ines,

Thanks for your review. According to your review I made th= e following changes to the document which is available now as revision -22:=


On 15.04.2020, at 18:36, Ines Roble= s via Datatracker <noreply@ietf.org> wrote:

Reviewer: Ines RoblesReview result: Has Nits

Review type: rtgdir - Telechat review
R= equested version for review: 20
Deadline: 2020-04-15
Reviewer: Ines R= obles

...

=C2=A0Nits:

1- In the Introduction, it would be nic= e to mention how this draft obsoletes
RFC7674 and point to appendix B wh= en referring obsoleting RFC5575.

For example, This document obsolete= s "Dissemination of Flow Specification
Rules" [RFC5575], whose= differences can be found in Appendix B. This document
obsoletes also &q= uot;Clarification of the Flowspec Redirect Extended
Community"[RFC7= 674] due to this document includes.....

- please expand iBGP --> Internal BGP = =C2=A0(iBGP)


<--=C2= =A0
Tracked via issue #165: https://github.com/stoffi92/rfc5575bis/= issues/165
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd53111bf3787b50= 16503431a173

Introduction modified as suggested:
```
=C2= =A0 =C2=A0This document obsoletes "Dissemination of Flow Specification= Rules"
=C2=A0 =C2=A0[RFC5575], the differences can be found in App= endix B.=C2=A0 This document
=C2=A0 =C2=A0also obsoletes
=C2=A0 =C2= =A0"Clarification of the Flowspec Redirect Extended Community" [R= FC7674]
=C2=A0 =C2=A0since it incorporates the encoding of the BGP Flow = Specification
=C2=A0 =C2=A0Redirect Extended Community in Section 7.4.```

iBGP - changed as suggested.

-->

<= /div>
2- Section 4.2.1.1

in "= ;a - =C2=A0AND bit:..."
2.1 - "the previous term" refers = to a component?
2.2 -nit: "...unset and and MUST..." =3D> &= quot;...unset and MUST..."


<--=C2=A0
Tracked via issue #166: https://github.com/st= offi92/rfc5575bis/issues/166
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b= 5375828e8b758e6ee1a11bc2a59994

ad 2.1.: Actually it is the resul= t of the previous {op, value} pair (within a component). Usually components= (defined in the next section) are a list of muliple {op, value} pairs. The= new changed text makes it a little clearer:

```
=C2=A0 =C2=A0a -= =C2=A0AND bit: If unset, the result of the previous {op, value} pair
= =C2=A0 =C2=A0 =C2=A0 is logically ORed with the current one.=C2=A0 If set, = the operation is
=C2=A0 =C2=A0 =C2=A0 a logical AND. =C2=A0
```
--= >

3-nit Sect= ion 5: "...this draft specifies..." if it becomes RFC it would be=
nice to read "..this document specifies.."

<--=C2=A0
Tracked via issue #167: https= ://github.com/stoffi92/rfc5575bis/issues/167
Commit mention: https://github.com/stoffi92/rfc5575bis/c= ommit/6762310b2f3035b12a82e3bf15f778a15ad969fa

Solved as suggest= ed
-->

Cheers

Christo= ph

--=C2=A0
Christoph Loibl
c@tix.at=C2=A0| CL8-RIPE | PGP= -Key-ID:=C2=A00x4B2C0055 |=C2=A0http://www.nextlayer.at


=
--000000000000b4182505a3780bd1-- From nobody Fri Apr 17 14:08:46 2020 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 E0F863A060A; Fri, 17 Apr 2020 14:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8SnbYdt9r-MC; Fri, 17 Apr 2020 14:08:38 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 397A33A05A4; Fri, 17 Apr 2020 14:08:37 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id k13so3392673wrw.7; Fri, 17 Apr 2020 14:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=AInDLumEJ9y9QQtm9TXTH7Bw0lLekZp1HhrVq+V7Y/c=; b=pqr/FmlLHFi6kiDnXW3XOAJeqidDBWCpgZVkDRA/5XPv+jqrFJVnw4zxiCJv3tqJFz B0KL34JQJ/wY08T7OKAHuwkbkGdCe4wgwCaDrtMo/AxcWrpMyzKe48AG3byMWkWGtH+i I6IpKy5eUuY2PzaLmylg/DULvW7re8RViE+4OohyToxFvEQP7aNDxgZHaY3GG6DkgbAi nPzWSz7A0VC0kSfRwP0Ph6eph8DPQX/WWNzDvZcz/MNwjkNOtB+Ifhmn5cS8V9irB9rU eE8NF1M/bbdtQaHCdrYWYJinBg0FbexrhA2w5c1twJ/B1vqdz7IosHlWj967B1Sh/zdk 3ftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=AInDLumEJ9y9QQtm9TXTH7Bw0lLekZp1HhrVq+V7Y/c=; b=G5l3Igp2rivf+zeXBFdFZ5csHPapq0Ols4jQCycrkXgK648VkhAeo4KIjoihTbyW3w 89SarDUZmGkvD2PWZ7qFvVFUKvxkjnGrNddE6JfoJwJPPyu6HyMKCEAy+iINJ09FMVvq d4aUyaiuSNPBKd8F/ufPVt95J3A2rzYY8c9csyiafdjj8m+o6mpc+vgaLAC/TLi/L2cu 234jGU1CMJlFPcM8IK9Nug2C0a/wRXfIf3+1IW/OwnJL8v8B7nVmeB2zkMzVhZQkLe6V 1yYNHb1ikliDVMP5nNMIGyUt4hZTOkzSUykwfpQM89D2OFXNASWLzpvmC3v5TdaNKtZ3 /Sbw== X-Gm-Message-State: AGi0PubY2T1BHeLxFAfGKdg7Yd1DZVQDsN4Dn/KxUq31+/3jySL0MdZz t0AcEEC/ng221kJ9QYSvPmTC+GKeQZGQ3WuOKywCsCjT X-Google-Smtp-Source: APiQypI+5varLGUWVnL8mi3qqJL0x+wQ0KHAVl/yF80w6HVSZWbPw2ZlaggFdre+6IcDOeBGupaM8kgljSUhyEUEobk= X-Received: by 2002:a5d:65c4:: with SMTP id e4mr5416059wrw.147.1587157714495; Fri, 17 Apr 2020 14:08:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 17 Apr 2020 14:08:33 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 17 Apr 2020 14:08:33 -0700 Message-ID: To: "" , Mach Chen Cc: "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , IDR List , "rtg-dir@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c6706205a382f366" Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 21:08:44 -0000 --000000000000c6706205a382f366 Content-Type: text/plain; charset="UTF-8" Mach: Hi! How are you? Thanks for the review!! Keep in mind that BGP-LS simply transports the information from the IGPs, so the ability to carry multiple instances/multiple values depends on the specification of the MSD itself, and any rules in the corresponding IGP RFCs. IOW, specifying that behavior for BGP-LS in this document is not needed. Take care! Alvaro. On April 17, 2020 at 3:38:55 AM, Mach Chen (mach.chen@huawei.com) wrote: Minor Issues: The Node MSD TLV and Link MSD TLV are designed to be able to carry multiple MSDs. I guess this is designed for future extensibility, where a Node may have multiple types of MSD, right? But for each type, is it allowed to carry multiple instances of MSD-Type/MSD-Value pair or only one instance? For whichever case, there need some text to describe the rule about the sending and receiving procedures. For example, when multiple instances allowed, how does a node decide which instance takes effect; if only one instance allowed and multiple instances received, how to handle this, discard the whole TLV, or only the first instance takes effect and the rest ignored. --000000000000c6706205a382f366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Mach:

Hi!=C2=A0 How are you?

Thanks for the review!!

Keep in mind that BGP-LS simply transports the infor= mation from the IGPs, so the ability to carry multiple instances/multiple v= alues depends on the specification of the MSD itself, and any rules in the = corresponding IGP RFCs.=C2=A0 IOW, specifying that behavior for BGP-LS in t= his document is not needed.


Take care!

Alvaro= .

On April 17, 2020 at 3:38:55 AM, Mach C= hen (mach.chen@huawei.com) wrot= e:

Minor Issues:=C2=A0
The Node MSD TLV and Link MSD TLV are designed t= o be able to carry multiple MSDs. I guess this is designed for future exten= sibility, where a Node may have multiple types of MSD, right? But for each = type, is it allowed to carry multiple instances of MSD-Type/MSD-Value pair = or only one instance? For whichever case, there need some text to describe = the rule about the sending and receiving procedures. For example, when mult= iple instances allowed, how does a node decide which instance takes effect;= if only one instance allowed and multiple instances received, how to handl= e this, discard the whole TLV, or only the first instance takes effect and = the rest ignored.=C2=A0=C2=A0
=
--000000000000c6706205a382f366-- From nobody Fri Apr 17 14:28:25 2020 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 5139B3A080C; Fri, 17 Apr 2020 14:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czU8krgFss-T; Fri, 17 Apr 2020 14:28:12 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 AC8653A07F8; Fri, 17 Apr 2020 14:28:08 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id nu11so1588105pjb.1; Fri, 17 Apr 2020 14:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=S55/8gnM7KvcJqQsFxraRZVD73qlFB2adwVR/ZCZ3ts=; b=uASg3bPZsBgrZmJQXwK7T/LGrybYjboDE0YliP3uB3T8yLAd1GJ4CIgeKgObkTxg39 TEC9QbaUOcQFmWcDx3EnemsPr8CkXb7uA8wfWXoejel2qxuc0qGnUk23HV68Hq1ADhU1 igV+rrehUH2Y8EOR4wUcf5rK7qfV4quDkgpX7ggCZDsfAw4/3EvwezxzPmwJm2d/oq5L kbrIwADVqwYq0aYBdtZ/lXLGPvrW6m9z0mUfJ7fXHJUeUqlKKtU9/QuoDWq0SjRVtTAP 9KGb2ub2fXwb6pYmKVuXBDTVoDhm0SLQw9WQCeNpKjhJ2WIMnwH7asSe1i4tdR85LN9J Zi6A== 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:message-id:in-reply-to :references:subject:mime-version; bh=S55/8gnM7KvcJqQsFxraRZVD73qlFB2adwVR/ZCZ3ts=; b=sgrVNXKYVQs/MhHBofmVtRwyGDgc2Mr40BX17pDFFCqGC8c4LyzEFpz9u29jOMyM9i FxgcfKTxX3d8u0nsPTRoioiCIOJC1lxIQFlf+c+7cDvCpEE4INogDQ1i73jEOoRImus6 EI0SaMNL5EouLzL1AkZBNTW5jJEeCnvy6JAKmpUJ9A3mrlk4RKtwETw6i4u07bZ0hnk1 bTJ1vhqcpUpt9zlRsqJsSuCF+uHOeY/QBqt3z/4BWtQYYNM4jIHS4SYkFM0N0GIKslPC fupCYFyHsvMfGlB33BGmBru0cypLZ9kZNTXuehbLD/XqMspxM56JzvjazxHs8FuYi4CB 6NSA== X-Gm-Message-State: AGi0PubLde7kNj26CppBbFfL/aurg7aAADdJnYmFxHtn7uRPyzibHv6H U09v9KmeHck3bGN8d6HClcLdjp7Z X-Google-Smtp-Source: APiQypLx4gw+q/zFA5ZvcZb6pKtQppaOoBOm6lxysw6iTeuj7AegN86FH/YNks62tXjyw5eqDRoQMg== X-Received: by 2002:a17:902:9a8a:: with SMTP id w10mr5641562plp.259.1587158887466; Fri, 17 Apr 2020 14:28:07 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id w13sm5406076pfn.192.2020.04.17.14.28.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 14:28:06 -0700 (PDT) Date: Fri, 17 Apr 2020 14:27:57 -0700 From: Jeff Tantsura To: "=?utf-8?Q??=" , Mach Chen Cc: "=?utf-8?Q?rtg-dir=40ietf.org?=" , "=?utf-8?Q?draft-ietf-idr-bgp-ls-segment-routing-msd.all=40ietf.org?=" , IDR List Message-ID: <64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark> In-Reply-To: References: X-Readdle-Message-ID: 64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e9a1f65_7a6d8d3c_e7ef" Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 21:28:16 -0000 --5e9a1f65_7a6d8d3c_e7ef Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Mach/Alvaro, Many thanks for your review. Please see inline Have a great weekend and stay safe=21 Cheers, Jeff On Apr 17, 2020, 12:38 AM -0700, Mach Chen , wrot= e: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft= . The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IET=46 last call and IESG review, and sometim= es on special request. The purpose of the review is to provide assistance= to the Routing ADs. =46or more information about the Routing Directorate= , please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r > > Although these comments are primarily for the use of the Routing ADs, i= t would be helpful if you could consider them along with any other IET=46= Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. > > Document: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt > Reviewer: Mach Chen > Review Date: April 17, 2020 > IET=46 LC End Date: > Intended Status: Standards Track > > Summary: > I have some minor concerns about this document that I think should be r= esolved before publication. > > Comments: > This document is clearly written and easy to understand. > > Major Issues: > No major issues found. > > Minor Issues: > The Node MSD TLV and Link MSD TLV are designed to be able to carry mult= iple MSDs. I guess this is designed for future extensibility, where a Nod= e may have multiple types of MSD, right=3F But for each type, is it allow= ed to carry multiple instances of MSD-Type/MSD-Value pair or only one ins= tance=3F =46or whichever case, there need some text to describe the rule = about the sending and receiving procedures. =46or example, when multiple = instances allowed, how does a node decide which instance takes effect; if= only one instance allowed and multiple instances received, how to handle= this, discard the whole TLV, or only the first instance takes effect and= the rest ignored. > > Nits: > 1. > Section 1, > s/learn/learns =5Bjeff=5D ack > > 2. > Section 3 and Section 4: > The TLV format of Node/Link MSD is defined as follows: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =7C Type =7C Length =7C > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =7C MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... =7C > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Since the MSD-Type/MSD-Value pairs are variable in length, the above de= finition does not reflect this, suggest to change the figure as below: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =7C Type =7C Length =7C > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =5Bjeff=5D As Alvaro already explained in his email, BGP-LS is simply the= transport here,=C2=A0https://tools.ietf.org/html/rfc8491=23section-2 sho= ws the format exactly as you suggested, thanks for that=21 I=E2=80=99m with Alvaro - this need not to be done in this document, sinc= e it is already done in the IGP R=46C. > > Best regards, > Mach > --5e9a1f65_7a6d8d3c_e7ef Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Mach/Alvaro,

Many thanks for your review.

Please see inline


Have a great weekend and stay safe=21

Cheers,
Jeff
On Apr 17, 2020, 12:38 AM -0700, Ma= ch Chen <mach.chen=40huawei.com>, wrote:
He= llo,

I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related dr= afts as they pass through IET=46 last call and IESG review, and sometimes= on special request. The purpose of the review is to provide assistance t= o the Routing ADs. =46or more information about the Routing Directorate, = please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<= br />
Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IET=46 L= ast Call comments that you receive, and strive to resolve them through di= scussion or by updating the draft.

Document: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt
Reviewer: Mach Chen
Review Date: April 17, 2020
IET=46 LC End Date:
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be res= olved before publication.

Comments:
This document is clearly written and easy to understand.

Major Issues:
No major issues found.

Minor Issues:
The Node MSD TLV and Link MSD TLV are designed to be able to carry multip= le MSDs. I guess this is designed for future extensibility, where a Node = may have multiple types of MSD, right=3F But for each type, is it allowed= to carry multiple instances of MSD-Type/MSD-Value pair or only one insta= nce=3F =46or whichever case, there need some text to describe the rule ab= out the sending and receiving procedures. =46or example, when multiple in= stances allowed, how does a node decide which instance takes effect; if o= nly one instance allowed and multiple instances received, how to handle t= his, discard the whole TLV, or only the first instance takes effect and t= he rest ignored.

Nits:
1.
Section 1,
s/learn/learns&=23160;
=5Bjeff=5D ack
2.
Section 3 and Section 4:
The TLV format of Node/Link MSD is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=7C Type =7C Length =7C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=7C MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... =7C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Since the MSD-Type/MSD-Value pairs are variable in length, the above defi= nition does not reflect this, suggest to change the figure as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=7C Type =7C Length =7C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&=23160;=

=5Bjeff=5D As Alvaro already explained in his email= , BGP-LS is simply the transport here,&=23160;https://tools.ietf.org/html= /rfc8491=23section-2 shows the format exactly as you suggested, thanks fo= r that=21&=23160;
I=E2=80=99m with Alvaro - this need not to be done = in this document, since it is already done in the IGP R=46C.&=23160;
Best regards,
Mach

--5e9a1f65_7a6d8d3c_e7ef-- From nobody Fri Apr 17 20:30:24 2020 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 5DB9D3A0E96; Fri, 17 Apr 2020 20:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBMLjrgsvIn3; Fri, 17 Apr 2020 20:30:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914D13A0E8D; Fri, 17 Apr 2020 20:30:12 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4711F62EAC16074CE84A; Sat, 18 Apr 2020 04:30:10 +0100 (IST) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 18 Apr 2020 04:30:09 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.249]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Sat, 18 Apr 2020 11:30:03 +0800 From: Mach Chen To: Alvaro Retana , "" CC: "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , IDR List , "rtg-dir@ietf.org" Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt Thread-Index: AdYUgufIha3uMI7HSMyOkGGdwgKyaQANmQuAABrRsaA= Date: Sat, 18 Apr 2020 03:30:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.48] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 03:30:22 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpUZWNobmljYWxseSwgYWNjb3JkaW5nIHRvIFRhYmxlIDIgb2YgUkZDIDc3 NTIsIHRoZSBzb3VyY2Ugb2YgQkdQLUxTIGluZm9ybWF0aW9uIGNhbiBiZSBmcm9tIElHUCwgRGly ZWN0IG9yIFN0YXRpYyBjb25maWd1cmF0aW9uLiBBbmQgdGhlIHJ1bGVzIGluIHF1ZXN0aW9uIGFy ZSBub3Qgc3BlY2lmaWVkIGluIHRoZSBJR1AgUkZDcywgSSBwZXJzb25hbGx5IHRoaW5rIHRoZXkg YXJlIGVzc2VudGlhbC4gSXTigJlzIHBpdHkgdGhhdCB3ZSBkaWQgbm90IGNhdGNoIGl0IHdoZW4g cHJvZ3Jlc3NpbmcgdGhvc2UgUkZDcy4gSSBkbyBhZ3JlZSB0aGlzIGRvY3VtZW50IG1heSBub3Qg YmUgdGhlIHBlcmZlY3QgcGxhY2UgdG8gc3BlY2lmeSAgdGhvc2UgcnVsZXMsIGJ1dCB3aXRoIHRo ZSBjdXJyZW50IHNpdHVhdGlvbiwgdG8gd3JpdGUgZG93biBzb21ldGhpbmcgaGVyZSBpcyBiZXR0 ZXIgdGhhbiBkbyBub3RoaW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCkZyb206IEFsdmFy byBSZXRhbmEgW21haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXks IEFwcmlsIDE4LCAyMDIwIDU6MDkgQU0NClRvOiA8cnRnLWFkc0BpZXRmLm9yZz4gPHJ0Zy1hZHNA aWV0Zi5vcmc+OyBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPg0KQ2M6IGRyYWZ0LWll dGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctbXNkLmFsbEBpZXRmLm9yZzsgSURSIExpc3Qg PGlkckBpZXRmLm9yZz47IHJ0Zy1kaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSdGdEaXIgcmV2 aWV3OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQNCg0K TWFjaDoNCg0KSGkhICBIb3cgYXJlIHlvdT8NCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3ISENCg0K S2VlcCBpbiBtaW5kIHRoYXQgQkdQLUxTIHNpbXBseSB0cmFuc3BvcnRzIHRoZSBpbmZvcm1hdGlv biBmcm9tIHRoZSBJR1BzLCBzbyB0aGUgYWJpbGl0eSB0byBjYXJyeSBtdWx0aXBsZSBpbnN0YW5j ZXMvbXVsdGlwbGUgdmFsdWVzIGRlcGVuZHMgb24gdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIE1T RCBpdHNlbGYsIGFuZCBhbnkgcnVsZXMgaW4gdGhlIGNvcnJlc3BvbmRpbmcgSUdQIFJGQ3MuICBJ T1csIHNwZWNpZnlpbmcgdGhhdCBiZWhhdmlvciBmb3IgQkdQLUxTIGluIHRoaXMgZG9jdW1lbnQg aXMgbm90IG5lZWRlZC4NCg0KDQpUYWtlIGNhcmUhDQoNCkFsdmFyby4NCg0KDQpPbiBBcHJpbCAx NywgMjAyMCBhdCAzOjM4OjU1IEFNLCBNYWNoIENoZW4gKG1hY2guY2hlbkBodWF3ZWkuY29tPG1h aWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4pIHdyb3RlOg0KTWlub3IgSXNzdWVzOg0KVGhlIE5v ZGUgTVNEIFRMViBhbmQgTGluayBNU0QgVExWIGFyZSBkZXNpZ25lZCB0byBiZSBhYmxlIHRvIGNh cnJ5IG11bHRpcGxlIE1TRHMuIEkgZ3Vlc3MgdGhpcyBpcyBkZXNpZ25lZCBmb3IgZnV0dXJlIGV4 dGVuc2liaWxpdHksIHdoZXJlIGEgTm9kZSBtYXkgaGF2ZSBtdWx0aXBsZSB0eXBlcyBvZiBNU0Qs IHJpZ2h0PyBCdXQgZm9yIGVhY2ggdHlwZSwgaXMgaXQgYWxsb3dlZCB0byBjYXJyeSBtdWx0aXBs ZSBpbnN0YW5jZXMgb2YgTVNELVR5cGUvTVNELVZhbHVlIHBhaXIgb3Igb25seSBvbmUgaW5zdGFu Y2U/IEZvciB3aGljaGV2ZXIgY2FzZSwgdGhlcmUgbmVlZCBzb21lIHRleHQgdG8gZGVzY3JpYmUg dGhlIHJ1bGUgYWJvdXQgdGhlIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBwcm9jZWR1cmVzLiBGb3Ig ZXhhbXBsZSwgd2hlbiBtdWx0aXBsZSBpbnN0YW5jZXMgYWxsb3dlZCwgaG93IGRvZXMgYSBub2Rl IGRlY2lkZSB3aGljaCBpbnN0YW5jZSB0YWtlcyBlZmZlY3Q7IGlmIG9ubHkgb25lIGluc3RhbmNl IGFsbG93ZWQgYW5kIG11bHRpcGxlIGluc3RhbmNlcyByZWNlaXZlZCwgaG93IHRvIGhhbmRsZSB0 aGlzLCBkaXNjYXJkIHRoZSB3aG9sZSBUTFYsIG9yIG9ubHkgdGhlIGZpcnN0IGluc3RhbmNlIHRh a2VzIGVmZmVjdCBhbmQgdGhlIHJlc3QgaWdub3JlZC4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHls ZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp IEFsdmFybyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGVjaG5pY2FsbHksIGFjY29yZGluZyB0byBUYWJsZSAyIG9m IFJGQyA3NzUyLCB0aGUgc291cmNlIG9mIEJHUC1MUyBpbmZvcm1hdGlvbiBjYW4gYmUgZnJvbSBJ R1AsIERpcmVjdCBvciBTdGF0aWMgY29uZmlndXJhdGlvbi4gQW5kIHRoZSBydWxlcyBpbg0KIHF1 ZXN0aW9uIGFyZSBub3Qgc3BlY2lmaWVkIGluIHRoZSBJR1AgUkZDcywgSSBwZXJzb25hbGx5IHRo aW5rIHRoZXkgYXJlIGVzc2VudGlhbC4gSXTigJlzIHBpdHkgdGhhdCB3ZSBkaWQgbm90IGNhdGNo IGl0IHdoZW4gcHJvZ3Jlc3NpbmcgdGhvc2UgUkZDcy4gSSBkbyBhZ3JlZSB0aGlzIGRvY3VtZW50 IG1heSBub3QgYmUgdGhlIHBlcmZlY3QgcGxhY2UgdG8gc3BlY2lmeSAmbmJzcDt0aG9zZSBydWxl cywgYnV0IHdpdGggdGhlIGN1cnJlbnQgc2l0dWF0aW9uLA0KIHRvIHdyaXRlIGRvd24gc29tZXRo aW5nIGhlcmUgaXMgYmV0dGVyIHRoYW4gZG8gbm90aGluZy4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1hY2g8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbHZhcm8gUmV0YW5hIFttYWlsdG86 YXJldGFuYS5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXBy aWwgMTgsIDIwMjAgNTowOSBBTTxicj4NCjxiPlRvOjwvYj4gJmx0O3J0Zy1hZHNAaWV0Zi5vcmcm Z3Q7ICZsdDtydGctYWRzQGlldGYub3JnJmd0OzsgTWFjaCBDaGVuICZsdDttYWNoLmNoZW5AaHVh d2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50 LXJvdXRpbmctbXNkLmFsbEBpZXRmLm9yZzsgSURSIExpc3QgJmx0O2lkckBpZXRmLm9yZyZndDs7 IHJ0Zy1kaXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJ0Z0RpciByZXZpZXc6 IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctbXNkLTE2LnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWFjaDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SGkhJm5ic3A7IEhvdyBhcmUgeW91PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U aGFua3MgZm9yIHRoZSByZXZpZXchITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LZWVwIGluIG1pbmQgdGhh dCBCR1AtTFMgc2ltcGx5IHRyYW5zcG9ydHMgdGhlIGluZm9ybWF0aW9uIGZyb20gdGhlIElHUHMs IHNvIHRoZSBhYmlsaXR5IHRvIGNhcnJ5IG11bHRpcGxlIGluc3RhbmNlcy9tdWx0aXBsZSB2YWx1 ZXMgZGVwZW5kcyBvbiB0aGUgc3BlY2lmaWNhdGlvbg0KIG9mIHRoZSBNU0QgaXRzZWxmLCBhbmQg YW55IHJ1bGVzIGluIHRoZSBjb3JyZXNwb25kaW5nIElHUCBSRkNzLiZuYnNwOyBJT1csIHNwZWNp ZnlpbmcgdGhhdCBiZWhhdmlvciBmb3IgQkdQLUxTIGluIHRoaXMgZG9jdW1lbnQgaXMgbm90IG5l ZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5UYWtlIGNhcmUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsdmFyby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImFp cm1haWxvbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBBcHJpbCAxNywgMjAy MCBhdCAzOjM4OjU1IEFNLCBNYWNoIENoZW4gKDxhIGhyZWY9Im1haWx0bzptYWNoLmNoZW5AaHVh d2VpLmNvbSI+bWFjaC5jaGVuQGh1YXdlaS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+TWlub3IgSXNzdWVzOjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQo8c3BhbiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhlIE5vZGUgTVNEIFRMViBhbmQgTGluayBNU0QgVExWIGFy ZSBkZXNpZ25lZCB0byBiZSBhYmxlIHRvIGNhcnJ5IG11bHRpcGxlIE1TRHMuIEkgZ3Vlc3MgdGhp cyBpcyBkZXNpZ25lZCBmb3IgZnV0dXJlIGV4dGVuc2liaWxpdHksIHdoZXJlIGEgTm9kZSBtYXkg aGF2ZSBtdWx0aXBsZSB0eXBlcyBvZiBNU0QsIHJpZ2h0PyBCdXQgZm9yIGVhY2ggdHlwZSwgaXMg aXQgYWxsb3dlZCB0byBjYXJyeQ0KIG11bHRpcGxlIGluc3RhbmNlcyBvZiBNU0QtVHlwZS9NU0Qt VmFsdWUgcGFpciBvciBvbmx5IG9uZSBpbnN0YW5jZT8gRm9yIHdoaWNoZXZlciBjYXNlLCB0aGVy ZSBuZWVkIHNvbWUgdGV4dCB0byBkZXNjcmliZSB0aGUgcnVsZSBhYm91dCB0aGUgc2VuZGluZyBh bmQgcmVjZWl2aW5nIHByb2NlZHVyZXMuIEZvciBleGFtcGxlLCB3aGVuIG11bHRpcGxlIGluc3Rh bmNlcyBhbGxvd2VkLCBob3cgZG9lcyBhIG5vZGUgZGVjaWRlIHdoaWNoIGluc3RhbmNlDQogdGFr ZXMgZWZmZWN0OyBpZiBvbmx5IG9uZSBpbnN0YW5jZSBhbGxvd2VkIGFuZCBtdWx0aXBsZSBpbnN0 YW5jZXMgcmVjZWl2ZWQsIGhvdyB0byBoYW5kbGUgdGhpcywgZGlzY2FyZCB0aGUgd2hvbGUgVExW LCBvciBvbmx5IHRoZSBmaXJzdCBpbnN0YW5jZSB0YWtlcyBlZmZlY3QgYW5kIHRoZSByZXN0IGln bm9yZWQuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_-- From nobody Fri Apr 17 20:45:04 2020 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 2CAE33A0ED0; Fri, 17 Apr 2020 20:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUi62k_DHZex; Fri, 17 Apr 2020 20:44:38 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141F03A0ECF; Fri, 17 Apr 2020 20:44:38 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6CF7B7E1C8A57C8CCC42; Sat, 18 Apr 2020 04:44:35 +0100 (IST) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 18 Apr 2020 04:44:34 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.249]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Sat, 18 Apr 2020 11:44:29 +0800 From: Mach Chen To: Jeff Tantsura , "" CC: "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , IDR List Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt Thread-Index: AdYUgufIha3uMI7HSMyOkGGdwgKyaQAORn6AAB1va+A= Date: Sat, 18 Apr 2020 03:44:27 +0000 Message-ID: References: <64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark> In-Reply-To: <64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.48] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 03:44:41 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVmZiwNCg0KUGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmXigKYNCg0KRnJvbTogSmVm ZiBUYW50c3VyYSBbbWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwuY29tXQ0KU2VudDogU2F0dXJk YXksIEFwcmlsIDE4LCAyMDIwIDU6MjggQU0NClRvOiA8cnRnLWFkc0BpZXRmLm9yZz4gPHJ0Zy1h ZHNAaWV0Zi5vcmc+OyBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPg0KQ2M6IHJ0Zy1k aXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctbXNkLmFs bEBpZXRmLm9yZzsgSURSIExpc3QgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQN Cg0KSGkgTWFjaC9BbHZhcm8sDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KUGxl YXNlIHNlZSBpbmxpbmUNCg0KDQpIYXZlIGEgZ3JlYXQgd2Vla2VuZCBhbmQgc3RheSBzYWZlIQ0K DQpDaGVlcnMsDQpKZWZmDQpPbiBBcHIgMTcsIDIwMjAsIDEyOjM4IEFNIC0wNzAwLCBNYWNoIENo ZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+LCB3 cm90ZToNCg0KSGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERp cmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0 ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBh cyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBz b21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlz IHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91 Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGlu ZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2 ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVw ZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdt ZW50LXJvdXRpbmctbXNkLTE2LnR4dA0KUmV2aWV3ZXI6IE1hY2ggQ2hlbg0KUmV2aWV3IERhdGU6 IEFwcmlsIDE3LCAyMDIwDQpJRVRGIExDIEVuZCBEYXRlOg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sNCg0KU3VtbWFyeToNCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0 IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVi bGljYXRpb24uDQoNCkNvbW1lbnRzOg0KVGhpcyBkb2N1bWVudCBpcyBjbGVhcmx5IHdyaXR0ZW4g YW5kIGVhc3kgdG8gdW5kZXJzdGFuZC4NCg0KTWFqb3IgSXNzdWVzOg0KTm8gbWFqb3IgaXNzdWVz IGZvdW5kLg0KDQpNaW5vciBJc3N1ZXM6DQpUaGUgTm9kZSBNU0QgVExWIGFuZCBMaW5rIE1TRCBU TFYgYXJlIGRlc2lnbmVkIHRvIGJlIGFibGUgdG8gY2FycnkgbXVsdGlwbGUgTVNEcy4gSSBndWVz cyB0aGlzIGlzIGRlc2lnbmVkIGZvciBmdXR1cmUgZXh0ZW5zaWJpbGl0eSwgd2hlcmUgYSBOb2Rl IG1heSBoYXZlIG11bHRpcGxlIHR5cGVzIG9mIE1TRCwgcmlnaHQ/IEJ1dCBmb3IgZWFjaCB0eXBl LCBpcyBpdCBhbGxvd2VkIHRvIGNhcnJ5IG11bHRpcGxlIGluc3RhbmNlcyBvZiBNU0QtVHlwZS9N U0QtVmFsdWUgcGFpciBvciBvbmx5IG9uZSBpbnN0YW5jZT8gRm9yIHdoaWNoZXZlciBjYXNlLCB0 aGVyZSBuZWVkIHNvbWUgdGV4dCB0byBkZXNjcmliZSB0aGUgcnVsZSBhYm91dCB0aGUgc2VuZGlu ZyBhbmQgcmVjZWl2aW5nIHByb2NlZHVyZXMuIEZvciBleGFtcGxlLCB3aGVuIG11bHRpcGxlIGlu c3RhbmNlcyBhbGxvd2VkLCBob3cgZG9lcyBhIG5vZGUgZGVjaWRlIHdoaWNoIGluc3RhbmNlIHRh a2VzIGVmZmVjdDsgaWYgb25seSBvbmUgaW5zdGFuY2UgYWxsb3dlZCBhbmQgbXVsdGlwbGUgaW5z dGFuY2VzIHJlY2VpdmVkLCBob3cgdG8gaGFuZGxlIHRoaXMsIGRpc2NhcmQgdGhlIHdob2xlIFRM Viwgb3Igb25seSB0aGUgZmlyc3QgaW5zdGFuY2UgdGFrZXMgZWZmZWN0IGFuZCB0aGUgcmVzdCBp Z25vcmVkLg0KDQpOaXRzOg0KMS4NClNlY3Rpb24gMSwNCnMvbGVhcm4vbGVhcm5zDQpbamVmZl0g YWNrDQoNCjIuDQpTZWN0aW9uIDMgYW5kIFNlY3Rpb24gNDoNClRoZSBUTFYgZm9ybWF0IG9mIE5v ZGUvTGluayBNU0QgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KMCAxIDIgMw0KMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KfCBUeXBlIHwgTGVuZ3RoIHwNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IE1TRC1UeXBlIHwgTVNELVZhbHVl IHwgTVNELVR5cGUuLi4gfCBNU0QtVmFsdWUuLi4gfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KU2luY2UgdGhlIE1T RC1UeXBlL01TRC1WYWx1ZSBwYWlycyBhcmUgdmFyaWFibGUgaW4gbGVuZ3RoLCB0aGUgYWJvdmUg ZGVmaW5pdGlvbiBkb2VzIG5vdCByZWZsZWN0IHRoaXMsIHN1Z2dlc3QgdG8gY2hhbmdlIHRoZSBm aWd1cmUgYXMgYmVsb3c6DQowIDEgMiAzDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IFR5cGUgfCBMZW5n dGggfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCi8vIE1TRC1UeXBlIHwgTVNELVZhbHVlIHwgTVNELVR5cGUuLi4gfCBN U0QtVmFsdWUuLi4gLy8NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCltqZWZmXSBBcyBBbHZhcm8gYWxyZWFkeSBleHBs YWluZWQgaW4gaGlzIGVtYWlsLCBCR1AtTFMgaXMgc2ltcGx5IHRoZSB0cmFuc3BvcnQgaGVyZSwg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0OTEjc2VjdGlvbi0yIHNob3dzIHRoZSBm b3JtYXQgZXhhY3RseSBhcyB5b3Ugc3VnZ2VzdGVkLCB0aGFua3MgZm9yIHRoYXQhDQpJ4oCZbSB3 aXRoIEFsdmFybyAtIHRoaXMgbmVlZCBub3QgdG8gYmUgZG9uZSBpbiB0aGlzIGRvY3VtZW50LCBz aW5jZSBpdCBpcyBhbHJlYWR5IGRvbmUgaW4gdGhlIElHUCBSRkMuDQoNCltNYWNoXSBJIG1heSBi ZSBhIGxpdHRsZSBiaXQgcGlja3kgaGVyZeKYuiAgQWNjb3JkaW5nIHRvIEZpZ3VyZSAxIGFuZCBG aWd1cmUgMiwgdGhleSBzaG93cyB0aGF0IHZhbHVlIGZpZWxkIGlzIGZpeGVkIChmb3VyIG9jdGV0 cykgaW4gbGVuZ3RoLCBidXQgYWN0dWFsbHkgdGhlIGxlbmd0aCBpcyB2YXJpYWJsZSBhcyBkZXNp Z25lZC4gSU1ITywgdGhlIGZvcm1hdCBvZiBJR1AgVExWIHdpbGwgbm90IGJlIGV4YWN0bHkgbWFw cGVkIHRvIHRoZSBmb3JtYXQgQkdQIFRMViBmb3JtYXQsIEJHUC1MUyBoYXMgaXRzIG93biBkZWZp bml0aW9ucy4gSXTigJlzIGJldHRlciB0aGF0IHRoaXMgZG9jdW1lbnQga2VlcHMgdGhlIGRlZmlu aXRpb24gc2FuZSBieSBpdHNlbGYuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KDQpCZXN0IHJl Z2FyZHMsDQpNYWNoDQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5 IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7 DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0x OjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2T O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgSmVmZiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+UGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmXigKY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKZWZmIFRhbnRzdXJhIFttYWlsdG86 amVmZnRhbnQuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEFw cmlsIDE4LCAyMDIwIDU6MjggQU08YnI+DQo8Yj5Ubzo8L2I+ICZsdDtydGctYWRzQGlldGYub3Jn Jmd0OyAmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDs7IE1hY2ggQ2hlbiAmbHQ7bWFjaC5jaGVuQGh1 YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBydGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRm LWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC5hbGxAaWV0Zi5vcmc7IElEUiBMaXN0ICZs dDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBSdGdEaXIgcmV2aWV3 OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgbmFtZT0i bWVzc2FnZUJvZHlTZWN0aW9uIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SGkgTWFjaC9BbHZhcm8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5NYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugc2VlIGlubGlu ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhhdmUgYSBncmVhdCB3ZWVrZW5kIGFuZCBzdGF5IHNhZmUh PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgbmFtZT0ibWVzc2Fn ZVNpZ25hdHVyZVNlY3Rpb24iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hlZXJzLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkplZmY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IG5hbWU9Im1lc3Nh Z2VSZXBseVNlY3Rpb24iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIEFwciAxNywgMjAyMCwgMTI6MzggQU0gLTA3MDAsIE1hY2ggQ2hlbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7 LCB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzFBQkM5QyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDguMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjMuNzVwdDtt YXJnaW4tcmlnaHQ6My43NXB0O21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyw8YnI+DQo8YnI+DQpJIGhhdmUgYmVlbiBz ZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9y IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNh bGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhl IHB1cnBvc2Ugb2YgdGhlDQogcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUg Um91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVj dG9yYXRlLCBwbGVhc2Ugc2VlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0RpciI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0 Z0RpcjwvYT48YnI+DQo8YnI+DQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5 b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2Fs bCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0 aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljxicj4NCjxicj4NCkRv Y3VtZW50OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQ8 YnI+DQpSZXZpZXdlcjogTWFjaCBDaGVuPGJyPg0KUmV2aWV3IERhdGU6IEFwcmlsIDE3LCAyMDIw PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTo8YnI+DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU cmFjazxicj4NCjxicj4NClN1bW1hcnk6PGJyPg0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMg YWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9y ZSBwdWJsaWNhdGlvbi48YnI+DQo8YnI+DQpDb21tZW50czo8YnI+DQpUaGlzIGRvY3VtZW50IGlz IGNsZWFybHkgd3JpdHRlbiBhbmQgZWFzeSB0byB1bmRlcnN0YW5kLjxicj4NCjxicj4NCk1ham9y IElzc3Vlczo8YnI+DQpObyBtYWpvciBpc3N1ZXMgZm91bmQuPGJyPg0KPGJyPg0KTWlub3IgSXNz dWVzOjxicj4NClRoZSBOb2RlIE1TRCBUTFYgYW5kIExpbmsgTVNEIFRMViBhcmUgZGVzaWduZWQg dG8gYmUgYWJsZSB0byBjYXJyeSBtdWx0aXBsZSBNU0RzLiBJIGd1ZXNzIHRoaXMgaXMgZGVzaWdu ZWQgZm9yIGZ1dHVyZSBleHRlbnNpYmlsaXR5LCB3aGVyZSBhIE5vZGUgbWF5IGhhdmUgbXVsdGlw bGUgdHlwZXMgb2YgTVNELCByaWdodD8gQnV0IGZvciBlYWNoIHR5cGUsIGlzIGl0IGFsbG93ZWQg dG8gY2FycnkgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIE1TRC1UeXBlL01TRC1WYWx1ZQ0KIHBhaXIg b3Igb25seSBvbmUgaW5zdGFuY2U/IEZvciB3aGljaGV2ZXIgY2FzZSwgdGhlcmUgbmVlZCBzb21l IHRleHQgdG8gZGVzY3JpYmUgdGhlIHJ1bGUgYWJvdXQgdGhlIHNlbmRpbmcgYW5kIHJlY2Vpdmlu ZyBwcm9jZWR1cmVzLiBGb3IgZXhhbXBsZSwgd2hlbiBtdWx0aXBsZSBpbnN0YW5jZXMgYWxsb3dl ZCwgaG93IGRvZXMgYSBub2RlIGRlY2lkZSB3aGljaCBpbnN0YW5jZSB0YWtlcyBlZmZlY3Q7IGlm IG9ubHkgb25lIGluc3RhbmNlIGFsbG93ZWQNCiBhbmQgbXVsdGlwbGUgaW5zdGFuY2VzIHJlY2Vp dmVkLCBob3cgdG8gaGFuZGxlIHRoaXMsIGRpc2NhcmQgdGhlIHdob2xlIFRMViwgb3Igb25seSB0 aGUgZmlyc3QgaW5zdGFuY2UgdGFrZXMgZWZmZWN0IGFuZCB0aGUgcmVzdCBpZ25vcmVkLjxicj4N Cjxicj4NCk5pdHM6PGJyPg0KMS48YnI+DQpTZWN0aW9uIDEsPGJyPg0Kcy9sZWFybi9sZWFybnMm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPltqZWZmXSBhY2s8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjMUFCQzlDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gOC4wcHQ7bWFyZ2lu LWxlZnQ6My43NXB0O21hcmdpbi10b3A6My43NXB0O21hcmdpbi1yaWdodDozLjc1cHQ7bWFyZ2lu LWJvdHRvbTozLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjIuPGJyPg0KU2VjdGlvbiAzIGFuZCBTZWN0aW9uIDQ6PGJyPg0KVGhlIFRMViBmb3Jt YXQgb2YgTm9kZS9MaW5rIE1TRCBpcyBkZWZpbmVkIGFzIGZvbGxvd3M6PGJyPg0KMCAxIDIgMzxi cj4NCjAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMTxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJyPg0KfCBUeXBlIHwg TGVuZ3RoIHw8YnI+DQomIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxicj4NCnwgTVNELVR5cGUg fCBNU0QtVmFsdWUgfCBNU0QtVHlwZS4uLiB8IE1TRC1WYWx1ZS4uLiB8PGJyPg0KJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8YnI+DQo8YnI+DQpTaW5jZSB0aGUgTVNELVR5cGUvTVNELVZhbHVl IHBhaXJzIGFyZSB2YXJpYWJsZSBpbiBsZW5ndGgsIHRoZSBhYm92ZSBkZWZpbml0aW9uIGRvZXMg bm90IHJlZmxlY3QgdGhpcywgc3VnZ2VzdCB0byBjaGFuZ2UgdGhlIGZpZ3VyZSBhcyBiZWxvdzo8 YnI+DQowIDEgMiAzPGJyPg0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPGJyPg0KJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 YnI+DQp8IFR5cGUgfCBMZW5ndGggfDxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJy Pg0KLy8gTVNELVR5cGUgfCBNU0QtVmFsdWUgfCBNU0QtVHlwZS4uLiB8IE1TRC1WYWx1ZS4uLiAv Lzxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W2plZmZdIEFzIEFsdmFybyBh bHJlYWR5IGV4cGxhaW5lZCBpbiBoaXMgZW1haWwsIEJHUC1MUyBpcyBzaW1wbHkgdGhlIHRyYW5z cG9ydCBoZXJlLCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NDkxI3NlY3Rpb24tMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0OTEjc2VjdGlv bi0yPC9hPiBzaG93cyB0aGUgZm9ybWF0IGV4YWN0bHkNCiBhcyB5b3Ugc3VnZ2VzdGVkLCB0aGFu a3MgZm9yIHRoYXQhJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPknigJltIHdpdGggQWx2YXJv IC0gdGhpcyBuZWVkIG5vdCB0byBiZSBkb25lIGluIHRoaXMgZG9jdW1lbnQsIHNpbmNlIGl0IGlz IGFscmVhZHkgZG9uZSBpbiB0aGUgSUdQIFJGQy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01hY2hdIEkg bWF5IGJlIGEgbGl0dGxlIGJpdCBwaWNreSBoZXJlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3 RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOw0KIEFjY29yZGluZyB0byBGaWd1cmUgMSBhbmQgRmlndXJlIDIsIHRoZXkgc2hvd3MgdGhh dCB2YWx1ZSBmaWVsZCBpcyBmaXhlZCAoZm91ciBvY3RldHMpIGluIGxlbmd0aCwgYnV0IGFjdHVh bGx5IHRoZSBsZW5ndGggaXMgdmFyaWFibGUgYXMgZGVzaWduZWQuIElNSE8sIHRoZSBmb3JtYXQg b2YgSUdQIFRMViB3aWxsIG5vdCBiZSBleGFjdGx5IG1hcHBlZCB0byB0aGUgZm9ybWF0IEJHUCBU TFYgZm9ybWF0LCBCR1AtTFMgaGFzIGl0cyBvd24gZGVmaW5pdGlvbnMuDQogSXTigJlzIGJldHRl ciB0aGF0IHRoaXMgZG9jdW1lbnQga2VlcHMgdGhlIGRlZmluaXRpb24gc2FuZSBieSBpdHNlbGYu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk1hY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICMxQUJDOUMgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDttYXJnaW4t bGVmdDozLjc1cHQ7bWFyZ2luLXRvcDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjMuNzVwdDttYXJnaW4t Ym90dG9tOjMuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KTWFj aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_-- From nobody Sun Apr 19 14:25:42 2020 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 7EBA73A11F9; Sun, 19 Apr 2020 14:25:31 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158733153145.25696.1577697319452012320@ietfa.amsl.com> Date: Sun, 19 Apr 2020 14:25:31 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-open-policy-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 21:25:32 -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 : Route Leak Prevention using Roles in Update and Open messages Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Kotikalapudi Sriram Filename : draft-ietf-idr-bgp-open-policy-09.txt Pages : 10 Date : 2020-04-19 Abstract: Route leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the BGP neighbor, or enforcement that the two BGP speakers agree on the relationship. This document enhances BGP OPEN to establish agreement of the (peer, customer, provider, Route Server, Route Server client) relationship of two neighboring BGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an OTC attribute according to the agreed relationship, allowing both prevention and detection of route leaks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-09 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-open-policy-09 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 Mon Apr 20 00:24:09 2020 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 4D8423A12E2; Mon, 20 Apr 2020 00:23:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <158736743780.26521.14193221247582622698@ietfa.amsl.com> Date: Mon, 20 Apr 2020 00:23:58 -0700 Archived-At: Subject: [Idr] Erik Kline's Yes on draft-ietf-idr-rfc5575bis-22: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 07:23:58 -0000 Erik Kline has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ sections 4.{1,3} ] Thank you for the clarifying examples at the boundary. [ sections 4.2.2.{4,5,6} ] What about non-{TCP,UDP} protocols with ports? Should operators be able to express a flow spec for SCTP traffic (e.g. within a 3GPP network context)? There's no mention of any such support in 5575, so I'll presume this sort of thing is left to another document (whether or not that document exists). [ section 5.1 ] My reading of this is that sorting between 2 different specifications each with source and destinations prefixes must always be examined by destination prefix first (because of the component ordering restriction in section 4.2). Is this correct? [ section 7 ] "may interfere with each other even contradict" --> "may interfere with each other or even contradict" ? [ section 11.2 ] "by a an 8-bit" --> "by an 8-bit" ? From nobody Mon Apr 20 01:10:43 2020 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 F0BB03A043A; Mon, 20 Apr 2020 01:10:36 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158737023693.17125.6693300482867416360@ietfa.amsl.com> Date: Mon, 20 Apr 2020 01:10:36 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 08:10:37 -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 : Dissemination of Flow Specification Rules for IPv6 Authors : Christoph Loibl Robert Raszuk Susan Hares Filename : draft-ietf-idr-flow-spec-v6-11.txt Pages : 15 Date : 2020-04-20 Abstract: Dissemination of Flow Specification Rules [I-D.ietf-idr-rfc5575bis] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [I-D.ietf-idr-rfc5575bis] specifies those extensions for IPv4 protocol data packets only. This specification extends [I-D.ietf-idr-rfc5575bis] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-11 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flow-spec-v6-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flow-spec-v6-11 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 Mon Apr 20 06:11:11 2020 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 DCDE83A0C9D; Mon, 20 Apr 2020 06:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 if5TFDIYabmp; Mon, 20 Apr 2020 06:10:54 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 309183A0CCE; Mon, 20 Apr 2020 06:10:54 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id x4so10959933wmj.1; Mon, 20 Apr 2020 06:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=dtTEsrStO99B7spoCuIiRkyQsgNv+oQHN+DD953zAaA=; b=OdkWxn7xEsuUohYG6nfBEqOlLt6OGxRSnzp7MQCVRnpGs3rH09yW+gqGpAxM5VEEQW IuFVLOSEXjYMTpex3JFSKEbPFhQ25DcIl/mk8OsyNEoRpbVB4DBeHlDsWmzCr39W+EJ5 WyRVNxpVG4JljrL6siDTJPso4Sk49jK6RgcknEVxMhvTtPX/yFVXACwuJ4lioGMO050R ziPFj8OdMJZfESd64QDACTa74Q1Mpegfzleal9ybkx0wGms/coxWuq8zfbBN1mBUoGA0 93cGrfxk7XAQymtLT5M3DudBVmvytfAp8PJB5Ub4+sRRv4kWcyMTZ7ywD3S/SOcnjUfH h7yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=dtTEsrStO99B7spoCuIiRkyQsgNv+oQHN+DD953zAaA=; b=tk9evWpDEmtoKW2M3N36qwF84BZgOmjMmIoTR8liY2DASLzDDuq8HOp8Pq6Fkvz+MP MOd1nLlFvT/AdzoMO208/PFdbjd1avFDuIXao1UCyhyg/Ut6geE40un4xC9L6j3BbwRo wuAxv+ExaDKMAc+aPvW2LUUMWajwrqP55cJTybVs4Xg/+2Apj2qQ/9bKE0AxLvBK2CEU MTKm9fqVBXaKfgnzPMc2iWVWPoPW52rQJVo06IS/Hr+S6fkfVidNNuoH0qZkajCFM+r1 cMc6aDi09a/7ToJBgv9nrmQ6sqwelrEBbeSbKY34BBIJEtDOXkekVO5ek73rBkvWLF3W XoDg== X-Gm-Message-State: AGi0Pua27uv1PNM3SGR1dHZmIPKfNp2CNtKCqIbr3ZlWVJ9ZuP9+yhql Wp7TsUji0Op2CyyUDhiZCVtJiGhDd5zStLakj2waoiQY X-Google-Smtp-Source: APiQypKdytlQGtlixYCpoC/yjAE2k4NU7Ibyb1VgYnFyuqMTx6gf4RmjKIfqliEJA/a0y04EALWwY/bQ0bIZceafjUQ= X-Received: by 2002:a05:600c:28e:: with SMTP id 14mr8083641wmk.79.1587388252270; Mon, 20 Apr 2020 06:10:52 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Apr 2020 06:10:51 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 20 Apr 2020 06:10:50 -0700 Message-ID: To: "" , Mach Chen Cc: "rtg-dir@ietf.org" , IDR List , "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e5b2a305a3b8a0a1" Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 13:11:05 -0000 --000000000000e5b2a305a3b8a0a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mach: Hi! You have a good point, the information can come from other sources. Besides Direct or Static, BGP is another defined source. So far, all the BGP-LS RFCs that have been published assume an IGP origin. Note that this document originally talked about carrying data originated by BGP =E2=80=94 but it would have been the first published document to do so= =E2=80=A6and defining the general operation of a BGP source didn=E2=80=99t seem to best = fit in an extension document. So it was agreed to document that in its own document [1]. Your point about processing of BGP-LS, in general, at the consumer is also a good one=E2=80=A6and one that caused a lot go discussion related to draft-ietf-idr-bgp-ls-segment-routing-ext (IIRC). The result being rfc7752bis. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/idr/uiTEbxlhsfGX_A5D7RQRrrRuA-M/ On April 17, 2020 at 11:30:11 PM, Mach Chen (mach.chen@huawei.com) wrote: Technically, according to Table 2 of RFC 7752, the source of BGP-LS information can be from IGP, Direct or Static configuration. And the rules in question are not specified in the IGP RFCs, I personally think they are essential. It=E2=80=99s pity that we did not catch it when progressing thos= e RFCs. I do agree this document may not be the perfect place to specify those rules, but with the current situation, to write down something here is better than do nothing. --000000000000e5b2a305a3b8a0a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Mach:

Hi!

Y= ou have a good point, the information can come from other sources.=C2=A0 Be= sides Direct or Static, BGP is another defined source.

So far, all the BGP-LS RFCs that have b= een published assume an IGP origin.=C2=A0 Note that this document originall= y talked about carrying data originated by BGP =E2=80=94 but it would have = been the first published document to do so=E2=80=A6and defining the general= operation of a BGP source didn=E2=80=99t seem to best fit in an extension = document.=C2=A0 So it was agreed to document that in its own document [1].<= /div>

Your point about pr= ocessing of BGP-LS, in general, at the consumer is also a good one=E2=80=A6= and one that caused a lot go discussion related to=C2=A0draft-ietf-idr-bgp-= ls-segment-routing-ext (IIRC).=C2=A0 The result being rfc7752bis.


Thanks!

Alvaro.


[= 1]=C2=A0https://mailarchive.ietf.org/arch/msg/idr/uiTEbxlhsfGX_A5D7= RQRrrRuA-M/=C2=A0

On April 17, 2020 at 11:30= :11 PM, Mach Chen (mach.chen@huawei= .com) wrote:

Technically, = according to Table 2 of RFC 7752, the source of BGP-LS information can be f= rom IGP, Direct or Static configuration. And the rules in question are not = specified in the IGP RFCs, I personally think they are essential. It=E2=80= =99s pity that we did not catch it when progressing those RFCs. I do agree = this document may not be the perfect place to specify =C2=A0those rules, bu= t with the current situation, to write down something here is better than d= o nothing.=C2=A0


--000000000000e5b2a305a3b8a0a1-- From nobody Tue Apr 21 05:50:42 2020 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 56BBD3A0B84; Tue, 21 Apr 2020 05:50:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158747342032.7754.13195829798543429586@ietfa.amsl.com> Date: Tue, 21 Apr 2020 05:50:20 -0700 Archived-At: Subject: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-rfc5575bis-22: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 12:50:22 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this approachable update. One item of feedback: Appendix A. This python code is referenced in Section 5.1. Is it intended to be normative? If not, then please say so. If it is, I’d recommend include the full snippet of flowspec-cmp code in the document in addition to making the github reference. Likewise, please provide a reference for Python 3. From nobody Tue Apr 21 11:51:54 2020 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 E02853A043D; Tue, 21 Apr 2020 11:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 DftIpi6l4tN8; Tue, 21 Apr 2020 11:51:41 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 A10EF3A044A; Tue, 21 Apr 2020 11:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=L+ZTzy6VyCXSvQuyKGUrKHRWbQpH9GIGli2dVYdBQ3I=; b=fFThA3JJ9ZdcHkaJ8Y4x95M+ov Be/oeCoaDWB0B+ZS5H4+EqPHxJDMQ46H6Au6kL/QmjUlnTDzn8ipOlIR/yrYjWwSqs/JL9Qxmld2t VwMA9IquulIbfR2QtaTxEV7jd3IXwyNUTKW84AlWrPjYN/p8W1ita6Lz2caXcw9VrstR5h2060zfA BPxrJ0cBC30IP+WT+Ch5P7IVICPcA2YggS50FufSzVPOQtS1+IUDKDUm0yEVNwsnaCapV4t1Jrxw5 ocsa5e4lb2BIcXxe0vJLIH5rGGqf/7LsuBs9Bw4mk1AAZSwVAc/YqYriUBQVJbNyKGnASFmcazfin NDUPGYyg==; Received: from [89.144.223.235] (helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQxz3-000Mg1-9T; Tue, 21 Apr 2020 20:51:02 +0200 From: Christoph Loibl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AA1B7469-5551-4ABC-8068-EDC58C99CA0C" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Tue, 21 Apr 2020 20:50:56 +0200 In-Reply-To: <158747342032.7754.13195829798543429586@ietfa.amsl.com> Cc: The IESG , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com To: Roman Danyliw References: <158747342032.7754.13195829798543429586@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Tue, 21 Apr 2020 20:51:01 +0200 Archived-At: Subject: Re: [Idr] [BULK] Roman Danyliw's No Objection on draft-ietf-idr-rfc5575bis-22: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 18:51:45 -0000 --Apple-Mail=_AA1B7469-5551-4ABC-8068-EDC58C99CA0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roman, Thanks for your review. I will deal with the feedback and will send an = update soon. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 21.04.2020, at 14:50, Roman Danyliw via Datatracker = wrote: >=20 > Roman Danyliw has entered the following ballot position for > draft-ietf-idr-rfc5575bis-22: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this approachable update. One item of feedback: >=20 > Appendix A. This python code is referenced in Section 5.1. Is it = intended to > be normative? If not, then please say so. If it is, I=E2=80=99d = recommend include the > full snippet of flowspec-cmp code in the document in addition to = making the > github reference. Likewise, please provide a reference for Python 3. >=20 >=20 >=20 --Apple-Mail=_AA1B7469-5551-4ABC-8068-EDC58C99CA0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Roman,

Thanks for = your review. I will deal with the feedback and will send an update = soon.

Cheers = Christoph

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



On 21.04.2020, at 14:50, Roman Danyliw via Datatracker <noreply@ietf.org> = wrote:

Roman Danyliw has entered the following ballot position = for
draft-ietf-idr-rfc5575bis-22: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/=



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thanks for this approachable = update.  One item of feedback:

Appendix = A.  This python code is referenced in Section 5.1.  Is it = intended to
be normative?  If not, then please say = so.  If it is, I=E2=80=99d recommend include the
full = snippet of flowspec-cmp code in the document in addition to making = the
github reference.  Likewise, please provide a = reference for Python 3.




= --Apple-Mail=_AA1B7469-5551-4ABC-8068-EDC58C99CA0C-- From nobody Tue Apr 21 23:27:55 2020 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 38BF13A0522; Tue, 21 Apr 2020 23:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158753687275.21086.14037095023027210670@ietfa.amsl.com> Date: Tue, 21 Apr 2020 23:27:53 -0700 Archived-At: Subject: [Idr] Barry Leiba's No Objection on draft-ietf-idr-rfc5575bis-22: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 06:27:54 -0000 Barry Leiba has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All of this is editorial: — Abstract — Other applications (ie. centralized control of traffic in a SDN or NFV context) are also possible. I don’t think you mean “i.e.†here, but “e.g.†I would avoid the Latin (for exactly this reason: many people don’t understand it and misuse it) and say, “Other applications, such as centralized control of traffic in an SDN or NFV context, are also possible.†— Section 1 — Modern IP routers contain both the capability to forward traffic according to IP prefixes as well as to classify, shape, rate limit, filter, or redirect packets based on administratively defined The two things that come after “both†have to be parallel, and they’re not. This will read better without the word “bothâ€, like this: NEW Modern IP routers have the capabilities to forward traffic according to IP prefixes and to classify, shape, rate limit, filter, or redirect packets based on administratively defined END Section 4 of this document defines a general procedure to encode Flow Specification for aggregated traffic flows so that they can be distributed as a BGP [RFC4271] NLRI. I think this has to say “Flow Specificationsâ€, plural, yes? That matches “theyâ€. automated systems are used, care should be taken to ensure their correctness as well as the limitations of the systems that receive and process the advertised Flow Specifications How does “as well as the limitations...†fit into the sentence? There seems to be something missing here. — Section 3 — prefix as well as community matching and manipulation, must apply to the Flow Specification defined NLRI-type I can’t tell whether “Flow Specification defined†is meant to be a compound modifier for “NLRI-type†(in which case the former needs hyphens and the latter does not), or this is meant to describe a defined NLRI tyoe called “Flow Specificationâ€. I think you mean the latter. Can you re-word this or re-punctuate it to make it clear? — Section 5 — In order to achieve this goal, this document specifies two application specific NLRI identifiers that provide traffic filters, and a set of actions encoding in BGP Extended Communities. The two application specific NLRI identifiers are: Both instances of “application-specific†should be hyphenated. — Section 6 — By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true: Make it “are trueâ€. c) There are no more specific unicast routes Hyphenate “more-specific†to distinguish it from “there are no more (specific unicast routes)â€. By originator of a BGP route, we mean either the address of the But nothing else says “originator of a BGP routeâ€. (b) does say “originator of the best-match unicast routeâ€... is that what you mean here? Can you make this match up so it’s clearer? On thinking more about this text, I think maybe putting quotation marks around “originator†in the quoted sentence is all that’s needed. Specification information that conveys a more or equally specific destination prefix. This needs awkward hyphenation ti be correct. I suggest avoiding that by saying, “Specification information that conveys a destination prefix that is more or equally specific.†Thus, as long as there are no more specific unicast routes, received from a different neighboring AS, which would be affected by that Flow Specification. As above, hyphenate “more-specificâ€. And then fix the sentence, as it doesn’t appear to be a complete sentence. — Section 7 — treated as interfering Traffic filtering actions (see below). Please capitalize “Filtering Actionsâ€, to be consistent. Some Traffic Filtering Actions may interfere with each other even contradict. Make it “may interfere with or even contradict each other.†— Section 7.7 — behaviour (ie. match - replace - delete communities on administrative boundaries). I can’t understand what’s in the parentheses, nor even whether “i.e.†is correct or it should be “e.g.â€. — Section 9 — statistics facilities. While this is an implementation specific Hyphenate “implementation-specificâ€. — Section 12 — This may stress the receiving systems, exceed their maximum capacity or may lead to unwanted Traffic Filtering Actions being applied to flows. Change “capacity or may lead†to “capacity, or lead†— the “may†is already there at the start of the sentence, and the Oxford comma helps readability here. From nobody Wed Apr 22 05:49:50 2020 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 B7D723A0B7B; Wed, 22 Apr 2020 05:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 o6MCEmh7d9Gn; Wed, 22 Apr 2020 05:49:37 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 3B0FB3A0B77; Wed, 22 Apr 2020 05:49:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Barry Leiba'" , "'The IESG'" Cc: , , , "'Jie Dong'" , References: <158753687275.21086.14037095023027210670@ietfa.amsl.com> In-Reply-To: <158753687275.21086.14037095023027210670@ietfa.amsl.com> Date: Wed, 22 Apr 2020 08:49:14 -0400 Message-ID: <005901d618a4$6e2e2770$4a8a7650$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEEvI26MCYpNXOTByy5KNUXOciUtaonz3kQ Content-Language: en-us X-Antivirus: AVG (VPS 200421-2, 04/21/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Barry Leiba's No Objection on draft-ietf-idr-rfc5575bis-22: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 12:49:40 -0000 Barry:=20 Thank you for the editorial comments on this draft.=20 I'm sorry I missed the "i.e." in the edits. Of course it should be = "e.g."=20 We'll address the remainder in the next draft.=20 Sue=20 -----Original Message----- From: Barry Leiba via Datatracker [mailto:noreply@ietf.org]=20 Sent: Wednesday, April 22, 2020 2:28 AM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org; Jie Dong; aretana.ietf@gmail.com; jie.dong@huawei.com Subject: Barry Leiba's No Objection on draft-ietf-idr-rfc5575bis-22: = (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All of this is editorial: =E2=80=94 Abstract =E2=80=94 Other applications (ie. centralized control of traffic in a SDN or NFV context) are also possible. I don=E2=80=99t think you mean =E2=80=9Ci.e.=E2=80=9D here, but = =E2=80=9Ce.g.=E2=80=9D I would avoid the Latin (for exactly this = reason: many people don=E2=80=99t understand it and misuse it) and say, = =E2=80=9COther applications, such as centralized control of traffic in = an SDN or NFV context, are also possible.=E2=80=9D =E2=80=94 Section 1 =E2=80=94 Modern IP routers contain both the capability to forward traffic according to IP prefixes as well as to classify, shape, rate limit, filter, or redirect packets based on administratively defined The two things that come after =E2=80=9Cboth=E2=80=9D have to be = parallel, and they=E2=80=99re not.=20 This will read better without the word =E2=80=9Cboth=E2=80=9D, like = this: NEW Modern IP routers have the capabilities to forward traffic according to IP prefixes and to classify, shape, rate limit, filter, or redirect packets based on administratively defined END Section 4 of this document defines a general procedure to encode Flow Specification for aggregated traffic flows so that they can be distributed as a BGP [RFC4271] NLRI. I think this has to say =E2=80=9CFlow Specifications=E2=80=9D, plural, = yes? That matches =E2=80=9Cthey=E2=80=9D. automated systems are used, care should be taken to ensure their correctness as well as the limitations of the systems that receive and process the advertised Flow Specifications How does =E2=80=9Cas well as the limitations...=E2=80=9D fit into the = sentence? There seems to be something missing here. =E2=80=94 Section 3 =E2=80=94 prefix as well as community matching and manipulation, must apply to the Flow Specification defined NLRI-type I can=E2=80=99t tell whether =E2=80=9CFlow Specification = defined=E2=80=9D is meant to be a compound modifier for = =E2=80=9CNLRI-type=E2=80=9D (in which case the former needs hyphens and = the latter does not), or this is meant to describe a defined NLRI tyoe = called =E2=80=9CFlow Specification=E2=80=9D. I think you mean the = latter. Can you re-word this or re-punctuate it to make it clear? =E2=80=94 Section 5 =E2=80=94 In order to achieve this goal, this document specifies two application specific NLRI identifiers that provide traffic filters, and a set of actions encoding in BGP Extended Communities. The two application specific NLRI identifiers are: Both instances of =E2=80=9Capplication-specific=E2=80=9D should be = hyphenated. =E2=80=94 Section 6 =E2=80=94 By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true: Make it =E2=80=9Care true=E2=80=9D. c) There are no more specific unicast routes Hyphenate =E2=80=9Cmore-specific=E2=80=9D to distinguish it from = =E2=80=9Cthere are no more (specific unicast routes)=E2=80=9D. By originator of a BGP route, we mean either the address of the But nothing else says =E2=80=9Coriginator of a BGP route=E2=80=9D. (b) = does say =E2=80=9Coriginator of the best-match unicast route=E2=80=9D... = is that what you mean here? Can you make this match up so it=E2=80=99s = clearer? On thinking more about this text, I think maybe putting quotation marks = around =E2=80=9Coriginator=E2=80=9D in the quoted sentence is all = that=E2=80=99s needed. Specification information that conveys a more or equally specific destination prefix. This needs awkward hyphenation ti be correct. I suggest avoiding that = by saying, =E2=80=9CSpecification information that conveys a destination = prefix that is more or equally specific.=E2=80=9D Thus, as long as there are no more specific unicast routes, received from a different neighboring AS, which would be affected by that Flow Specification. As above, hyphenate =E2=80=9Cmore-specific=E2=80=9D. And then fix the = sentence, as it doesn=E2=80=99t appear to be a complete sentence. =E2=80=94 Section 7 =E2=80=94 treated as interfering Traffic filtering actions (see below). Please capitalize =E2=80=9CFiltering Actions=E2=80=9D, to be consistent. Some Traffic Filtering Actions may interfere with each other even contradict. Make it =E2=80=9Cmay interfere with or even contradict each = other.=E2=80=9D =E2=80=94 Section 7.7 =E2=80=94 behaviour (ie. match - replace - delete communities on administrative boundaries). I can=E2=80=99t understand what=E2=80=99s in the parentheses, nor even = whether =E2=80=9Ci.e.=E2=80=9D is correct or it should be = =E2=80=9Ce.g.=E2=80=9D. =E2=80=94 Section 9 =E2=80=94 statistics facilities. While this is an implementation specific Hyphenate =E2=80=9Cimplementation-specific=E2=80=9D. =E2=80=94 Section 12 =E2=80=94 This may stress the receiving systems, exceed their maximum capacity or may lead to unwanted Traffic Filtering Actions being applied to flows. Change =E2=80=9Ccapacity or may lead=E2=80=9D to =E2=80=9Ccapacity, or = lead=E2=80=9D =E2=80=94 the =E2=80=9Cmay=E2=80=9D is already there at = the start of the sentence, and the Oxford comma helps readability here. From nobody Wed Apr 22 06:29:19 2020 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 6B5FA3A0C4D; Wed, 22 Apr 2020 06:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTvuzX4py3m9; Wed, 22 Apr 2020 06:29:11 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 93FA93A0C48; Wed, 22 Apr 2020 06:29:11 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id f3so2342222ioj.1; Wed, 22 Apr 2020 06:29:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CRpZTAT04XIavU5LGn5fWzkAK0dvTkiHDOQA1DBMnVI=; b=UGcKl+8joaiIvfnqJT3eEYnkk+ulN+FLjjBzYaqpObbT5169xXSOs1WnH8eG1eYZcl S5oQb610DtcuZDQM2ohOb/Uk9/52ZU1MAZux8zY1N3awKZ2t+0xZHk6ozr3HjGc5mpB0 o12d/0y7yEuiRkGGbha/6ZQiK+beGbpEMy3ZuFZ3bu0h8Fr0oeHDJx6kUE3aAHnNgWKu AKm4RgK/bQ2l+nX5DWDfAdjMQY61bPVFJY6gLq35M4R08gOIUEdeKrHo34hvjTpaAglM dkiF0BmupZglx0nf/0JUW1USQ9FFEgEbgnksh06uOW2W2xN19cv9emWPD22nOt7KEVje JYmA== X-Gm-Message-State: AGi0PuZvsGUl8h5fJkdt6fm7X+9ZMg7hEkItZawowbXhHwd4wJfJIDRE PRNmCiUbjI/iQqZDrYyTkTX/YT4pRqQBGSHbf25TQ0jP X-Google-Smtp-Source: APiQypLfjcXdppOlAe4REmU/Zm1zEGTkmtv5PAXsx1CmLYjOtz0m6H56dVMrcKEgdT+9LUaU8nAdVZVuk4l7OOOSmPE= X-Received: by 2002:a5e:8613:: with SMTP id z19mr24965826ioj.84.1587562150507; Wed, 22 Apr 2020 06:29:10 -0700 (PDT) MIME-Version: 1.0 References: <158753687275.21086.14037095023027210670@ietfa.amsl.com> <005901d618a4$6e2e2770$4a8a7650$@ndzh.com> In-Reply-To: <005901d618a4$6e2e2770$4a8a7650$@ndzh.com> From: Barry Leiba Date: Wed, 22 Apr 2020 09:28:59 -0400 Message-ID: To: Susan Hares Cc: The IESG , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , =?UTF-8?Q?=C3=81lvaro_Retana?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] Barry Leiba's No Objection on draft-ietf-idr-rfc5575bis-22: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 13:29:14 -0000 Thanks for the quick response, Sue. Stay well... Barry On Wed, Apr 22, 2020 at 8:49 AM Susan Hares wrote: > > Barry: > > Thank you for the editorial comments on this draft. > > I'm sorry I missed the "i.e." in the edits. Of course it should be "e.g= ." > > We'll address the remainder in the next draft. > > Sue > > -----Original Message----- > From: Barry Leiba via Datatracker [mailto:noreply@ietf.org] > Sent: Wednesday, April 22, 2020 2:28 AM > To: The IESG > Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org= ; Jie Dong; aretana.ietf@gmail.com; jie.dong@huawei.com > Subject: Barry Leiba's No Objection on draft-ietf-idr-rfc5575bis-22: (wit= h COMMENT) > > Barry Leiba has entered the following ballot position for > draft-ietf-idr-rfc5575bis-22: No Objection > > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > All of this is editorial: > > =E2=80=94 Abstract =E2=80=94 > > Other applications (ie. centralized control of traffic in a SDN or > NFV context) are also possible. > > I don=E2=80=99t think you mean =E2=80=9Ci.e.=E2=80=9D here, but =E2=80=9C= e.g.=E2=80=9D I would avoid the Latin (for exactly this reason: many peopl= e don=E2=80=99t understand it and misuse it) and say, =E2=80=9COther applic= ations, such as centralized control of traffic in an SDN or NFV context, ar= e also possible.=E2=80=9D > > =E2=80=94 Section 1 =E2=80=94 > > Modern IP routers contain both the capability to forward traffic > according to IP prefixes as well as to classify, shape, rate limit, > filter, or redirect packets based on administratively defined > > The two things that come after =E2=80=9Cboth=E2=80=9D have to be parallel= , and they=E2=80=99re not. > This will read better without the word =E2=80=9Cboth=E2=80=9D, like this: > > NEW > Modern IP routers have the capabilities to forward traffic > according to IP prefixes and to classify, shape, rate limit, > filter, or redirect packets based on administratively defined END > > Section 4 of this document defines a general procedure to encode Flow > Specification for aggregated traffic flows so that they can be > distributed as a BGP [RFC4271] NLRI. > > I think this has to say =E2=80=9CFlow Specifications=E2=80=9D, plural, ye= s? That matches =E2=80=9Cthey=E2=80=9D. > > automated systems are used, care should be taken to ensure their > correctness as well as the limitations of the systems that receive > and process the advertised Flow Specifications > > How does =E2=80=9Cas well as the limitations...=E2=80=9D fit into the sen= tence? There seems to be something missing here. > > =E2=80=94 Section 3 =E2=80=94 > > prefix as well as community matching and manipulation, must apply to > the Flow Specification defined NLRI-type > > I can=E2=80=99t tell whether =E2=80=9CFlow Specification defined=E2=80=9D= is meant to be a compound modifier for =E2=80=9CNLRI-type=E2=80=9D (in whi= ch case the former needs hyphens and the latter does not), or this is meant= to describe a defined NLRI tyoe called =E2=80=9CFlow Specification=E2=80= =9D. I think you mean the latter. Can you re-word this or re-punctuate it= to make it clear? > > =E2=80=94 Section 5 =E2=80=94 > > In order to achieve this goal, this document specifies two > application specific NLRI identifiers that provide traffic filters, > and a set of actions encoding in BGP Extended Communities. The two > application specific NLRI identifiers are: > > Both instances of =E2=80=9Capplication-specific=E2=80=9D should be hyphen= ated. > > =E2=80=94 Section 6 =E2=80=94 > > By default a Flow Specification NLRI MUST be validated such that it > is considered feasible if and only if all of the below is true: > > Make it =E2=80=9Care true=E2=80=9D. > > c) There are no more specific unicast routes > > Hyphenate =E2=80=9Cmore-specific=E2=80=9D to distinguish it from =E2=80= =9Cthere are no more (specific unicast routes)=E2=80=9D. > > By originator of a BGP route, we mean either the address of the > > But nothing else says =E2=80=9Coriginator of a BGP route=E2=80=9D. (b) d= oes say =E2=80=9Coriginator of the best-match unicast route=E2=80=9D... is = that what you mean here? Can you make this match up so it=E2=80=99s cleare= r? > > On thinking more about this text, I think maybe putting quotation marks a= round =E2=80=9Coriginator=E2=80=9D in the quoted sentence is all that=E2=80= =99s needed. > > Specification information that conveys a more or equally specific > destination prefix. > > This needs awkward hyphenation ti be correct. I suggest avoiding that by= saying, =E2=80=9CSpecification information that conveys a destination pref= ix that is more or equally specific.=E2=80=9D > > Thus, as long as there are no more specific > unicast routes, received from a different neighboring AS, which would > be affected by that Flow Specification. > > As above, hyphenate =E2=80=9Cmore-specific=E2=80=9D. And then fix the se= ntence, as it doesn=E2=80=99t appear to be a complete sentence. > > =E2=80=94 Section 7 =E2=80=94 > > treated as interfering Traffic filtering actions (see below). > > Please capitalize =E2=80=9CFiltering Actions=E2=80=9D, to be consistent. > > Some Traffic Filtering Actions may interfere with each other even > contradict. > > Make it =E2=80=9Cmay interfere with or even contradict each other.=E2=80= =9D > > =E2=80=94 Section 7.7 =E2=80=94 > > behaviour (ie. match - replace - delete communities on administrative > boundaries). > > I can=E2=80=99t understand what=E2=80=99s in the parentheses, nor even wh= ether =E2=80=9Ci.e.=E2=80=9D is correct or it should be =E2=80=9Ce.g.=E2=80= =9D. > > =E2=80=94 Section 9 =E2=80=94 > > statistics facilities. While this is an implementation specific > > Hyphenate =E2=80=9Cimplementation-specific=E2=80=9D. > > =E2=80=94 Section 12 =E2=80=94 > > This may stress the receiving systems, exceed their > maximum capacity or may lead to unwanted Traffic Filtering Actions > being applied to flows. > > Change =E2=80=9Ccapacity or may lead=E2=80=9D to =E2=80=9Ccapacity, or le= ad=E2=80=9D =E2=80=94 the =E2=80=9Cmay=E2=80=9D is already there at the sta= rt of the sentence, and the Oxford comma helps readability here. > > > > From nobody Wed Apr 22 06:46:16 2020 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 EF7453A0CA6; Wed, 22 Apr 2020 06:46:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158756317450.27447.7394258570701485593@ietfa.amsl.com> Date: Wed, 22 Apr 2020 06:46:14 -0700 Archived-At: Subject: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 13:46:15 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Apologies as this may be a really silly question, but isn't it possible for traffic-rate-bytes and traffic-rate-packets to interfere with each other? That is, if by mistake a flow specification shows up containing both actions and they contradict each other (e.g., 0 bytes but 1M packets), how is that situation supposed to be handled? From nobody Wed Apr 22 06:53:22 2020 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 BD41B3A0BD6; Wed, 22 Apr 2020 06:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 fPaPZYxfxOhM; Wed, 22 Apr 2020 06:53:07 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 4DE843A0CD4; Wed, 22 Apr 2020 06:53:07 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id u16so2452058wmc.5; Wed, 22 Apr 2020 06:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=N9ns7ABOzO8B8dyIsnvJmS1me94cbVfdPwG2pPF+ICo=; b=r8qTusVliNG0RvJLeVak5ZnB5szLhrAD+Aq4OdSOEGeqeRgigR6WzGJeIBvcTrRXds 1QjT2blEZHL2NFfobt08CLTM9IedNiYjYlh8vqs1MuInnqL4isEMeVt5up4D+ia4dAkh IuGBtPT2Br4Nitkotj6+QRoaaPT1ipenjCYix8YiJows5UT1sTX7y4/feqIOqJ2uDKfC Q6FePOu+ztWft4IrdPNVFqNaGPkqiLe8PHUGBkRQ8U4qpagHLu0FFi2eoQSC0zymw9bY 5xADsyq5OLPvulVJ033q2cP3uIOJC4IIiZy3TphXaklfpfuCmYUZNsnrzPxx8WdBX4rn 2aOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=N9ns7ABOzO8B8dyIsnvJmS1me94cbVfdPwG2pPF+ICo=; b=L70RKUUVeVOe6vjCYW9ZPF0tBOjjb+T0PlI+O/cylUGHJji29uPrwbB7iy5F1SqrkE utOmrQYUOqd28knsMucZP9ggx6HJ/Ox+zvCY45aqaF744fs6MreZqUAIXOZYDJUZf2CT tyf1c3n3HACrVCZcp4K8hM+/8QlTKk73J9s7IiW7+AoneHvWcYNmfcyehUzlCpQY/1Q3 Kgdj0z9IllOFwWvGddh7jz2H5Qn9ErQvUCsQc9U4ta3xc4jBLuuibLljemNEbGzcoAEd o1xix/UGKIaVIAV/69mGOuZZXeoUqGHjtD9mkejwtPaR6EehrPFWPp7d4Z2OBvE7r+uP t2sA== X-Gm-Message-State: AGi0PuYinTpjqS9+lLIZjzR5N0Wnhj6wa8jiCg8UuY9lUY3BGZjLKO4l meSFrBvkZSrPcebJIPHuzH9CYgatq24uGn+Cjr8LDIXc X-Google-Smtp-Source: APiQypJq6wutKjrOQlRYgIxVQgSwLWahyrkunvkWYxKALaPC2QXB35KbbVxyzNBdDq0ba+MiXQxTRJ8HgKSLACNFC4g= X-Received: by 2002:a1c:f312:: with SMTP id q18mr10700655wmq.175.1587563585506; Wed, 22 Apr 2020 06:53:05 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 Apr 2020 06:53:04 -0700 From: Alvaro Retana In-Reply-To: <158756317450.27447.7394258570701485593@ietfa.amsl.com> References: <158756317450.27447.7394258570701485593@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 22 Apr 2020 06:53:04 -0700 Message-ID: To: Alissa Cooper Cc: idr-chairs@ietf.org, draft-ietf-idr-rfc5575bis@ietf.org, Jie Dong , idr@ietf.org, The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 13:53:16 -0000 On April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote: Alissa: Hi! > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Apologies as this may be a really silly question, but isn't it possible f= or > traffic-rate-bytes and traffic-rate-packets to interfere with each other? > That is, if by mistake a flow specification shows up containing both acti= ons > and they contradict each other (e.g., 0 bytes but 1M packets), how is tha= t > situation supposed to be handled? See =C2=A77.7. =C2=A0It is left to the implementation to decide which filte= ring action to use. Alvaro. From nobody Wed Apr 22 06:55:36 2020 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 C31A43A0CBE; Wed, 22 Apr 2020 06:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=09KoZb5N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GCPUCsTw 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 A42sHrxyh1J2; Wed, 22 Apr 2020 06:55:14 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE0C3A0CAA; Wed, 22 Apr 2020 06:55:13 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6E5AE5C00B5; Wed, 22 Apr 2020 09:55:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 22 Apr 2020 09:55:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=ZTCgjJCsgnf6zVMcmTDiIy/ oLCW4A0iGDh7AqnltlMA=; b=09KoZb5NKezq/ZyYm0nxLkhznTglcnR40cAplQl XslqAparO0sKvQSMmruM4WFWfzRrfTT9X8Bri5nHt1qjjw7TY128feA4sh0hMMcK Awg7lacFGz8p6nSe9w5rpSGQsdl/HPN540o8FLLWUMht2aDQYI8DUyxa7mSbCjxA 7EVCcRZWCI2pQ+mmkN3HfOVSVNCLAF1BlrSYK0PzO+DQXRvOXwmK6HY1jKYJSidm ydh9Gil2CXhq9ZxfikaR/8Iewz1NAXSoaEBvYHHjlWsfcdZyXwa2A98lvW4UeAmv 8UCCC0wdVNApp4MsEjBUHhM+gv2UL6pgyFiwdGGLmYfPUGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ZTCgjJ Csgnf6zVMcmTDiIy/oLCW4A0iGDh7AqnltlMA=; b=GCPUCsTwewwZDULRP/i6I8 jdX9I7wtnhxF1enptD3CAfL0GXCXjjYhuz5rniOCRci2gJ2zf9MbwYwynOCgqmcz zQXsLJuAg97ysq3RHAsIwfEmzRD2JhGp4l+colNORhPCRqlRtYlh2srpgEjHROvr le0Q4VZoh6PmTaxYeBilExUxzQ0cxvzLixzV6CthojNgK84ju8e3LH1JUk92lOSY LOEeoPZbKT+pVnGMB+IB+rGtlUkMRpSdcl2FU5Yef6LPXyzUKkv+tYvufBT7RDG4 N9FdPICtrN/tFIq1G7dKTyHk6BxDDLdqG/Fg2foRQWvc7SyVVD+bRc2OG8Hj+usA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffktgggufffjgfvfhfosegrtdhmre hhtdejnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceorghlihhsshgrsegtohho phgvrhifrdhinheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpnhgvgihtlhgrhi gvrhdrrghtpdhivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejkeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrg estghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id B640E3065CDF; Wed, 22 Apr 2020 09:55:10 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F69FD258-EE59-4822-A3B9-096D0AC9F5F2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Wed, 22 Apr 2020 09:55:06 -0400 In-Reply-To: <42014AE1-D058-486E-9E17-475D07A91885@tix.at> Cc: last-call@ietf.org, General Area Review Team , draft-ietf-idr-rfc5575bis.all@ietf.org, IDR List To: Christoph Loibl , Gyan Mishra References: <158629580378.13606.6350807287790835622@ietfa.amsl.com> <42014AE1-D058-486E-9E17-475D07A91885@tix.at> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Idr] [Gen-art] Genart last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 13:55:17 -0000 --Apple-Mail=_F69FD258-EE59-4822-A3B9-096D0AC9F5F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gyan, thanks for your review. Christoph, thanks for your response. I = think the intro in the draft is ok as-is. I entered a DISCUSS ballot = with a question about Section 7. Alissa > On Apr 17, 2020, at 3:43 AM, Christoph Loibl wrote: >=20 > Hi Gyan, >=20 > Thanks for your review. According to your review I made the following = changes to the document which is available now as revision -22: >=20 >> On 07.04.2020, at 23:43, Gyan Mishra via Datatracker = > wrote: >>=20 >> Reviewer: Gyan Mishra >> Review result: Ready with Nits >>=20 >> Reviewer: Gyan Mishra >> Review result: Ready with Minor Issues >>=20 >> Minor issues: >> I am familiar with BGP Flow specification and would like to recommend = some >> verbiage that may help in the introduction as far as explaining how = BGP flow >> spec works. Ssince the introduction has been re-written with this = update, this >> could be a possible addition to the draft. >>=20 >> This could be placed at the end of the introduction if desired. >> BGP flow specification is a client-server model that allows for a = more granular >> approach to DDOS mitigation than its predecessor, =E2=80=9CRemotely = Triggered Blackhole >> (RTBF) which tagged a prefix with a community and sent it do a = discard next >> hop. BGP flow spec has two main components, the =E2=80=9Ccontroller=E2= =80=9D being the BGP >> speaker device which acts as the server side, which injects the new = flowspec >> entry, and the client side which is the BGP speaker devices that = receives the >> flowspec NLRI and acts on the instruction to match a particular flow = with Layer >> 3 and Layer 4 parameters and then implements the hardware forwarding = action >> requested. >=20 > <--=20 > Tracked via issue #163: = https://github.com/stoffi92/rfc5575bis/issues/163 = >=20 > I do not agree that BGP flowspec is a client-server model -only-. We = can propagate this NLRI over administrative domain borders as we do with = IP routing information, it follows the same mechanisms. We see such = solutions being deployed in the internet as inter provider DDoS = solutions. >=20 > We actually had a paragraph in the darft that was explaining the = advantages over other approaches like RTBF but this has been removed = because it was pointed out that it is not relevant to the spec to = justify a well deployed technology. > --> >=20 >=20 >> Nits/editorial comments: >> 7. Traffic Filtering Actions >> This document defines a minimum set of Traffic Filtering Actions = that >> it standardizes as BGP extended community values [RFC4360] >>=20 >> Any mention of [RFC4360] should be updated with [RFC7153] IANA = Registries >> for BGP Extended Communities. >>=20 >=20 > <--=20 > Tracked via issue #164: = https://github.com/stoffi92/rfc5575bis/issues/164 = > Commits mentions: > = https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa2750fd376dc= 148d7a590369 = > = https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7d5c1822070b= 862247dfaead = >=20 > Removed the "values" statement (as suggested by Alvaro) from the draft = to make clear we are not talking about particular values but about = Extended Communities as specified in RFC4360. > s/standardizes as BGP extended community values [RFC4360]/standardizes = as BGP extended communities [RFC4360]/ >=20 > --> >=20 > Cheers=20 > Christoph >=20 > --=20 > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | = http://www.nextlayer.at >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_F69FD258-EE59-4822-A3B9-096D0AC9F5F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Gyan,= thanks for your review. Christoph, thanks for your response. I think = the intro in the draft is ok as-is. I entered a DISCUSS ballot with a = question about Section 7.

Alissa


On Apr = 17, 2020, at 3:43 AM, Christoph Loibl <c@tix.at> wrote:

Hi Gyan,

Thanks for your review. According to your review I made the = following changes to the document which is available now as revision = -22:

On 07.04.2020, at 23:43, Gyan Mishra via = Datatracker <noreply@ietf.org> wrote:

Reviewer: Gyan Mishra
Review result: Ready with = Nits

Reviewer: Gyan Mishra
Review result: Ready with Minor Issues

Minor issues:
I am familiar with BGP Flow = specification and would like to recommend some
verbiage = that may help in the introduction as far as explaining how BGP flow
spec works.  Ssince the introduction has been re-written = with this update, this
could be a possible addition to the = draft.

This could be placed at the end of = the introduction if desired.
BGP flow specification is a = client-server model that allows for a more granular
approach= to DDOS mitigation than its predecessor, =E2=80=9CRemotely Triggered = Blackhole
(RTBF) which tagged a prefix with a community = and sent it do a discard next
hop.  BGP flow spec has = two main components, the =E2=80=9Ccontroller=E2=80=9D being the BGP
speaker device which acts as the server side, which injects = the new flowspec
entry, and the client side which is the = BGP speaker devices that receives the
flowspec NLRI and = acts on the instruction to match a particular flow with Layer
3 and Layer 4 parameters and then implements the hardware = forwarding action
requested.

<-- 
Tracked via = issue #163: https://github.com/stoffi92/rfc5575bis/issues/163

I do not agree that BGP flowspec is a = client-server model -only-. We can propagate this NLRI over = administrative domain borders as we do with IP routing information, it = follows the same mechanisms. We see such solutions being deployed in the = internet as inter provider DDoS solutions.

We= actually had a paragraph in the darft that was explaining the = advantages over other approaches like RTBF but this has been removed = because it was pointed out that it is not relevant to the spec to = justify a well deployed technology.
-->


Nits/editorial comments:
7.  Traffic = Filtering Actions
  This document defines a = minimum set of Traffic Filtering Actions that
  it= standardizes as BGP extended community values [RFC4360]
  Any mention of [RFC4360] should be updated with = [RFC7153] IANA Registries
  for BGP Extended = Communities.


<-- 
Tracked via issue #164: https://github.com/stoffi92/rfc5575bis/issues/164
Commits mentions:
    https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa= 2750fd376dc148d7a590369
    https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7= d5c1822070b862247dfaead

Removed the = "values" statement (as suggested by Alvaro) from the draft to make clear = we are not talking about particular values but about  Extended = Communities as specified in RFC4360.
s/standardizes as BGP = extended community values [RFC4360]/standardizes as BGP extended = communities [RFC4360]/

-->

Cheers 
Christoph

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



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_F69FD258-EE59-4822-A3B9-096D0AC9F5F2-- From nobody Wed Apr 22 07:03:07 2020 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 35D4E3A0CD1; Wed, 22 Apr 2020 07:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=qeCAUCoe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VGfbTPk+ 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 O3FQ1rGkv-gE; Wed, 22 Apr 2020 07:03:04 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B213A0CCA; Wed, 22 Apr 2020 07:03:03 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0E13C5C01FA; Wed, 22 Apr 2020 10:03:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Apr 2020 10:03:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=p voN+9jfU4F8EaJy3HED9inYW7VrC/E2aEtWiU7SklU=; b=qeCAUCoeqryN7+2BZ wL+lq7qV6Bl2BSPNNMbsPYxshwyj8sPc4qhhdKzj7EeBYn8rKVstJFZjUfndAQOu L6lNUq/oZ617agI62FDp+kkCBnK/wodgRSQP3f/hep9RyFI1/hq52pSMIXG7gtlE qLl5zZzejEkBrA2eCWJ2CB5F/LKRWknFg59sbqFfLna8OGC+hHMl011jN0wxvU4E ywm392k/DTvYrrx3PnGMcaF+bwghtwNtFhVOrNO3ClMg4GMJ5is7awkYAul2upli b2bTBWbbgibYDuundojelnPMTSEdprsGpcC3GYGNTPo8J08z6ZrpJ7hikOJACb7m OlbBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=pvoN+9jfU4F8EaJy3HED9inYW7VrC/E2aEtWiU7Sk lU=; b=VGfbTPk+fAvt1kzPMvPTDeI7y1U/7AHLMDDxmVgYoNV1J3Wg2welas7n4 wcDZHcheFu9axPDmeJvRMSGTGsZJk4kgdOyHC7WwXNV5y5hd/isaL0YG3rBE25DI BiGmTapvp8EIGSNXfIjHbc/9yolZNP/8fPaZ3kkw42rLfZ9ddxRc9wGGWBYIPwiH DAycltNv7VI0a5QhiI2Qy8KYU0I7Zkiu/E4RzL9u2Qqo+d7uExe2ZtTlPDgW/cmN S+v9fI5yQa7HIbZ0wpPj7/k1kF0GJ2Xuo02VbXVsaP8321e7e5Vxyj01Y+vt2RnW 8eYLclMMKZrDNHSD5YYINYPR6A2uA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppeduje efrdefkedruddujedrjeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id D594C3280060; Wed, 22 Apr 2020 10:03:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: Date: Wed, 22 Apr 2020 10:02:57 -0400 Cc: idr-chairs@ietf.org, draft-ietf-idr-rfc5575bis@ietf.org, Jie Dong , idr@ietf.org, IESG Content-Transfer-Encoding: quoted-printable Message-Id: <2316B33C-8C79-4A23-B126-5B4D6EB11FBC@cooperw.in> References: <158756317450.27447.7394258570701485593@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 14:03:05 -0000 Hi Alvaro, > On Apr 22, 2020, at 9:53 AM, Alvaro Retana = wrote: >=20 > On April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote: >=20 >=20 > Alissa: >=20 > Hi! >=20 >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Apologies as this may be a really silly question, but isn't it = possible for >> traffic-rate-bytes and traffic-rate-packets to interfere with each = other? >> That is, if by mistake a flow specification shows up containing both = actions >> and they contradict each other (e.g., 0 bytes but 1M packets), how is = that >> situation supposed to be handled? >=20 > See =C2=A77.7. It is left to the implementation to decide which = filtering > action to use. Right, but 7.1 and 7.2 say that traffic-rate-bytes and = traffic-rate-packets don=E2=80=99t interfere with each other (or any = other filtering actions specified), so presumably 7.7 does not apply?=20 Alissa >=20 >=20 > Alvaro. From nobody Wed Apr 22 08:52:32 2020 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 6D1943A0F19; Wed, 22 Apr 2020 08:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 axuKBuzzd4jO; Wed, 22 Apr 2020 08:52:29 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 98EE23A0F20; Wed, 22 Apr 2020 08:52:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Alissa Cooper'" , "'Alvaro Retana'" Cc: , , , "'IESG'" References: <158756317450.27447.7394258570701485593@ietfa.amsl.com> <2316B33C-8C79-4A23-B126-5B4D6EB11FBC@cooperw.in> In-Reply-To: <2316B33C-8C79-4A23-B126-5B4D6EB11FBC@cooperw.in> Date: Wed, 22 Apr 2020 11:52:23 -0400 Message-ID: <006201d618be$03e4afa0$0bae0ee0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFY6rrzI6CfE5KyY0tWxrUe2MJIswGDYWKhAhzuiHqpYqB0cA== Content-Language: en-us X-Antivirus: AVG (VPS 200421-2, 04/21/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 15:52:31 -0000 Alissa and Alvaro:=20 Alissa discuss is correct. =20 My solution to fix this is to provide the following revisions:=20 Section 7.1:=20 Old/ Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. / New/ Interferes with: May interfere with the traffic-rate-packets (see = section 7.2). Policy may allow both filtering by traffic-rate-packets and = traffic-rate-bytes.=20 If policy does not allow this, these two actions will conflict. =20 / =20 Section 7.2=20 Old/ Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. / Interferes with: May interfere with the traffic-rate-bytes (see = section 7.1)=20 Policy may allow both filtering by traffic-rate-packets and = traffic-rate-bytes.=20 If policy does not allow this, these two actions will conflict. =20 / If this fix is acceptable to both of you, please let me know. We will = re-spin the draft.=20 Sue Hares=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Wednesday, April 22, 2020 10:03 AM To: Alvaro Retana Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org; IESG Subject: Re: [Idr] Alissa Cooper's Discuss on = draft-ietf-idr-rfc5575bis-22: (with DISCUSS) Hi Alvaro, > On Apr 22, 2020, at 9:53 AM, Alvaro Retana = wrote: >=20 > On April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote: >=20 >=20 > Alissa: >=20 > Hi! >=20 >=20 >> --------------------------------------------------------------------- >> - >> DISCUSS: >> --------------------------------------------------------------------- >> - >>=20 >> Apologies as this may be a really silly question, but isn't it=20 >> possible for traffic-rate-bytes and traffic-rate-packets to interfere = with each other? >> That is, if by mistake a flow specification shows up containing both=20 >> actions and they contradict each other (e.g., 0 bytes but 1M=20 >> packets), how is that situation supposed to be handled? >=20 > See =C2=A77.7. It is left to the implementation to decide which = filtering=20 > action to use. Right, but 7.1 and 7.2 say that traffic-rate-bytes and = traffic-rate-packets don=E2=80=99t interfere with each other (or any = other filtering actions specified), so presumably 7.7 does not apply?=20 Alissa >=20 >=20 > Alvaro. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Apr 22 08:56:42 2020 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 7EB463A0F6A; Wed, 22 Apr 2020 08:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=W5S7ZDKA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pCAsvukz 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 5YiI14JWvAdw; Wed, 22 Apr 2020 08:56:33 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC1C3A0F79; Wed, 22 Apr 2020 08:56:33 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 914085C01F4; Wed, 22 Apr 2020 11:56:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 22 Apr 2020 11:56:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=D yOadCZjk/MSd5CSDypAZwbk7jMO76XVflefTVDxdfM=; b=W5S7ZDKATQb04LVdc JZLTT3BajxIIBaPRj1f/6Jd1Gkpfy3elMDly1JG23oGHWsqXN1g/sPEs7BovZYK1 z5jtsZKbuyGH7mxhmKkZ6yQJrblBv63xBfO0R+R6tPc0yIRt9KyH0El46CIjpzzp qKL97H8tbOuo+dZKT3L/H4Bbv6G2fhMaDqfKfjLTpmkgtAvZTje8TbB17U0aZQtR 1wi9tDllW/kn00SvHx802xI3PVps0CbZuOScqv0A7DGY5AL30QC+WleWyi6ug+LO NOGym/KyDDgW6UCKrfgECXuTyQ2JkL8Mk7nEwa1769lfQC4z0k3msWpW6Ohg7VOk MrJEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=DyOadCZjk/MSd5CSDypAZwbk7jMO76XVflefTVDxd fM=; b=pCAsvukziQqvYwX7M2ey/vIax9TV3PoxzArwGSfcj05nheydCWDMgbMIi n90rs4aD0fympB96y8ku6+7dTddsw3ONfWUk0cJgewmEqwDka5MFtErYaFC+lUjZ di59DkToAQLG2D62p/8QUFDX/F5hIBeOPoQHOjM7EMdZ7jKaUzde5NkraPg0HyOW w4jFziJRM4tZwcjgZkfmqvh/ewNnFpN/9ejXIbcEmIiE8lgvk7I5FvxL6w39Qk/f MvZW700buGGUI7vz0aO1Gx6Ms83VIco1vYfa93AiJ1jXa40CkKSJ5hjwnR3zSq3U D0+k4+n23L0CG5cN/sg98Vy2oJjbg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpeguohgtuhhmvghnthdrnhgvfidpihgvthhfrdhorhhgnecukfhppedujeefrdefkedr uddujedrjeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id C0D3C3065CE3; Wed, 22 Apr 2020 11:56:31 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: <006201d618be$03e4afa0$0bae0ee0$@ndzh.com> Date: Wed, 22 Apr 2020 11:56:27 -0400 Cc: Alvaro Retana , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, IESG , idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3FC2341A-4760-4129-9DE3-536515C2FC6F@cooperw.in> References: <158756317450.27447.7394258570701485593@ietfa.amsl.com> <2316B33C-8C79-4A23-B126-5B4D6EB11FBC@cooperw.in> <006201d618be$03e4afa0$0bae0ee0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 15:56:36 -0000 Works for me. Thanks. Alissa > On Apr 22, 2020, at 11:52 AM, Susan Hares wrote: >=20 > Alissa and Alvaro:=20 >=20 > Alissa discuss is correct. =20 >=20 > My solution to fix this is to provide the following revisions:=20 >=20 > Section 7.1:=20 > Old/ > Interferes with: No other BGP Flow Specification Traffic Filtering > Action in this document. > / > New/ > Interferes with: May interfere with the traffic-rate-packets (see = section 7.2). > Policy may allow both filtering by traffic-rate-packets and = traffic-rate-bytes.=20 > If policy does not allow this, these two actions will conflict. =20 > / =20 > Section 7.2=20 > Old/ > Interferes with: No other BGP Flow Specification Traffic Filtering > Action in this document. > / > Interferes with: May interfere with the traffic-rate-bytes (see = section 7.1)=20 > Policy may allow both filtering by traffic-rate-packets and = traffic-rate-bytes.=20 > If policy does not allow this, these two actions will conflict. =20= > / >=20 > If this fix is acceptable to both of you, please let me know. We = will re-spin the draft.=20 >=20 > Sue Hares=20 >=20 >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Wednesday, April 22, 2020 10:03 AM > To: Alvaro Retana > Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org; IESG > Subject: Re: [Idr] Alissa Cooper's Discuss on = draft-ietf-idr-rfc5575bis-22: (with DISCUSS) >=20 > Hi Alvaro, >=20 >> On Apr 22, 2020, at 9:53 AM, Alvaro Retana = wrote: >>=20 >> On April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote: >>=20 >>=20 >> Alissa: >>=20 >> Hi! >>=20 >>=20 >>> = --------------------------------------------------------------------- >>> - >>> DISCUSS: >>> = --------------------------------------------------------------------- >>> - >>>=20 >>> Apologies as this may be a really silly question, but isn't it=20 >>> possible for traffic-rate-bytes and traffic-rate-packets to = interfere with each other? >>> That is, if by mistake a flow specification shows up containing both=20= >>> actions and they contradict each other (e.g., 0 bytes but 1M=20 >>> packets), how is that situation supposed to be handled? >>=20 >> See =C2=A77.7. It is left to the implementation to decide which = filtering=20 >> action to use. >=20 > Right, but 7.1 and 7.2 say that traffic-rate-bytes and = traffic-rate-packets don=E2=80=99t interfere with each other (or any = other filtering actions specified), so presumably 7.7 does not apply?=20 >=20 > Alissa >=20 >>=20 >>=20 >> Alvaro. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From nobody Wed Apr 22 09:31:35 2020 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 77DB73A0FB2; Wed, 22 Apr 2020 09:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8MKA5OHF9ZGW; Wed, 22 Apr 2020 09:31:30 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 F24963A0FAC; Wed, 22 Apr 2020 09:31:29 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id h2so3106551wmb.4; Wed, 22 Apr 2020 09:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=fvglh/5+A9ZGJ9ZGOBCldXawGuikR0mwlUHSF4+PK4A=; b=bd4G4vPjpeGRgtvfYF++HzAV7cR2qw+o/8MfZrbMT/w4q+9kEsRA5T+rJ/0yGqorfb feQdNCEYPW2fazEk+6g0y+9Wsdvwc7e25I0GKh5BogLQUD1B6hYD3sKmrNXOYu6E1i2u 34AJNoPjZvNQG4sI5OQtKq0gFDMgvdel/GYi8Xl8bMeO7tl5Nl5IhqSIw87m1IvSeQVP d6vZ9I6yHT24NuAiClz4kMlMIrnrneQLptLKB8d7o7Yd6+72M2v0A6IEbx/OK5BViZh0 rSf0M5oNCl9lZnqFL6pFPpQRl5kO9A22sF52zmlRziUGxjezRDao9YrlL04u9SSbrrx2 k2iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=fvglh/5+A9ZGJ9ZGOBCldXawGuikR0mwlUHSF4+PK4A=; b=Yl2RREpbzoMQCXbzrkNI08jstTTbrcnO5c/ITsBs/WRh9eEuGAd6GPGRUKdioQMCw7 si2ZAanoRCcP9jaR63DWWBTQzGhTsMpIdZzOsEwRgmJs2OmhTjcXVym80HIagnWRKvp1 yqrC9N4JonUUe812IXY8pDHLLj8b20/yCvNupnt0WUd2Zy6Z7/alrBdA5279hrtJnFk3 9jA/RKmVe2uCR2Idc5ytL0DtF3jh7vUYHnxAq9nTeHzmQRmBY7zfQSw8Q9FeEFxzCvnI LWm4sMcf4Va9ZbQxz+F9Xzdj9geQjboTuZp97B5s4XgLP0rHvn+48oCoR5Ypv7l0eqxz YYSA== X-Gm-Message-State: AGi0Puaow2TvVNI4SVEu2HRpmbuRmphYKUr3CxMVjgB0nFw5Vmv8nVHx 1b6x1Nk8srcBvgr1N3GEj5siS7x8FsMbjSstyNrBVbLK X-Google-Smtp-Source: APiQypKR0k+54jDY/lGLuyUZ5N3jA16ar6MJSw9jODxgrT5KrDOI/n5+zOazYEPkIRLwEK5W9rGR4qXJHleoAA4xNn4= X-Received: by 2002:a1c:4b16:: with SMTP id y22mr11472938wma.170.1587573088321; Wed, 22 Apr 2020 09:31:28 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 Apr 2020 09:31:27 -0700 From: Alvaro Retana In-Reply-To: <3FC2341A-4760-4129-9DE3-536515C2FC6F@cooperw.in> References: <158756317450.27447.7394258570701485593@ietfa.amsl.com> <2316B33C-8C79-4A23-B126-5B4D6EB11FBC@cooperw.in> <006201d618be$03e4afa0$0bae0ee0$@ndzh.com> <3FC2341A-4760-4129-9DE3-536515C2FC6F@cooperw.in> MIME-Version: 1.0 Date: Wed, 22 Apr 2020 09:31:27 -0700 Message-ID: To: Alissa Cooper , Susan Hares Cc: idr-chairs@ietf.org, draft-ietf-idr-rfc5575bis@ietf.org, IESG , idr@ietf.org Content-Type: multipart/alternative; boundary="000000000000fc050305a3e3a9e1" Archived-At: Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 16:31:33 -0000 --000000000000fc050305a3e3a9e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Works for me too. Thanks! Alvaro. On April 22, 2020 at 11:56:33 AM, Alissa Cooper (alissa@cooperw.in) wrote: Works for me. Thanks. Alissa > On Apr 22, 2020, at 11:52 AM, Susan Hares wrote: > > Alissa and Alvaro: > > Alissa discuss is correct. > > My solution to fix this is to provide the following revisions: > > Section 7.1: > Old/ > Interferes with: No other BGP Flow Specification Traffic Filtering > Action in this document. > / > New/ > Interferes with: May interfere with the traffic-rate-packets (see section 7.2). > Policy may allow both filtering by traffic-rate-packets and traffic-rate-bytes. > If policy does not allow this, these two actions will conflict. > / > Section 7.2 > Old/ > Interferes with: No other BGP Flow Specification Traffic Filtering > Action in this document. > / > Interferes with: May interfere with the traffic-rate-bytes (see section 7.1) > Policy may allow both filtering by traffic-rate-packets and traffic-rate-bytes. > If policy does not allow this, these two actions will conflict. > / > > If this fix is acceptable to both of you, please let me know. We will re-spin the draft. > > Sue Hares > > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Wednesday, April 22, 2020 10:03 AM > To: Alvaro Retana > Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org= ; IESG > Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) > > Hi Alvaro, > >> On Apr 22, 2020, at 9:53 AM, Alvaro Retana wrote: >> >> On April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote: >> >> >> Alissa: >> >> Hi! >> >> >>> --------------------------------------------------------------------- >>> - >>> DISCUSS: >>> --------------------------------------------------------------------- >>> - >>> >>> Apologies as this may be a really silly question, but isn't it >>> possible for traffic-rate-bytes and traffic-rate-packets to interfere with each other? >>> That is, if by mistake a flow specification shows up containing both >>> actions and they contradict each other (e.g., 0 bytes but 1M >>> packets), how is that situation supposed to be handled? >> >> See =C2=A77.7. It is left to the implementation to decide which filterin= g >> action to use. > > Right, but 7.1 and 7.2 say that traffic-rate-bytes and traffic-rate-packets don=E2=80=99t interfere with each other (or any other filtering actions specified), so presumably 7.7 does not apply? > > Alissa > >> >> >> Alvaro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --000000000000fc050305a3e3a9e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Works for me too.

Thanks!

Alvaro.

On April 22, 2020 = at 11:56:33 AM, Alissa Cooper (alissa@= cooperw.in) wrote:

Works for me. Thanks.
Alissa

> On Apr 22, 2020, at 11:52 AM, Susan Hares <shares@ndzh.com> wrote:
> =20
> Alissa and Alvaro: =20
> =20
> Alissa discuss is correct. =20
> =20
> My solution to fix this is to provide the following revisions: =20
> =20
> Section 7.1: =20
> Old/
> Interferes with: No other BGP Flow Specification Traffic Filteri= ng
> Action in this document.
> /
> New/
> Interferes with: May interfere with the traffic-rate-packets (s= ee section 7.2).
> Policy may allow both filtering by traffic-rate-packets and traf= fic-rate-bytes. =20
> If policy does not allow this, these two actions will conflict. = =20
> / =20
> Section 7.2 =20
> Old/
> Interferes with: No other BGP Flow Specification Traffic Filteri= ng
> Action in this document.
> /
> Interferes with: May interfere with the traffic-rate-bytes (see= section 7.1) =20
> Policy may allow both filtering by traffic-rate-packets and traf= fic-rate-bytes. =20
> If policy does not allow this, these two actions will conflict. = =20
> /
> =20
> If this fix is acceptable to both of you, please let me know. We= will re-spin the draft. =20
> =20
> Sue Hares =20
> =20
> =20
> -----Original Message-----
> From: Idr [mailto:idr-boun= ces@ietf.org] On Behalf Of Alissa Cooper
> Sent: Wednesday, April 22, 2020 10:03 AM
> To: Alvaro Retana
> Cc: draft-ie= tf-idr-rfc5575bis@ietf.org; idr-= chairs@ietf.org; idr@ietf.org; IESG
> Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-r= fc5575bis-22: (with DISCUSS)
> =20
> Hi Alvaro,
> =20
>> On Apr 22, 2020, at 9:53 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:
>> =20
>> On April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote:
>> =20
>> =20
>> Alissa:
>> =20
>> Hi!
>> =20
>> =20
>>> ----------------------------------------------------------= -----------
>>> -
>>> DISCUSS:
>>> ----------------------------------------------------------= -----------
>>> -
>>> =20
>>> Apologies as this may be a really silly question, but isn&= #39;t it =20
>>> possible for traffic-rate-bytes and traffic-rate-packets t= o interfere with each other?
>>> That is, if by mistake a flow specification shows up conta= ining both =20
>>> actions and they contradict each other (e.g., 0 bytes but = 1M =20
>>> packets), how is that situation supposed to be handled?
>> =20
>> See =C2=A77.7. It is left to the implementation to decide whi= ch filtering =20
>> action to use.
> =20
> Right, but 7.1 and 7.2 say that traffic-rate-bytes and traffic-rat= e-packets don=E2=80=99t interfere with each other (or any other filtering a= ctions specified), so presumably 7.7 does not apply? =20
> =20
> Alissa
> =20
>> =20
>> =20
>> Alvaro.
> =20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.= ietf.org/mailman/listinfo/idr
> =20

<= /body> --000000000000fc050305a3e3a9e1-- From nobody Wed Apr 22 11:11:43 2020 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 A4C253A11F6; Wed, 22 Apr 2020 11:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 Tf-DUvWzMdn2; Wed, 22 Apr 2020 11:11:32 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 6564D3A11F5; Wed, 22 Apr 2020 11:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yHkzhd7GcVC8O/xwezbT4eYCZe7Q0rS/8LzqQlP201k=; b=HM3s2AgMnGBBuM6/2g6xklVNZS Y97qZX1uWMzCfE6EAuyJA3mDimfSF83i3QvQZfm3mGvCJo9y24s4XHjgvKIXkR7lqgugKVq92fWL+ pKeo0ZZIEEWoyckOC2oPHECrqF2lC1wgKERVVfxtvJLoFtYq8AnozimnirzllE7Rk4/BpbtvMSuCc R4E+SpNl+f+H6tlPAFgxC6FseHne6/XGrtk0TQRqGJ9/0FxUWVEXv1rfY6RTi1XftL1KrGwJBl3Yp /xBoNtHCuITiT1l/jmgsG8bSCA8eUYzeY8Y2VGW59uJJ3h8Yj9Aed7PUuthJnpVtApb4OR4Xmlmaa dc+h1tcg==; Received: from [89.144.223.235] (helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jRJq8-000A5R-W5; Wed, 22 Apr 2020 20:11:19 +0200 From: Christoph Loibl Message-Id: <2377AA4B-B80F-4011-B350-0D3D10661572@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_E6BE172D-9A48-42C6-8521-C28ED8E5CB29" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Wed, 22 Apr 2020 20:11:10 +0200 In-Reply-To: Cc: Alissa Cooper , Susan Hares , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, IESG , idr@ietf.org To: Alvaro Retana References: <158756317450.27447.7394258570701485593@ietfa.amsl.com> <2316B33C-8C79-4A23-B126-5B4D6EB11FBC@cooperw.in> <006201d618be$03e4afa0$0bae0ee0$@ndzh.com> <3FC2341A-4760-4129-9DE3-536515C2FC6F@cooperw.in> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Wed, 22 Apr 2020 20:11:17 +0200 Archived-At: Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 18:11:41 -0000 --Apple-Mail=_E6BE172D-9A48-42C6-8521-C28ED8E5CB29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone. Thanks for bringing this up. I remember that we had a very similar = discussion about this before. Since both is possible at the same time I = think that the changes suggested below are reasonable. It seems that = this has consensus and I will take care of the update tomorrow. Cheers Christoph. --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 22.04.2020, at 18:31, Alvaro Retana wrote: >=20 > Works for me too. >=20 > Thanks! >=20 > Alvaro. >=20 > On April 22, 2020 at 11:56:33 AM, Alissa Cooper (alissa@cooperw.in = ) wrote: >=20 >> Works for me. Thanks.=20 >> Alissa=20 >>=20 >> > On Apr 22, 2020, at 11:52 AM, Susan Hares > wrote:=20 >> > =20 >> > Alissa and Alvaro: =20 >> > =20 >> > Alissa discuss is correct. =20 >> > =20 >> > My solution to fix this is to provide the following revisions: =20 >> > =20 >> > Section 7.1: =20 >> > Old/=20 >> > Interferes with: No other BGP Flow Specification Traffic Filtering=20= >> > Action in this document.=20 >> > /=20 >> > New/=20 >> > Interferes with: May interfere with the traffic-rate-packets (see = section 7.2).=20 >> > Policy may allow both filtering by traffic-rate-packets and = traffic-rate-bytes. =20 >> > If policy does not allow this, these two actions will conflict. =20 >> > / =20 >> > Section 7.2 =20 >> > Old/=20 >> > Interferes with: No other BGP Flow Specification Traffic Filtering=20= >> > Action in this document.=20 >> > /=20 >> > Interferes with: May interfere with the traffic-rate-bytes (see = section 7.1) =20 >> > Policy may allow both filtering by traffic-rate-packets and = traffic-rate-bytes. =20 >> > If policy does not allow this, these two actions will conflict. =20 >> > /=20 >> > =20 >> > If this fix is acceptable to both of you, please let me know. We = will re-spin the draft. =20 >> > =20 >> > Sue Hares =20 >> > =20 >> > =20 >> > -----Original Message-----=20 >> > From: Idr [mailto:idr-bounces@ietf.org = ] On Behalf Of Alissa Cooper=20 >> > Sent: Wednesday, April 22, 2020 10:03 AM=20 >> > To: Alvaro Retana=20 >> > Cc: draft-ietf-idr-rfc5575bis@ietf.org = ; idr-chairs@ietf.org = ; idr@ietf.org ; IESG=20= >> > Subject: Re: [Idr] Alissa Cooper's Discuss on = draft-ietf-idr-rfc5575bis-22: (with DISCUSS)=20 >> > =20 >> > Hi Alvaro,=20 >> > =20 >> >> On Apr 22, 2020, at 9:53 AM, Alvaro Retana > wrote:=20 >> >> =20 >> >> On April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote:=20 >> >> =20 >> >> =20 >> >> Alissa:=20 >> >> =20 >> >> Hi!=20 >> >> =20 >> >> =20 >> >>> = ---------------------------------------------------------------------=20 >> >>> -=20 >> >>> DISCUSS:=20 >> >>> = ---------------------------------------------------------------------=20 >> >>> -=20 >> >>> =20 >> >>> Apologies as this may be a really silly question, but isn't it =20= >> >>> possible for traffic-rate-bytes and traffic-rate-packets to = interfere with each other?=20 >> >>> That is, if by mistake a flow specification shows up containing = both =20 >> >>> actions and they contradict each other (e.g., 0 bytes but 1M =20 >> >>> packets), how is that situation supposed to be handled?=20 >> >> =20 >> >> See =C2=A77.7. It is left to the implementation to decide which = filtering =20 >> >> action to use.=20 >> > =20 >> > Right, but 7.1 and 7.2 say that traffic-rate-bytes and = traffic-rate-packets don=E2=80=99t interfere with each other (or any = other filtering actions specified), so presumably 7.7 does not apply? =20= >> > =20 >> > Alissa=20 >> > =20 >> >> =20 >> >> =20 >> >> Alvaro.=20 >> > =20 >> > _______________________________________________=20 >> > Idr mailing list=20 >> > Idr@ietf.org =20 >> > https://www.ietf.org/mailman/listinfo/idr = =20 >> > =20 >>=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_E6BE172D-9A48-42C6-8521-C28ED8E5CB29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone.

Thanks for = bringing this up. I remember that we had a very similar discussion about = this before. Since both is possible at the same time I think that the = changes suggested below are reasonable. It seems that this has consensus = and I will take care of the update tomorrow.

Cheers Christoph.

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



On 22.04.2020, at 18:31, Alvaro Retana <aretana.ietf@gmail.com> wrote:

Works for me too.

Thanks!

Alvaro.

On April 22, 2020 at 11:56:33 AM, Alissa Cooper = (alissa@cooperw.in) = wrote:

Works for me. Thanks. 
Alissa 

> On Apr 22, 2020, at 11:52 AM, Susan Hares <shares@ndzh.com> = wrote: 
>  
> Alissa = and Alvaro:  
>  
> Alissa = discuss is correct.  
>  
> My = solution to fix this is to provide the following revisions:  
>  
> Section = 7.1:  
> = Old/ 
>= Interferes with: No other BGP Flow Specification Traffic Filtering 
> Action = in this document. 
> / 
> New/ > Interferes with: May interfere with the = traffic-rate-packets (see section 7.2). 
> Policy = may allow both filtering by traffic-rate-packets and = traffic-rate-bytes.  
> If = policy does not allow this, these two actions will conflict.  
> /  
> Section = 7.2  
> = Old/ 
>= Interferes with: No other BGP Flow Specification Traffic Filtering 
> Action = in this document. 
> / 
> Interferes with: May interfere with the = traffic-rate-bytes (see section 7.1)  
> Policy = may allow both filtering by traffic-rate-packets and = traffic-rate-bytes.  
> If = policy does not allow this, these two actions will conflict.  
> / 
>  
> If this = fix is acceptable to both of you, please let me know. We will re-spin = the draft.  
>  
> Sue = Hares  
>  
>  
> = -----Original Message----- 
> From: = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alissa Cooper 
> Sent: = Wednesday, April 22, 2020 10:03 AM 
> To: = Alvaro Retana 
> Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org; IESG 
> = Subject: Re: [Idr] Alissa Cooper's Discuss on = draft-ietf-idr-rfc5575bis-22: (with DISCUSS) 
>  
> Hi = Alvaro, 
>  
>> On = Apr 22, 2020, at 9:53 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote: 
>>  
>> On = April 22, 2020 at 9:46:15 AM, Alissa Cooper wrote: 
>>  
>>  
>> = Alissa: 
>>  
>> = Hi! 
>>  
>>  
>>> = --------------------------------------------------------------------- 
>>> = - 
>>> DISCUSS: 
>>> = --------------------------------------------------------------------- 
>>> = - 
>>>  
>>> = Apologies as this may be a really silly question, but isn't it  
>>> = possible for traffic-rate-bytes and traffic-rate-packets to interfere = with each other? 
>>> That is, if by mistake a flow specification = shows up containing both  
>>> = actions and they contradict each other (e.g., 0 bytes but 1M  
>>> = packets), how is that situation supposed to be handled? 
>>  
>> See = =C2=A77.7. It is left to the implementation to decide which = filtering  
>> = action to use. 
>  
> Right, = but 7.1 and 7.2 say that traffic-rate-bytes and traffic-rate-packets = don=E2=80=99t interfere with each other (or any other filtering actions = specified), so presumably 7.7 does not apply?  
>  
> = Alissa 
>  
>>  
>>  
>> = Alvaro. 
>  
> = _______________________________________________ 
> 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

= --Apple-Mail=_E6BE172D-9A48-42C6-8521-C28ED8E5CB29-- From nobody Wed Apr 22 12:09:10 2020 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 59E873A0B41; Wed, 22 Apr 2020 12:09:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <158758254889.29189.17403732838269730397@ietfa.amsl.com> Date: Wed, 22 Apr 2020 12:09:09 -0700 Archived-At: Subject: [Idr] Warren Kumari's Yes on draft-ietf-idr-rfc5575bis-22: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 19:09:10 -0000 Warren Kumari has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you, this is a useful document. I have two minor comments: “ Modern IP routers contain both the capability to forward traffic according to IP prefixes ...†For some reason the “according to IP prefixes†scans oddly to me - the rest of the actions are also (largely) “according to ip prefixes†- this is more of a nit / preference, but I think it would be better to just drop that phrase. “ This specification has removed all references to a opaque-key property. BGP is able to understand the NLRI encoding.†2 nits: 1: a opaque-key -> an opaque-key (or the opaque-key) 2: BGP is able to... seems a bit odd - BGP is just a protocol, it doesn’t really understand *anything*. I think that a better option would be best “BGP implementations areâ€. Again this is just a nit, feel free to address it or not... From nobody Wed Apr 22 17:42:40 2020 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 DF9BF3A0F2A; Wed, 22 Apr 2020 17:42:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158760254746.26942.2049621502527864651@ietfa.amsl.com> Date: Wed, 22 Apr 2020 17:42:27 -0700 Archived-At: Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 00:42:28 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There might be a minor internal inconsistency to tidy up (or I might be misunderstanding things). Section 8 states that: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. As far as I can tell, this is referring to the text in Section 6 where (for the non-VPN case) "By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true [...]". But immediately following what I quote above is a statement that "the validation proceure (section 6) [...] [is] the same as for IPv4", which seems to be in conflict with this statement ("contrary to" vs. "the same as"). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract is perhaps pushing the length limits appropriate for an Abstract (vs. Introduction). Abstract Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to This makes me think of the DOTS WG (but it's far from clear that we should reference it in this text). Section 1 This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], the differences can be found in Appendix B. This document nit: comma splice A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted (Section 6). The Flow Specification received from an internal BGP peer within the same autonomous system [RFC4271] is assumed to have been validated prior to transmission within the internal BGP (iBGP) mesh of an autonomous system. If the aggregate traffic flow defined (Just to check, there's no particular harm in also validating iBGP flowspecs, just the extra computation burden of doing so, right?) systems that are able to detect malicious traffic flows. When automated systems are used, care should be taken to ensure their correctness as well as the limitations of the systems that receive and process the advertised Flow Specifications (see also Section 12). This seems to discuss making sure that the recipients of automated information handle it robustly; is it also worth some considerations on robustness of generating such automated information (something akin to a circuit breaker that would shut off the source if it started producing nonsensical output)? Also, nit: I think I parse this as "care should be taken to ensure [...] the limitations of the systems that receive and process [flowspecs]", which doesn't quite seem like what was intended. Section 4 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as one or more 2-tuples of the form . It consists of a 1- or 2-octet length field followed by a variable-length NLRI value. The length is expressed in octets. RFC 4760 only shows the one-octet length form; is there a good reference for the 2-octet length? (Or is it "new" with 5575?) Section 4.2 I think we should say something about how multi-byte values are encoded, especially given that we implicitly allow for different encodings of a given value (e.g., IP protocol could have padding, and small port numbers don't need to be encoded in 2 bytes). Even just making it more explicit that multiple encodings are allowed (and what the semantics are for any such "padding") would be worthwhile. Is there a maximum encoded length for anything other than the constraints of the 2-bit 'len' field? Interestingly, for DCSP we are much more strict -- why is the strictness needed there but not in general? Is this just to faithfully reproduce RFC 5575, as implied by the discussion in Appendix B? (I would make this a DISCUSS point if I didn't think that we're acting as if we're required to preserve the RFC 5575 behavior.) A NLRI value not encoded as specified in Section 4.2 is considered This *is* Section 4.2; perhaps "specified here" or "specified below"? Section 4.2.1.1, 4.2.1.2 While I don't anticipate needing a future extension to numeric_op, having the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper any future extensibility efforts. (Similarly for the "Traffic-action" field in Section 7.3, and "Traffic-marking" from Section 7.5.) Section 4.2.2.3 This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 3 component values SHOULD be encoded as single octet (numeric_op len=00). Is it well-defined how I would encode the value if I ignored the SHOULD? I, for one, am not sure what I would do... Section 4.2.2.4, etc. (I agree with my esteemed colleagues that hardcoding TCP and UDP as "the only protocols with ports" is unnecessary.) system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. If an implementation cannot decode the transport header does it treat all such packets as matching or not matching? Section 4.2.2.7 In case of the presence of the ICMP type (code) component only ICMP packets can match the entire Flow Specification. The ICMP type I'm not sure why the parenthetical is needed given that there's a separate NRLI type for "ICMP code". Section 5.1 component type. If the component types are the same, then a type- specific comparison is performed (see below) if the types are equal the algorithm continues with the next component. nit: there seems to be some missing punctuation or conjunction here. For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. It is surprising to me that the comparison operator can return "not-equal" for different encodings of a quantity that have the same semantic value (viz my previous note about encoding flexibility). That said, this procedure is well-defined and BGP speakers are not going to be re-encoding the NRLI values as they propagate, so I don't see an interop problem. Section 6 By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true: Perhaps "in the absence of explicit configuration otherwise," to more closely parallel the other case? BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it for security reasons. nit: missing word (e.g., "necessary to enforce it here" or "necessary to enforce it in processing flow specifications"). The best-match unicast route may change over the time independently of the Flow Specification NLRI. Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change. Revalidation is defined as retesting that clause a and clause b above are true. IMPORTANT: Why does clause c not need to be retested? The neighboring AS is the immediate destination of the traffic described by the Flow Specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it. (This presumes that there is some integrity protection applied to the received data, which might be worth making more explicit.) Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as if/ Section 7 Please be consistent about "ASN" vs. "AS" in Table 2. Should the "traffic-action" and "traffic-marking" actions list the encoded length for the reader's convenience? Section 7.1 The remaining 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. Thank you for being clear about the units! Section 7.2 Is there anything to say about what time interval a non-integer packet rate should be evaluated over? Section 7.3 o T: Terminal Action (bit 47): When this bit is set, the traffic filtering engine will evaluate any subsequent Flow Specifications (as defined by the ordering procedure Section 5.1). If not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated. Just to check I'm reading this right: when the "terminal action" bit is set to one, it is *not* the terminal action, and the action *is* the terminal action when the "terminal action" bit is set to zero? That sounds backwards to my intuition (and maybe others'?). Section 7.4 Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. Do the different possible 'type's for this 'sub-type' interfere with each other? Section 7.6 Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to Traffic Filtering Actions that require different mappings in different systems in the network. nit(?): to my eye this reads better as "on different systems" (vs. "in"). For instance, providing packets with a worse-than-best-effort, per- hop behavior is a functionality that is likely to be implemented nit: no comma after worst-than-best-effort. Section 7.7 other (e.g. there may be more than one conflicting traffic-rate-bytes Traffic Filtering Action associated with a single Flow Specification). Traffic Filtering Action interference has no impact Maybe we should revise the earlier text about "Interferes with: No other [...]" to be explicit that it *does* self-interfere. behaviour (ie. match - replace - delete communities on administrative boundaries). See also Section 12. nit: could this parenthetical be expanded a little bit more? I feel like it's expected to be common knowledge among the main readership and so the current wording just serves as a trigger for this "well-known" (but not to me) concept, as opposed to standing on its own. Section 8 [side note: I'd love for us to eventually stop using "VPN" for things that don't encrypt the data passing over them. This doesn't seem like the right place to start, though.] Section 9 Should either/both of these mechanisms be on or off by default? Section 12 I'd consider mentioning again that some of the NRLI components won't work properly on fragmented traffic and that unexpected fragmentation can cause DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where fragmentation can occur anywhere on the path.) Is it worth saying anything about how the RT-redirect actions can direct traffic to an entity not expecting it (and, as such, potentially DoS them)? It also struck me as noteworthy that we're letting DSCP values creep out of a single administrative scope -- the filtering of inbound DSCP markings should probably be consistent with the traffic markings advertised to that peer. (There is perhaps also some "information leakage" as to what semantics are assigned to given DSCP values within the network in question, but I find it hard to get too worked up about that, especially since the inter-AS relationship is inherently pretty trusted.) As long as Flow Specifications are restricted to match the corresponding unicast routing paths for the relevant prefixes (Section 6), the security characteristics of this proposal are [There's an implicit "and both are received over trustworthy channels" in here. Perhaps it's okay to remain implicit, given how well-known BGP's security properties are...] Where the above mechanisms are not in place, this could open the door to further denial-of-service attacks such as unwanted traffic filtering, remarking or redirection. nit(?): I might just say "In particular, relaxing the validation procedure could [...]". additional filtering. For example, the use of [RFC6811] to enhance filtering within an AS confederation. nit: incomplete sentence. Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not I guess it's also a well-known attack that malicious neighbor could also draw traffic to itself for snooping purposes without actually dropping the traffic. But I'm not sure if there are any flowspec-specific considerations relating to that scenario. provide service (unfiltered address space hijack). Since validation of the Flow Specification is tied to the announcement of the best unicast route, this may also cause this validation to fail and consequently prevent Flow Specifications from being accepted by a peer. Possible mitigations are [RFC6811] and [RFC8205]. nit: there's a lot of pronouns ("this") in here; it might be worth disambiguating a couple. Flow Specification BGP speakers (e.g. automated DDoS controllers) not properly programmed, algorithms that are not performing as expected, or simply rogue systems may announce unintended Flow Specifications, send updates at a high rate or generate a high number of Flow Specifications. This may stress the receiving systems, exceed their maximum capacity or may lead to unwanted Traffic Filtering Actions being applied to flows. Is there any relevant guidance to give to receiving systems? Appendix A I don't know that just this one function is useful without some description of what format of input it requires. For example, if a.components and/or b.components have elements that evaluate to "false", the first two checks could return incorrect results (the perhaps-more-obvious case where both comp_a and comp_b are None cannot happen due to the nature of zip_longest). Appendix B Section 7 defines all Traffic Filtering Action Extended communities as transitive extended communities. [RFC5575] defined the traffic-rate action to be non-transitive and did not define the transitivity of the other Traffic Filtering Action communities at all. I assume the consequences of changing a community from non-transitive to transitive are well-known (but not to me) and that any operational considerations for mixed deployments are already stated somewhere prominent to someone working with BGP. (Where is that?) Section 7.7 contains general considerations on interfering traffic actions. Section 7.3 also cross-references this section. nit(?): the last "this section" refers to 7.7, not the location of the text I'm quoting from (Appendix B). I misread it the first time. From nobody Thu Apr 23 01:53:38 2020 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 468C03A1733; Thu, 23 Apr 2020 01:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 KRHwq7RIX0sD; Thu, 23 Apr 2020 01:53:23 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 7C5A43A1731; Thu, 23 Apr 2020 01:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=ABw2C1jixwNUfFX4fFiWoioqWUBJeRAIrM/aPgVT5Js=; b=uk/AUOjuwgMYHvB9ScJY3qIofA 36PZuARVL8simcSlr3lmDKwhujl5J5IfSsDJ4gFt5pb6F9BaTxJSjBPcOuTK6hgcSZJtVadjpuz8s fMrnuyG4h23t36JRZcA7YRSwldX4vC+Ntp9Cb6py/eddxEp3Ctx5NUgoCIstMq/NQmDSjwFKY9Pim BNhoMD1o0CaHmEOI2vTxpRfQ0TCiAZBXsiyGztXlc8S4M9CgXvBWmc2nlPxajHjMiA0zGYjeJy22X bmfQj5cUW6GWNjltcgs0jChueDhUlSMsupDdQ0u3Tk7Sa25qd6/cYvc6ZQbwDBBx7u/t5E0Gx+rsB 2dyyQLXQ==; Received: from [89.144.223.235] (helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jRXbi-000AA7-FH; Thu, 23 Apr 2020 10:53:18 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Christoph Loibl In-Reply-To: <158760254746.26942.2049621502527864651@ietfa.amsl.com> Date: Thu, 23 Apr 2020 10:53:12 +0200 Cc: The IESG , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <95C65325-EE11-42A1-8BAE-967BA2A0E448@tix.at> References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Thu, 23 Apr 2020 10:53:18 +0200 Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 08:53:28 -0000 Hi Benjamin, Thanks for your review. I opened cases for all of the issues you raised = in the github repo: https://github.com/stoffi92/rfc5575bis The discuss item you raised is this: https://github.com/stoffi92/rfc5575bis/issues/184 To resolve this I suggest the following change to the document: I suggest to change it to the following (I hope that Robert and Sue can = also have a look if this is still correct to the desired behaviour): OLD: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. The validation procedure (Section 6) and Traffic Filtering Actions (Section 7) are the same as for IPv4. NEW: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. The validation procedure (Section 6) when Flow = Specifications are received from a remote CE are the same as for IPv4.=20 Traffic Filtering Actions (Section 7) are the same as for IPv4. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 23.04.2020, at 02:42, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-idr-rfc5575bis-22: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > There might be a minor internal inconsistency to tidy up (or I might = be > misunderstanding things). Section 8 states that: >=20 > Contrary to the behavior specified for the non-VPN NLRI, Flow > Specifications are accepted by default, when received from remote PE > routers. >=20 > As far as I can tell, this is referring to the text in Section 6 where = (for > the non-VPN case) "By default a Flow Specification NLRI MUST be = validated > such that it is considered feasible if and only if all of the below is = true > [...]". But immediately following what I quote above is a statement = that > "the validation proceure (section 6) [...] [is] the same as for IPv4", = which > seems to be in conflict with this statement ("contrary to" vs. "the = same > as"). >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The Abstract is perhaps pushing the length limits appropriate for an > Abstract (vs. Introduction). >=20 > Abstract >=20 > Additionally, it defines two applications of that encoding format: > one that can be used to automate inter-domain coordination of = traffic > filtering, such as what is required in order to mitigate > (distributed) denial-of-service attacks, and a second application to >=20 > This makes me think of the DOTS WG (but it's far from clear that we = should > reference it in this text). >=20 > Section 1 >=20 > This document obsoletes "Dissemination of Flow Specification Rules" > [RFC5575], the differences can be found in Appendix B. This = document >=20 > nit: comma splice >=20 > A Flow Specification received from an external autonomous system = will > need to be validated against unicast routing before being accepted > (Section 6). The Flow Specification received from an internal BGP > peer within the same autonomous system [RFC4271] is assumed to have > been validated prior to transmission within the internal BGP (iBGP) > mesh of an autonomous system. If the aggregate traffic flow defined >=20 > (Just to check, there's no particular harm in also validating iBGP > flowspecs, just the extra computation burden of doing so, right?) >=20 > systems that are able to detect malicious traffic flows. When > automated systems are used, care should be taken to ensure their > correctness as well as the limitations of the systems that receive > and process the advertised Flow Specifications (see also Section = 12). >=20 > This seems to discuss making sure that the recipients of automated > information handle it robustly; is it also worth some considerations = on > robustness of generating such automated information (something akin to = a > circuit breaker that would shut off the source if it started producing > nonsensical output)? > Also, nit: I think I parse this as "care should be taken to ensure = [...] the > limitations of the systems that receive and process [flowspecs]", = which > doesn't quite seem like what was intended. >=20 > Section 4 >=20 > The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded = as > one or more 2-tuples of the form . It consists > of a 1- or 2-octet length field followed by a variable-length NLRI > value. The length is expressed in octets. >=20 > RFC 4760 only shows the one-octet length form; is there a good = reference for > the 2-octet length? (Or is it "new" with 5575?) >=20 > Section 4.2 >=20 > I think we should say something about how multi-byte values are = encoded, > especially given that we implicitly allow for different encodings of a = given > value (e.g., IP protocol could have padding, and small port numbers = don't > need to be encoded in 2 bytes). Even just making it more explicit = that > multiple encodings are allowed (and what the semantics are for any = such > "padding") would be worthwhile. Is there a maximum encoded length for > anything other than the constraints of the 2-bit 'len' field? > Interestingly, for DCSP we are much more strict -- why is the = strictness > needed there but not in general? Is this just to faithfully reproduce = RFC > 5575, as implied by the discussion in Appendix B? > (I would make this a DISCUSS point if I didn't think that we're acting = as if > we're required to preserve the RFC 5575 behavior.) >=20 > A NLRI value not encoded as specified in Section 4.2 is considered >=20 > This *is* Section 4.2; perhaps "specified here" or "specified below"? >=20 > Section 4.2.1.1, 4.2.1.2 >=20 > While I don't anticipate needing a future extension to numeric_op, = having > the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to = hamper any > future extensibility efforts. > (Similarly for the "Traffic-action" field in Section 7.3, and > "Traffic-marking" from Section 7.5.) >=20 > Section 4.2.2.3 >=20 > This component uses the Numeric Operator (numeric_op) described in > Section 4.2.1.1. Type 3 component values SHOULD be encoded as = single > octet (numeric_op len=3D00). >=20 > Is it well-defined how I would encode the value if I ignored the = SHOULD? > I, for one, am not sure what I would do... >=20 > Section 4.2.2.4, etc. >=20 > (I agree with my esteemed colleagues that hardcoding TCP and UDP as > "the only protocols with ports" is unnecessary.) >=20 > system is unable to locate the transport header. Different > implementations may or may not be able to decode the transport = header > in the presence of IP options or Encapsulating Security Payload = (ESP) > NULL [RFC4303] encryption. >=20 > If an implementation cannot decode the transport header does it treat = all > such packets as matching or not matching? >=20 > Section 4.2.2.7 >=20 > In case of the presence of the ICMP type (code) component only ICMP > packets can match the entire Flow Specification. The ICMP type >=20 > I'm not sure why the parenthetical is needed given that there's a = separate > NRLI type for "ICMP code". >=20 > Section 5.1 >=20 > component type. If the component types are the same, then a type- > specific comparison is performed (see below) if the types are equal > the algorithm continues with the next component. >=20 > nit: there seems to be some missing punctuation or conjunction here. >=20 > For all other component types, unless otherwise specified, the > comparison is performed by comparing the component data as a binary > string using the memcmp() function as defined by [ISO_IEC_9899]. = For > strings with equal lengths the lowest string (memcmp) has higher > precedence. For strings of different lengths, the common prefix is > compared. If the common prefix is not equal the string with the > lowest prefix has higher precedence. If the common prefix is equal, > the longest string is considered to have higher precedence than the > shorter one. >=20 > It is surprising to me that the comparison operator can return = "not-equal" > for different encodings of a quantity that have the same semantic = value > (viz my previous note about encoding flexibility). That said, this > procedure is well-defined and BGP speakers are not going to be = re-encoding > the NRLI values as they propagate, so I don't see an interop problem. >=20 > Section 6 >=20 > By default a Flow Specification NLRI MUST be validated such that it > is considered feasible if and only if all of the below is true: >=20 > Perhaps "in the absence of explicit configuration otherwise," to more > closely parallel the other case? >=20 > BGP implementations MUST also enforce that the AS_PATH attribute of = a > route received via the External Border Gateway Protocol (eBGP) > contains the neighboring AS in the left-most position of the AS_PATH > attribute. While this rule is optional in the BGP specification, it > becomes necessary to enforce it for security reasons. >=20 > nit: missing word (e.g., "necessary to enforce it here" or "necessary = to > enforce it in processing flow specifications"). >=20 > The best-match unicast route may change over the time independently > of the Flow Specification NLRI. Therefore, a revalidation of the > Flow Specification NLRI MUST be performed whenever unicast routes > change. Revalidation is defined as retesting that clause a and > clause b above are true. >=20 > IMPORTANT: Why does clause c not need to be retested? >=20 > The neighboring AS is the immediate destination of the traffic > described by the Flow Specification. If it requests these flows to > be dropped, that request can be honored without concern that it > represents a denial of service in itself. Supposedly, the traffic = is > being dropped by the downstream autonomous system, and there is no > added value in carrying the traffic to it. >=20 > (This presumes that there is some integrity protection applied to the > received data, which might be worth making more explicit.) > Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as = if/ >=20 > Section 7 >=20 > Please be consistent about "ASN" vs. "AS" in Table 2. >=20 > Should the "traffic-action" and "traffic-marking" actions list the = encoded > length for the reader's convenience? >=20 > Section 7.1 >=20 > The remaining 4 octets carry the maximum rate information in IEEE > floating point [IEEE.754.1985] format, units being bytes per second. >=20 > Thank you for being clear about the units! >=20 > Section 7.2 >=20 > Is there anything to say about what time interval a non-integer packet = rate > should be evaluated over? >=20 > Section 7.3 >=20 > o T: Terminal Action (bit 47): When this bit is set, the traffic > filtering engine will evaluate any subsequent Flow Specifications > (as defined by the ordering procedure Section 5.1). If not set, > the evaluation of the traffic filters stops when this Flow > Specification is evaluated. >=20 > Just to check I'm reading this right: when the "terminal action" bit = is set > to one, it is *not* the terminal action, and the action *is* the = terminal > action when the "terminal action" bit is set to zero? That sounds > backwards to my intuition (and maybe others'?). >=20 > Section 7.4 >=20 > Interferes with: No other BGP Flow Specification Traffic Filtering > Action in this document. >=20 > Do the different possible 'type's for this 'sub-type' interfere with = each > other? >=20 > Section 7.6 >=20 > Implementations should provide mechanisms that map an arbitrary BGP > community value (normal or extended) to Traffic Filtering Actions > that require different mappings in different systems in the network. >=20 > nit(?): to my eye this reads better as "on different systems" (vs. = "in"). >=20 > For instance, providing packets with a worse-than-best-effort, per- > hop behavior is a functionality that is likely to be implemented >=20 > nit: no comma after worst-than-best-effort. >=20 > Section 7.7 >=20 > other (e.g. there may be more than one conflicting = traffic-rate-bytes > Traffic Filtering Action associated with a single Flow > Specification). Traffic Filtering Action interference has no impact >=20 > Maybe we should revise the earlier text about "Interferes with: No = other > [...]" to be explicit that it *does* self-interfere. >=20 > behaviour (ie. match - replace - delete communities on = administrative > boundaries). See also Section 12. >=20 > nit: could this parenthetical be expanded a little bit more? I feel = like > it's expected to be common knowledge among the main readership and so = the > current wording just serves as a trigger for this "well-known" (but = not to > me) concept, as opposed to standing on its own. >=20 > Section 8 >=20 > [side note: I'd love for us to eventually stop using "VPN" for things = that > don't encrypt the data passing over them. This doesn't seem like the = right > place to start, though.] >=20 > Section 9 >=20 > Should either/both of these mechanisms be on or off by default? >=20 > Section 12 >=20 > I'd consider mentioning again that some of the NRLI components won't = work > properly on fragmented traffic and that unexpected fragmentation can = cause > DoS. (This is particularly relevant for IPv4, as opposed to IPv6, = where > fragmentation can occur anywhere on the path.) >=20 > Is it worth saying anything about how the RT-redirect actions can = direct > traffic to an entity not expecting it (and, as such, potentially DoS = them)? >=20 > It also struck me as noteworthy that we're letting DSCP values creep = out of > a single administrative scope -- the filtering of inbound DSCP = markings > should probably be consistent with the traffic markings advertised to = that > peer. (There is perhaps also some "information leakage" as to what > semantics are assigned to given DSCP values within the network in = question, > but I find it hard to get too worked up about that, especially since = the > inter-AS relationship is inherently pretty trusted.) >=20 > As long as Flow Specifications are restricted to match the > corresponding unicast routing paths for the relevant prefixes > (Section 6), the security characteristics of this proposal are >=20 > [There's an implicit "and both are received over trustworthy channels" = in > here. Perhaps it's okay to remain implicit, given how well-known = BGP's > security properties are...] >=20 > Where the above mechanisms are not in place, this could open the = door > to further denial-of-service attacks such as unwanted traffic > filtering, remarking or redirection. >=20 > nit(?): I might just say "In particular, relaxing the validation = procedure > could [...]". >=20 > additional filtering. For example, the use of [RFC6811] to enhance > filtering within an AS confederation. >=20 > nit: incomplete sentence. >=20 > Inter-provider routing is based on a web of trust. Neighboring > autonomous systems are trusted to advertise valid reachability > information. If this trust model is violated, a neighboring > autonomous system may cause a denial-of-service attack by = advertising > reachability information for a given prefix for which it does not >=20 > I guess it's also a well-known attack that malicious neighbor could = also > draw traffic to itself for snooping purposes without actually dropping = the > traffic. But I'm not sure if there are any flowspec-specific = considerations > relating to that scenario. >=20 > provide service (unfiltered address space hijack). Since validation > of the Flow Specification is tied to the announcement of the best > unicast route, this may also cause this validation to fail and > consequently prevent Flow Specifications from being accepted by a > peer. Possible mitigations are [RFC6811] and [RFC8205]. >=20 > nit: there's a lot of pronouns ("this") in here; it might be worth > disambiguating a couple. >=20 > Flow Specification BGP speakers (e.g. automated DDoS controllers) = not > properly programmed, algorithms that are not performing as expected, > or simply rogue systems may announce unintended Flow Specifications, > send updates at a high rate or generate a high number of Flow > Specifications. This may stress the receiving systems, exceed their > maximum capacity or may lead to unwanted Traffic Filtering Actions > being applied to flows. >=20 > Is there any relevant guidance to give to receiving systems? >=20 > Appendix A >=20 > I don't know that just this one function is useful without some = description > of what format of input it requires. For example, if a.components = and/or > b.components have elements that evaluate to "false", the first two = checks > could return incorrect results (the perhaps-more-obvious case where = both > comp_a and comp_b are None cannot happen due to the nature of = zip_longest). >=20 > Appendix B >=20 > Section 7 defines all Traffic Filtering Action Extended > communities as transitive extended communities. [RFC5575] = defined > the traffic-rate action to be non-transitive and did not define > the transitivity of the other Traffic Filtering Action = communities > at all. >=20 > I assume the consequences of changing a community from non-transitive = to > transitive are well-known (but not to me) and that any operational > considerations for mixed deployments are already stated somewhere = prominent > to someone working with BGP. (Where is that?) >=20 > Section 7.7 contains general considerations on interfering = traffic > actions. Section 7.3 also cross-references this section. >=20 > nit(?): the last "this section" refers to 7.7, not the location of the = text > I'm quoting from (Appendix B). I misread it the first time. >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Apr 23 06:05:14 2020 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 5D1DD3A003C; Thu, 23 Apr 2020 06:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 ocJ1w7P_PMAf; Thu, 23 Apr 2020 06:04:50 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 6E31B3A0029; Thu, 23 Apr 2020 06:04:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , , , "'Jie Dong'" , References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> In-Reply-To: <158760254746.26942.2049621502527864651@ietfa.amsl.com> Date: Thu, 23 Apr 2020 09:04:21 -0400 Message-ID: <00e501d6196f$b53fa640$1fbef2c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHio2zJAolkNix40BeFqEjeljO6MahtlVjQ Content-Language: en-us X-Antivirus: AVG (VPS 200422-2, 04/22/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 13:04:53 -0000 Ben: Christoph has addresses your specific request -- but let's check the = higher level security issue to make sure you agree it is closed.=20 This text per the context of section (per Christoph's latest draft)=20 1) The NLRI that is being controlled is the NLRI with the Flow = specification,=20 2) Route target filters check that it is goes to the right VPN 3) validation of section 6 and 7 have occurred The next choice would be for the PE to check whether the NLRI are = accepted.=20 Since these are filters to shut down traffic, the default cause is not = ignore but accept. The concept is if there no filters the safest thing to do is to accept = the filters.=20 This concept dates back to the original RFC5575.=20 " Contrary to the behavior specified for the non-VPN NLRI, flow rules are accepted by default, when received from remote PE routers."=20 Please check that you agree.=20 Sue=20 -----Original Message----- From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org]=20 Sent: Wednesday, April 22, 2020 8:42 PM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org; Jie Dong; aretana.ietf@gmail.com; jie.dong@huawei.com Subject: Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with = DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There might be a minor internal inconsistency to tidy up (or I might be = misunderstanding things). Section 8 states that: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. As far as I can tell, this is referring to the text in Section 6 where = (for the non-VPN case) "By default a Flow Specification NLRI MUST be = validated such that it is considered feasible if and only if all of the = below is true [...]". But immediately following what I quote above is a = statement that "the validation proceure (section 6) [...] [is] the same = as for IPv4", which seems to be in conflict with this statement = ("contrary to" vs. "the same as"). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract is perhaps pushing the length limits appropriate for an = Abstract (vs. Introduction). Abstract Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to This makes me think of the DOTS WG (but it's far from clear that we = should reference it in this text). Section 1 This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], the differences can be found in Appendix B. This document nit: comma splice A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted (Section 6). The Flow Specification received from an internal BGP peer within the same autonomous system [RFC4271] is assumed to have been validated prior to transmission within the internal BGP (iBGP) mesh of an autonomous system. If the aggregate traffic flow defined (Just to check, there's no particular harm in also validating iBGP = flowspecs, just the extra computation burden of doing so, right?) systems that are able to detect malicious traffic flows. When automated systems are used, care should be taken to ensure their correctness as well as the limitations of the systems that receive and process the advertised Flow Specifications (see also Section 12). This seems to discuss making sure that the recipients of automated = information handle it robustly; is it also worth some considerations on = robustness of generating such automated information (something akin to a = circuit breaker that would shut off the source if it started producing = nonsensical output)? Also, nit: I think I parse this as "care should be taken to ensure [...] = the limitations of the systems that receive and process [flowspecs]", = which doesn't quite seem like what was intended. Section 4 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as one or more 2-tuples of the form . It consists of a 1- or 2-octet length field followed by a variable-length NLRI value. The length is expressed in octets. RFC 4760 only shows the one-octet length form; is there a good reference = for the 2-octet length? (Or is it "new" with 5575?) Section 4.2 I think we should say something about how multi-byte values are encoded, = especially given that we implicitly allow for different encodings of a = given value (e.g., IP protocol could have padding, and small port = numbers don't need to be encoded in 2 bytes). Even just making it more = explicit that multiple encodings are allowed (and what the semantics are = for any such "padding") would be worthwhile. Is there a maximum encoded length for = anything other than the constraints of the 2-bit 'len' field? Interestingly, for DCSP we are much more strict -- why is the strictness = needed there but not in general? Is this just to faithfully reproduce = RFC 5575, as implied by the discussion in Appendix B? (I would make this a DISCUSS point if I didn't think that we're acting = as if we're required to preserve the RFC 5575 behavior.) A NLRI value not encoded as specified in Section 4.2 is considered This *is* Section 4.2; perhaps "specified here" or "specified below"? Section 4.2.1.1, 4.2.1.2 While I don't anticipate needing a future extension to numeric_op, = having the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to = hamper any future extensibility efforts. (Similarly for the "Traffic-action" field in Section 7.3, and = "Traffic-marking" from Section 7.5.) Section 4.2.2.3 This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 3 component values SHOULD be encoded as single octet (numeric_op len=3D00). Is it well-defined how I would encode the value if I ignored the SHOULD? I, for one, am not sure what I would do... Section 4.2.2.4, etc. (I agree with my esteemed colleagues that hardcoding TCP and UDP as "the = only protocols with ports" is unnecessary.) system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. If an implementation cannot decode the transport header does it treat = all such packets as matching or not matching? Section 4.2.2.7 In case of the presence of the ICMP type (code) component only ICMP packets can match the entire Flow Specification. The ICMP type I'm not sure why the parenthetical is needed given that there's a = separate NRLI type for "ICMP code". Section 5.1 component type. If the component types are the same, then a type- specific comparison is performed (see below) if the types are equal the algorithm continues with the next component. nit: there seems to be some missing punctuation or conjunction here. For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. It is surprising to me that the comparison operator can return = "not-equal" for different encodings of a quantity that have the same semantic value = (viz my previous note about encoding flexibility). That said, this = procedure is well-defined and BGP speakers are not going to be = re-encoding the NRLI values as they propagate, so I don't see an interop = problem. Section 6 By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true: Perhaps "in the absence of explicit configuration otherwise," to more = closely parallel the other case? BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it for security reasons. nit: missing word (e.g., "necessary to enforce it here" or "necessary to = enforce it in processing flow specifications"). The best-match unicast route may change over the time independently of the Flow Specification NLRI. Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change. Revalidation is defined as retesting that clause a and clause b above are true. IMPORTANT: Why does clause c not need to be retested? The neighboring AS is the immediate destination of the traffic described by the Flow Specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it. (This presumes that there is some integrity protection applied to the = received data, which might be worth making more explicit.) Also, nit: = I'd suggest s/Supposedly,/The reasoning is that this is as if/ Section 7 Please be consistent about "ASN" vs. "AS" in Table 2. Should the "traffic-action" and "traffic-marking" actions list the = encoded length for the reader's convenience? Section 7.1 The remaining 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. Thank you for being clear about the units! Section 7.2 Is there anything to say about what time interval a non-integer packet = rate should be evaluated over? Section 7.3 o T: Terminal Action (bit 47): When this bit is set, the traffic filtering engine will evaluate any subsequent Flow Specifications (as defined by the ordering procedure Section 5.1). If not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated. Just to check I'm reading this right: when the "terminal action" bit is = set to one, it is *not* the terminal action, and the action *is* the = terminal action when the "terminal action" bit is set to zero? That = sounds backwards to my intuition (and maybe others'?). Section 7.4 Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. Do the different possible 'type's for this 'sub-type' interfere with = each other? Section 7.6 Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to Traffic Filtering Actions that require different mappings in different systems in the network. nit(?): to my eye this reads better as "on different systems" (vs. = "in"). For instance, providing packets with a worse-than-best-effort, per- hop behavior is a functionality that is likely to be implemented nit: no comma after worst-than-best-effort. Section 7.7 other (e.g. there may be more than one conflicting traffic-rate-bytes Traffic Filtering Action associated with a single Flow Specification). Traffic Filtering Action interference has no impact Maybe we should revise the earlier text about "Interferes with: No other = [...]" to be explicit that it *does* self-interfere. behaviour (ie. match - replace - delete communities on administrative boundaries). See also Section 12. nit: could this parenthetical be expanded a little bit more? I feel = like it's expected to be common knowledge among the main readership and = so the current wording just serves as a trigger for this "well-known" = (but not to me) concept, as opposed to standing on its own. Section 8 [side note: I'd love for us to eventually stop using "VPN" for things = that don't encrypt the data passing over them. This doesn't seem like = the right place to start, though.] Section 9 Should either/both of these mechanisms be on or off by default? Section 12 I'd consider mentioning again that some of the NRLI components won't = work properly on fragmented traffic and that unexpected fragmentation = can cause DoS. (This is particularly relevant for IPv4, as opposed to = IPv6, where fragmentation can occur anywhere on the path.) Is it worth saying anything about how the RT-redirect actions can direct = traffic to an entity not expecting it (and, as such, potentially DoS = them)? It also struck me as noteworthy that we're letting DSCP values creep out = of a single administrative scope -- the filtering of inbound DSCP = markings should probably be consistent with the traffic markings = advertised to that peer. (There is perhaps also some "information = leakage" as to what semantics are assigned to given DSCP values within = the network in question, but I find it hard to get too worked up about = that, especially since the inter-AS relationship is inherently pretty = trusted.) As long as Flow Specifications are restricted to match the corresponding unicast routing paths for the relevant prefixes (Section 6), the security characteristics of this proposal are [There's an implicit "and both are received over trustworthy channels" = in here. Perhaps it's okay to remain implicit, given how well-known = BGP's security properties are...] Where the above mechanisms are not in place, this could open the door to further denial-of-service attacks such as unwanted traffic filtering, remarking or redirection. nit(?): I might just say "In particular, relaxing the validation = procedure could [...]". additional filtering. For example, the use of [RFC6811] to enhance filtering within an AS confederation. nit: incomplete sentence. Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not I guess it's also a well-known attack that malicious neighbor could also = draw traffic to itself for snooping purposes without actually dropping = the traffic. But I'm not sure if there are any flowspec-specific = considerations relating to that scenario. provide service (unfiltered address space hijack). Since validation of the Flow Specification is tied to the announcement of the best unicast route, this may also cause this validation to fail and consequently prevent Flow Specifications from being accepted by a peer. Possible mitigations are [RFC6811] and [RFC8205]. nit: there's a lot of pronouns ("this") in here; it might be worth = disambiguating a couple. Flow Specification BGP speakers (e.g. automated DDoS controllers) not properly programmed, algorithms that are not performing as expected, or simply rogue systems may announce unintended Flow Specifications, send updates at a high rate or generate a high number of Flow Specifications. This may stress the receiving systems, exceed their maximum capacity or may lead to unwanted Traffic Filtering Actions being applied to flows. Is there any relevant guidance to give to receiving systems? Appendix A I don't know that just this one function is useful without some = description of what format of input it requires. For example, if = a.components and/or b.components have elements that evaluate to "false", = the first two checks could return incorrect results (the = perhaps-more-obvious case where both comp_a and comp_b are None cannot = happen due to the nature of zip_longest). Appendix B Section 7 defines all Traffic Filtering Action Extended communities as transitive extended communities. [RFC5575] defined the traffic-rate action to be non-transitive and did not define the transitivity of the other Traffic Filtering Action communities at all. I assume the consequences of changing a community from non-transitive to = transitive are well-known (but not to me) and that any operational = considerations for mixed deployments are already stated somewhere = prominent to someone working with BGP. (Where is that?) Section 7.7 contains general considerations on interfering traffic actions. Section 7.3 also cross-references this section. nit(?): the last "this section" refers to 7.7, not the location of the = text I'm quoting from (Appendix B). I misread it the first time. From nobody Thu Apr 23 07:50:23 2020 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 85F5E3A09C8 for ; Thu, 23 Apr 2020 07:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id livSFwm83e6E for ; Thu, 23 Apr 2020 07:49:56 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514153A0999 for ; Thu, 23 Apr 2020 07:49:56 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id s3so4892899eji.6 for ; Thu, 23 Apr 2020 07:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1O86HjFDDqZ0Def5fobOUXo7HXP6y+GSW+ciQfH20qk=; b=VJSHp0wWcKrRlj7YNo6nTQ1zXhq9kGKVmJaOFVKQ0ysueNkArNfmVVjMGjmI4tpiWk 66gqmlg8KAGdoHP1vDvoNI+XLpjjoMgDGPCmXe8ahQ/iVPnbcJr4PSYqKXXyWDSqfIDz svfTW690YvMXwbuzAfrqRFucvZKvRlvE4qPMR4o6XOZn6VBAfeyA2JDTVqE6Kg2iq7Zk EgDbgOYQiLKhSljkr2hg0jPH7EwLSV5SAJdyRfuDi5MV/muVIjayzLesszAKlokiU4Q2 XOlntFD5TzjAuooPmJlOz2dqDR5Q+3AK3t3bZGU2/a0HJ8RdTUeqzaHG6ssLYz6UfVHo jfGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1O86HjFDDqZ0Def5fobOUXo7HXP6y+GSW+ciQfH20qk=; b=SV5DUO6p0RhfNTnbQeTNa8revX1y5EqJ0ap6PKWW8n5IIawvHnF5cJIDl35aWcWqWH NgY+xRxJy7f19um5cbiTamlt3PGBX9aFKL7xM1uEvTx1vFEKJaszsAzdVtzLQnrUUNsZ 8LdrgBL2EDnJn6xer2IU+Q+I43C2QElYwkThjo5Nv+OdkRSCNBMKWT75mRBTEKFk7Qsb X1TGf7J5+p1tzxgb/WvsMrd/YCiDN3WMDYLh7YVYGNRiw159nLceNl7VsJjs1lyCbFGQ qDDzksxPP00MyH0CYrt412ZnuhJg9eafa3EyWxnY9R0noZ92BMxMKb2rNP/A+VZP3K2p VyJw== X-Gm-Message-State: AGi0PuZvRRjt3l9qU2m4WK/rmXJtZs5jmuIJe16/9bdj1GeE2cBPueIV +0fOCMH1TK/VLgw7ipwGklRYw6ZOtiohjDVUjGXK/A== X-Google-Smtp-Source: APiQypLR+zeUoohYHDL4WxcGXBhCvH0tgSQb/yuuLrUIgNnxirZr/Ero5mgGgmNlFx2FmIAkQpWWMAmCgP78hfJxQeA= X-Received: by 2002:a17:906:328c:: with SMTP id 12mr2740468ejw.69.1587653394413; Thu, 23 Apr 2020 07:49:54 -0700 (PDT) MIME-Version: 1.0 References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> In-Reply-To: <158760254746.26942.2049621502527864651@ietfa.amsl.com> From: Robert Raszuk Date: Thu, 23 Apr 2020 16:49:43 +0200 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, "idr@ietf. org" , Jie Dong , Alvaro Retana Content-Type: multipart/alternative; boundary="00000000000099d4fb05a3f65c91" Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 14:50:07 -0000 --00000000000099d4fb05a3f65c91 Content-Type: text/plain; charset="UTF-8" Hi Benjamin Acceptance and validation are completely different things. By acceptance we say that router control plane accepted the update message (as opposed to dropping it due to non intersecting RTs in VPNs). Validation however is executed on accepted routes to check if such routes - or to be more precise paths - are eligible to be used for best path selection and therefor for local installation into data plane. Hope that clarifies the discuss :) Many thx, r. On Thu, Apr 23, 2020 at 2:42 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-idr-rfc5575bis-22: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > There might be a minor internal inconsistency to tidy up (or I might be > misunderstanding things). Section 8 states that: > > Contrary to the behavior specified for the non-VPN NLRI, Flow > Specifications are accepted by default, when received from remote PE > routers. > > As far as I can tell, this is referring to the text in Section 6 where (for > the non-VPN case) "By default a Flow Specification NLRI MUST be validated > such that it is considered feasible if and only if all of the below is true > [...]". But immediately following what I quote above is a statement that > "the validation proceure (section 6) [...] [is] the same as for IPv4", > which > seems to be in conflict with this statement ("contrary to" vs. "the same > as"). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The Abstract is perhaps pushing the length limits appropriate for an > Abstract (vs. Introduction). > > Abstract > > Additionally, it defines two applications of that encoding format: > one that can be used to automate inter-domain coordination of traffic > filtering, such as what is required in order to mitigate > (distributed) denial-of-service attacks, and a second application to > > This makes me think of the DOTS WG (but it's far from clear that we should > reference it in this text). > > Section 1 > > This document obsoletes "Dissemination of Flow Specification Rules" > [RFC5575], the differences can be found in Appendix B. This document > > nit: comma splice > > A Flow Specification received from an external autonomous system will > need to be validated against unicast routing before being accepted > (Section 6). The Flow Specification received from an internal BGP > peer within the same autonomous system [RFC4271] is assumed to have > been validated prior to transmission within the internal BGP (iBGP) > mesh of an autonomous system. If the aggregate traffic flow defined > > (Just to check, there's no particular harm in also validating iBGP > flowspecs, just the extra computation burden of doing so, right?) > > systems that are able to detect malicious traffic flows. When > automated systems are used, care should be taken to ensure their > correctness as well as the limitations of the systems that receive > and process the advertised Flow Specifications (see also Section 12). > > This seems to discuss making sure that the recipients of automated > information handle it robustly; is it also worth some considerations on > robustness of generating such automated information (something akin to a > circuit breaker that would shut off the source if it started producing > nonsensical output)? > Also, nit: I think I parse this as "care should be taken to ensure [...] > the > limitations of the systems that receive and process [flowspecs]", which > doesn't quite seem like what was intended. > > Section 4 > > The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as > one or more 2-tuples of the form . It consists > of a 1- or 2-octet length field followed by a variable-length NLRI > value. The length is expressed in octets. > > RFC 4760 only shows the one-octet length form; is there a good reference > for > the 2-octet length? (Or is it "new" with 5575?) > > Section 4.2 > > I think we should say something about how multi-byte values are encoded, > especially given that we implicitly allow for different encodings of a > given > value (e.g., IP protocol could have padding, and small port numbers don't > need to be encoded in 2 bytes). Even just making it more explicit that > multiple encodings are allowed (and what the semantics are for any such > "padding") would be worthwhile. Is there a maximum encoded length for > anything other than the constraints of the 2-bit 'len' field? > Interestingly, for DCSP we are much more strict -- why is the strictness > needed there but not in general? Is this just to faithfully reproduce RFC > 5575, as implied by the discussion in Appendix B? > (I would make this a DISCUSS point if I didn't think that we're acting as > if > we're required to preserve the RFC 5575 behavior.) > > A NLRI value not encoded as specified in Section 4.2 is considered > > This *is* Section 4.2; perhaps "specified here" or "specified below"? > > Section 4.2.1.1, 4.2.1.2 > > While I don't anticipate needing a future extension to numeric_op, having > the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper any > future extensibility efforts. > (Similarly for the "Traffic-action" field in Section 7.3, and > "Traffic-marking" from Section 7.5.) > > Section 4.2.2.3 > > This component uses the Numeric Operator (numeric_op) described in > Section 4.2.1.1. Type 3 component values SHOULD be encoded as single > octet (numeric_op len=00). > > Is it well-defined how I would encode the value if I ignored the SHOULD? > I, for one, am not sure what I would do... > > Section 4.2.2.4, etc. > > (I agree with my esteemed colleagues that hardcoding TCP and UDP as > "the only protocols with ports" is unnecessary.) > > system is unable to locate the transport header. Different > implementations may or may not be able to decode the transport header > in the presence of IP options or Encapsulating Security Payload (ESP) > NULL [RFC4303] encryption. > > If an implementation cannot decode the transport header does it treat all > such packets as matching or not matching? > > Section 4.2.2.7 > > In case of the presence of the ICMP type (code) component only ICMP > packets can match the entire Flow Specification. The ICMP type > > I'm not sure why the parenthetical is needed given that there's a separate > NRLI type for "ICMP code". > > Section 5.1 > > component type. If the component types are the same, then a type- > specific comparison is performed (see below) if the types are equal > the algorithm continues with the next component. > > nit: there seems to be some missing punctuation or conjunction here. > > For all other component types, unless otherwise specified, the > comparison is performed by comparing the component data as a binary > string using the memcmp() function as defined by [ISO_IEC_9899]. For > strings with equal lengths the lowest string (memcmp) has higher > precedence. For strings of different lengths, the common prefix is > compared. If the common prefix is not equal the string with the > lowest prefix has higher precedence. If the common prefix is equal, > the longest string is considered to have higher precedence than the > shorter one. > > It is surprising to me that the comparison operator can return "not-equal" > for different encodings of a quantity that have the same semantic value > (viz my previous note about encoding flexibility). That said, this > procedure is well-defined and BGP speakers are not going to be re-encoding > the NRLI values as they propagate, so I don't see an interop problem. > > Section 6 > > By default a Flow Specification NLRI MUST be validated such that it > is considered feasible if and only if all of the below is true: > > Perhaps "in the absence of explicit configuration otherwise," to more > closely parallel the other case? > > BGP implementations MUST also enforce that the AS_PATH attribute of a > route received via the External Border Gateway Protocol (eBGP) > contains the neighboring AS in the left-most position of the AS_PATH > attribute. While this rule is optional in the BGP specification, it > becomes necessary to enforce it for security reasons. > > nit: missing word (e.g., "necessary to enforce it here" or "necessary to > enforce it in processing flow specifications"). > > The best-match unicast route may change over the time independently > of the Flow Specification NLRI. Therefore, a revalidation of the > Flow Specification NLRI MUST be performed whenever unicast routes > change. Revalidation is defined as retesting that clause a and > clause b above are true. > > IMPORTANT: Why does clause c not need to be retested? > > The neighboring AS is the immediate destination of the traffic > described by the Flow Specification. If it requests these flows to > be dropped, that request can be honored without concern that it > represents a denial of service in itself. Supposedly, the traffic is > being dropped by the downstream autonomous system, and there is no > added value in carrying the traffic to it. > > (This presumes that there is some integrity protection applied to the > received data, which might be worth making more explicit.) > Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as if/ > > Section 7 > > Please be consistent about "ASN" vs. "AS" in Table 2. > > Should the "traffic-action" and "traffic-marking" actions list the encoded > length for the reader's convenience? > > Section 7.1 > > The remaining 4 octets carry the maximum rate information in IEEE > floating point [IEEE.754.1985] format, units being bytes per second. > > Thank you for being clear about the units! > > Section 7.2 > > Is there anything to say about what time interval a non-integer packet rate > should be evaluated over? > > Section 7.3 > > o T: Terminal Action (bit 47): When this bit is set, the traffic > filtering engine will evaluate any subsequent Flow Specifications > (as defined by the ordering procedure Section 5.1). If not set, > the evaluation of the traffic filters stops when this Flow > Specification is evaluated. > > Just to check I'm reading this right: when the "terminal action" bit is set > to one, it is *not* the terminal action, and the action *is* the terminal > action when the "terminal action" bit is set to zero? That sounds > backwards to my intuition (and maybe others'?). > > Section 7.4 > > Interferes with: No other BGP Flow Specification Traffic Filtering > Action in this document. > > Do the different possible 'type's for this 'sub-type' interfere with each > other? > > Section 7.6 > > Implementations should provide mechanisms that map an arbitrary BGP > community value (normal or extended) to Traffic Filtering Actions > that require different mappings in different systems in the network. > > nit(?): to my eye this reads better as "on different systems" (vs. "in"). > > For instance, providing packets with a worse-than-best-effort, per- > hop behavior is a functionality that is likely to be implemented > > nit: no comma after worst-than-best-effort. > > Section 7.7 > > other (e.g. there may be more than one conflicting traffic-rate-bytes > Traffic Filtering Action associated with a single Flow > Specification). Traffic Filtering Action interference has no impact > > Maybe we should revise the earlier text about "Interferes with: No other > [...]" to be explicit that it *does* self-interfere. > > behaviour (ie. match - replace - delete communities on administrative > boundaries). See also Section 12. > > nit: could this parenthetical be expanded a little bit more? I feel like > it's expected to be common knowledge among the main readership and so the > current wording just serves as a trigger for this "well-known" (but not to > me) concept, as opposed to standing on its own. > > Section 8 > > [side note: I'd love for us to eventually stop using "VPN" for things that > don't encrypt the data passing over them. This doesn't seem like the right > place to start, though.] > > Section 9 > > Should either/both of these mechanisms be on or off by default? > > Section 12 > > I'd consider mentioning again that some of the NRLI components won't work > properly on fragmented traffic and that unexpected fragmentation can cause > DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where > fragmentation can occur anywhere on the path.) > > Is it worth saying anything about how the RT-redirect actions can direct > traffic to an entity not expecting it (and, as such, potentially DoS them)? > > It also struck me as noteworthy that we're letting DSCP values creep out of > a single administrative scope -- the filtering of inbound DSCP markings > should probably be consistent with the traffic markings advertised to that > peer. (There is perhaps also some "information leakage" as to what > semantics are assigned to given DSCP values within the network in question, > but I find it hard to get too worked up about that, especially since the > inter-AS relationship is inherently pretty trusted.) > > As long as Flow Specifications are restricted to match the > corresponding unicast routing paths for the relevant prefixes > (Section 6), the security characteristics of this proposal are > > [There's an implicit "and both are received over trustworthy channels" in > here. Perhaps it's okay to remain implicit, given how well-known BGP's > security properties are...] > > Where the above mechanisms are not in place, this could open the door > to further denial-of-service attacks such as unwanted traffic > filtering, remarking or redirection. > > nit(?): I might just say "In particular, relaxing the validation procedure > could [...]". > > additional filtering. For example, the use of [RFC6811] to enhance > filtering within an AS confederation. > > nit: incomplete sentence. > > Inter-provider routing is based on a web of trust. Neighboring > autonomous systems are trusted to advertise valid reachability > information. If this trust model is violated, a neighboring > autonomous system may cause a denial-of-service attack by advertising > reachability information for a given prefix for which it does not > > I guess it's also a well-known attack that malicious neighbor could also > draw traffic to itself for snooping purposes without actually dropping the > traffic. But I'm not sure if there are any flowspec-specific > considerations > relating to that scenario. > > provide service (unfiltered address space hijack). Since validation > of the Flow Specification is tied to the announcement of the best > unicast route, this may also cause this validation to fail and > consequently prevent Flow Specifications from being accepted by a > peer. Possible mitigations are [RFC6811] and [RFC8205]. > > nit: there's a lot of pronouns ("this") in here; it might be worth > disambiguating a couple. > > Flow Specification BGP speakers (e.g. automated DDoS controllers) not > properly programmed, algorithms that are not performing as expected, > or simply rogue systems may announce unintended Flow Specifications, > send updates at a high rate or generate a high number of Flow > Specifications. This may stress the receiving systems, exceed their > maximum capacity or may lead to unwanted Traffic Filtering Actions > being applied to flows. > > Is there any relevant guidance to give to receiving systems? > > Appendix A > > I don't know that just this one function is useful without some description > of what format of input it requires. For example, if a.components and/or > b.components have elements that evaluate to "false", the first two checks > could return incorrect results (the perhaps-more-obvious case where both > comp_a and comp_b are None cannot happen due to the nature of zip_longest). > > Appendix B > > Section 7 defines all Traffic Filtering Action Extended > communities as transitive extended communities. [RFC5575] defined > the traffic-rate action to be non-transitive and did not define > the transitivity of the other Traffic Filtering Action communities > at all. > > I assume the consequences of changing a community from non-transitive to > transitive are well-known (but not to me) and that any operational > considerations for mixed deployments are already stated somewhere prominent > to someone working with BGP. (Where is that?) > > Section 7.7 contains general considerations on interfering traffic > actions. Section 7.3 also cross-references this section. > > nit(?): the last "this section" refers to 7.7, not the location of the text > I'm quoting from (Appendix B). I misread it the first time. > > > > --00000000000099d4fb05a3f65c91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin

Acceptance and v= alidation are completely different things.=C2=A0

B= y acceptance we say that router control plane accepted the update message= =C2=A0(as opposed to dropping it due to non intersecting RTs in VPNs).=C2= =A0

Validation however is executed on accepted rou= tes to check if such routes - or to be more precise paths - are eligible to= be used for best path selection and therefor for local installation into d= ata plane.=C2=A0

Hope that clarifies the discuss := )=C2=A0

Many thx,
r.

On Thu, Apr 23= , 2020 at 2:42 AM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the following ball= ot position for
draft-ietf-idr-rfc5575bis-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-idr-rfc5575bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There might be a minor internal inconsistency to tidy up (or I might be
misunderstanding things).=C2=A0 Section 8 states that:

=C2=A0 =C2=A0Contrary to the behavior specified for the non-VPN NLRI, Flow<= br> =C2=A0 =C2=A0Specifications are accepted by default, when received from rem= ote PE
=C2=A0 =C2=A0routers.

As far as I can tell, this is referring to the text in Section 6 where (for=
the non-VPN case) "By default a Flow Specification NLRI MUST be valida= ted
such that it is considered feasible if and only if all of the below is true=
[...]".=C2=A0 But immediately following what I quote above is a statem= ent that
"the validation proceure (section 6) [...] [is] the same as for IPv4&q= uot;, which
seems to be in conflict with this statement ("contrary to" vs. &q= uot;the same
as").


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The Abstract is perhaps pushing the length limits appropriate for an
Abstract (vs. Introduction).

Abstract

=C2=A0 =C2=A0Additionally, it defines two applications of that encoding for= mat:
=C2=A0 =C2=A0one that can be used to automate inter-domain coordination of = traffic
=C2=A0 =C2=A0filtering, such as what is required in order to mitigate
=C2=A0 =C2=A0(distributed) denial-of-service attacks, and a second applicat= ion to

This makes me think of the DOTS WG (but it's far from clear that we sho= uld
reference it in this text).

Section 1

=C2=A0 =C2=A0This document obsoletes "Dissemination of Flow Specificat= ion Rules"
=C2=A0 =C2=A0[RFC5575], the differences can be found in Appendix B.=C2=A0 T= his document

nit: comma splice

=C2=A0 =C2=A0A Flow Specification received from an external autonomous syst= em will
=C2=A0 =C2=A0need to be validated against unicast routing before being acce= pted
=C2=A0 =C2=A0(Section 6).=C2=A0 The Flow Specification received from an int= ernal BGP
=C2=A0 =C2=A0peer within the same autonomous system [RFC4271] is assumed to= have
=C2=A0 =C2=A0been validated prior to transmission within the internal BGP (= iBGP)
=C2=A0 =C2=A0mesh of an autonomous system.=C2=A0 If the aggregate traffic f= low defined

(Just to check, there's no particular harm in also validating iBGP
flowspecs, just the extra computation burden of doing so, right?)

=C2=A0 =C2=A0systems that are able to detect malicious traffic flows.=C2=A0= When
=C2=A0 =C2=A0automated systems are used, care should be taken to ensure the= ir
=C2=A0 =C2=A0correctness as well as the limitations of the systems that rec= eive
=C2=A0 =C2=A0and process the advertised Flow Specifications (see also Secti= on 12).

This seems to discuss making sure that the recipients of automated
information handle it robustly; is it also worth some considerations on
robustness of generating such automated information (something akin to a circuit breaker that would shut off the source if it started producing
nonsensical output)?
Also, nit: I think I parse this as "care should be taken to ensure [..= .] the
limitations of the systems that receive and process [flowspecs]", whic= h
doesn't quite seem like what was intended.

Section 4

=C2=A0 =C2=A0The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is enc= oded as
=C2=A0 =C2=A0one or more 2-tuples of the form <length, NLRI value>.= =C2=A0 It consists
=C2=A0 =C2=A0of a 1- or 2-octet length field followed by a variable-length = NLRI
=C2=A0 =C2=A0value.=C2=A0 The length is expressed in octets.

RFC 4760 only shows the one-octet length form; is there a good reference fo= r
the 2-octet length?=C2=A0 (Or is it "new" with 5575?)

Section 4.2

I think we should say something about how multi-byte values are encoded, especially given that we implicitly allow for different encodings of a give= n
value (e.g., IP protocol could have padding, and small port numbers don'= ;t
need to be encoded in 2 bytes).=C2=A0 Even just making it more explicit tha= t
multiple encodings are allowed (and what the semantics are for any such
"padding") would be worthwhile.=C2=A0 Is there a maximum encoded = length for
anything other than the constraints of the 2-bit 'len' field?
Interestingly, for DCSP we are much more strict -- why is the strictness needed there but not in general?=C2=A0 Is this just to faithfully reproduce= RFC
5575, as implied by the discussion in Appendix B?
(I would make this a DISCUSS point if I didn't think that we're act= ing as if
we're required to preserve the RFC 5575 behavior.)

=C2=A0 =C2=A0A NLRI value not encoded as specified in Section 4.2 is consid= ered

This *is* Section 4.2; perhaps "specified here" or "specifie= d below"?

Section 4.2.1.1, 4.2.1.2

While I don't anticipate needing a future extension to numeric_op, havi= ng
the '0' field only be "SHOULD be set to 0" (vs. "MUS= T") seems to hamper any
future extensibility efforts.
(Similarly for the "Traffic-action" field in Section 7.3, and
"Traffic-marking" from Section 7.5.)

Section 4.2.2.3

=C2=A0 =C2=A0This component uses the Numeric Operator (numeric_op) describe= d in
=C2=A0 =C2=A0Section 4.2.1.1.=C2=A0 Type 3 component values SHOULD be encod= ed as single
=C2=A0 =C2=A0octet (numeric_op len=3D00).

Is it well-defined how I would encode the value if I ignored the SHOULD? I, for one, am not sure what I would do...

Section 4.2.2.4, etc.

(I agree with my esteemed colleagues that hardcoding TCP and UDP as
"the only protocols with ports" is unnecessary.)

=C2=A0 =C2=A0system is unable to locate the transport header.=C2=A0 Differe= nt
=C2=A0 =C2=A0implementations may or may not be able to decode the transport= header
=C2=A0 =C2=A0in the presence of IP options or Encapsulating Security Payloa= d (ESP)
=C2=A0 =C2=A0NULL [RFC4303] encryption.

If an implementation cannot decode the transport header does it treat all such packets as matching or not matching?

Section 4.2.2.7

=C2=A0 =C2=A0In case of the presence of the ICMP type (code) component only= ICMP
=C2=A0 =C2=A0packets can match the entire Flow Specification.=C2=A0 The ICM= P type

I'm not sure why the parenthetical is needed given that there's a s= eparate
NRLI type for "ICMP code".

Section 5.1

=C2=A0 =C2=A0component type.=C2=A0 If the component types are the same, the= n a type-
=C2=A0 =C2=A0specific comparison is performed (see below) if the types are = equal
=C2=A0 =C2=A0the algorithm continues with the next component.

nit: there seems to be some missing punctuation or conjunction here.

=C2=A0 =C2=A0For all other component types, unless otherwise specified, the=
=C2=A0 =C2=A0comparison is performed by comparing the component data as a b= inary
=C2=A0 =C2=A0string using the memcmp() function as defined by [ISO_IEC_9899= ].=C2=A0 For
=C2=A0 =C2=A0strings with equal lengths the lowest string (memcmp) has high= er
=C2=A0 =C2=A0precedence.=C2=A0 For strings of different lengths, the common= prefix is
=C2=A0 =C2=A0compared.=C2=A0 If the common prefix is not equal the string w= ith the
=C2=A0 =C2=A0lowest prefix has higher precedence.=C2=A0 If the common prefi= x is equal,
=C2=A0 =C2=A0the longest string is considered to have higher precedence tha= n the
=C2=A0 =C2=A0shorter one.

It is surprising to me that the comparison operator can return "not-eq= ual"
for different encodings of a quantity that have the same semantic value
(viz my previous note about encoding flexibility).=C2=A0 That said, this procedure is well-defined and BGP speakers are not going to be re-encoding<= br> the NRLI values as they propagate, so I don't see an interop problem.
Section 6

=C2=A0 =C2=A0By default a Flow Specification NLRI MUST be validated such th= at it
=C2=A0 =C2=A0is considered feasible if and only if all of the below is true= :

Perhaps "in the absence of explicit configuration otherwise," to = more
closely parallel the other case?

=C2=A0 =C2=A0BGP implementations MUST also enforce that the AS_PATH attribu= te of a
=C2=A0 =C2=A0route received via the External Border Gateway Protocol (eBGP)=
=C2=A0 =C2=A0contains the neighboring AS in the left-most position of the A= S_PATH
=C2=A0 =C2=A0attribute.=C2=A0 While this rule is optional in the BGP specif= ication, it
=C2=A0 =C2=A0becomes necessary to enforce it for security reasons.

nit: missing word (e.g., "necessary to enforce it here" or "= necessary to
enforce it in processing flow specifications").

=C2=A0 =C2=A0The best-match unicast route may change over the time independ= ently
=C2=A0 =C2=A0of the Flow Specification NLRI.=C2=A0 Therefore, a revalidatio= n of the
=C2=A0 =C2=A0Flow Specification NLRI MUST be performed whenever unicast rou= tes
=C2=A0 =C2=A0change.=C2=A0 Revalidation is defined as retesting that clause= a and
=C2=A0 =C2=A0clause b above are true.

IMPORTANT: Why does clause c not need to be retested?

=C2=A0 =C2=A0The neighboring AS is the immediate destination of the traffic=
=C2=A0 =C2=A0described by the Flow Specification.=C2=A0 If it requests thes= e flows to
=C2=A0 =C2=A0be dropped, that request can be honored without concern that i= t
=C2=A0 =C2=A0represents a denial of service in itself.=C2=A0 Supposedly, th= e traffic is
=C2=A0 =C2=A0being dropped by the downstream autonomous system, and there i= s no
=C2=A0 =C2=A0added value in carrying the traffic to it.

(This presumes that there is some integrity protection applied to the
received data, which might be worth making more explicit.)
Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as i= f/

Section 7

Please be consistent about "ASN" vs. "AS" in Table 2.
Should the "traffic-action" and "traffic-marking" actio= ns list the encoded
length for the reader's convenience?

Section 7.1

=C2=A0 =C2=A0The remaining 4 octets carry the maximum rate information in I= EEE
=C2=A0 =C2=A0floating point [IEEE.754.1985] format, units being bytes per s= econd.

Thank you for being clear about the units!

Section 7.2

Is there anything to say about what time interval a non-integer packet rate=
should be evaluated over?

Section 7.3

=C2=A0 =C2=A0o=C2=A0 T: Terminal Action (bit 47): When this bit is set, the= traffic
=C2=A0 =C2=A0 =C2=A0 filtering engine will evaluate any subsequent Flow Spe= cifications
=C2=A0 =C2=A0 =C2=A0 (as defined by the ordering procedure Section 5.1).=C2= =A0 If not set,
=C2=A0 =C2=A0 =C2=A0 the evaluation of the traffic filters stops when this = Flow
=C2=A0 =C2=A0 =C2=A0 Specification is evaluated.

Just to check I'm reading this right: when the "terminal action&qu= ot; bit is set
to one, it is *not* the terminal action, and the action *is* the terminal action when the "terminal action" bit is set to zero?=C2=A0 That = sounds
backwards to my intuition (and maybe others'?).

Section 7.4

=C2=A0 =C2=A0Interferes with: No other BGP Flow Specification Traffic Filte= ring
=C2=A0 =C2=A0Action in this document.

Do the different possible 'type's for this 'sub-type' inter= fere with each
other?

Section 7.6

=C2=A0 =C2=A0Implementations should provide mechanisms that map an arbitrar= y BGP
=C2=A0 =C2=A0community value (normal or extended) to Traffic Filtering Acti= ons
=C2=A0 =C2=A0that require different mappings in different systems in the ne= twork.

nit(?): to my eye this reads better as "on different systems" (vs= . "in").

=C2=A0 =C2=A0For instance, providing packets with a worse-than-best-effort,= per-
=C2=A0 =C2=A0hop behavior is a functionality that is likely to be implement= ed

nit: no comma after worst-than-best-effort.

Section 7.7

=C2=A0 =C2=A0other (e.g. there may be more than one conflicting traffic-rat= e-bytes
=C2=A0 =C2=A0Traffic Filtering Action associated with a single Flow
=C2=A0 =C2=A0Specification).=C2=A0 Traffic Filtering Action interference ha= s no impact

Maybe we should revise the earlier text about "Interferes with: No oth= er
[...]" to be explicit that it *does* self-interfere.

=C2=A0 =C2=A0behaviour (ie. match - replace - delete communities on adminis= trative
=C2=A0 =C2=A0boundaries).=C2=A0 See also Section 12.

nit: could this parenthetical be expanded a little bit more?=C2=A0 I feel l= ike
it's expected to be common knowledge among the main readership and so t= he
current wording just serves as a trigger for this "well-known" (b= ut not to
me) concept, as opposed to standing on its own.

Section 8

[side note: I'd love for us to eventually stop using "VPN" fo= r things that
don't encrypt the data passing over them.=C2=A0 This doesn't seem l= ike the right
place to start, though.]

Section 9

Should either/both of these mechanisms be on or off by default?

Section 12

I'd consider mentioning again that some of the NRLI components won'= t work
properly on fragmented traffic and that unexpected fragmentation can cause<= br> DoS.=C2=A0 (This is particularly relevant for IPv4, as opposed to IPv6, whe= re
fragmentation can occur anywhere on the path.)

Is it worth saying anything about how the RT-redirect actions can direct traffic to an entity not expecting it (and, as such, potentially DoS them)?=

It also struck me as noteworthy that we're letting DSCP values creep ou= t of
a single administrative scope -- the filtering of inbound DSCP markings
should probably be consistent with the traffic markings advertised to that<= br> peer.=C2=A0 (There is perhaps also some "information leakage" as = to what
semantics are assigned to given DSCP values within the network in question,=
but I find it hard to get too worked up about that, especially since the inter-AS relationship is inherently pretty trusted.)

=C2=A0 =C2=A0As long as Flow Specifications are restricted to match the
=C2=A0 =C2=A0corresponding unicast routing paths for the relevant prefixes<= br> =C2=A0 =C2=A0(Section 6), the security characteristics of this proposal are=

[There's an implicit "and both are received over trustworthy chann= els" in
here.=C2=A0 Perhaps it's okay to remain implicit, given how well-known = BGP's
security properties are...]

=C2=A0 =C2=A0Where the above mechanisms are not in place, this could open t= he door
=C2=A0 =C2=A0to further denial-of-service attacks such as unwanted traffic<= br> =C2=A0 =C2=A0filtering, remarking or redirection.

nit(?): I might just say "In particular, relaxing the validation proce= dure
could [...]".

=C2=A0 =C2=A0additional filtering.=C2=A0 For example, the use of [RFC6811] = to enhance
=C2=A0 =C2=A0filtering within an AS confederation.

nit: incomplete sentence.

=C2=A0 =C2=A0Inter-provider routing is based on a web of trust.=C2=A0 Neigh= boring
=C2=A0 =C2=A0autonomous systems are trusted to advertise valid reachability=
=C2=A0 =C2=A0information.=C2=A0 If this trust model is violated, a neighbor= ing
=C2=A0 =C2=A0autonomous system may cause a denial-of-service attack by adve= rtising
=C2=A0 =C2=A0reachability information for a given prefix for which it does = not

I guess it's also a well-known attack that malicious neighbor could als= o
draw traffic to itself for snooping purposes without actually dropping the<= br> traffic.=C2=A0 But I'm not sure if there are any flowspec-specific cons= iderations
relating to that scenario.

=C2=A0 =C2=A0provide service (unfiltered address space hijack).=C2=A0 Since= validation
=C2=A0 =C2=A0of the Flow Specification is tied to the announcement of the b= est
=C2=A0 =C2=A0unicast route, this may also cause this validation to fail and=
=C2=A0 =C2=A0consequently prevent Flow Specifications from being accepted b= y a
=C2=A0 =C2=A0peer.=C2=A0 Possible mitigations are [RFC6811] and [RFC8205].<= br>
nit: there's a lot of pronouns ("this") in here; it might be = worth
disambiguating a couple.

=C2=A0 =C2=A0Flow Specification BGP speakers (e.g. automated DDoS controlle= rs) not
=C2=A0 =C2=A0properly programmed, algorithms that are not performing as exp= ected,
=C2=A0 =C2=A0or simply rogue systems may announce unintended Flow Specifica= tions,
=C2=A0 =C2=A0send updates at a high rate or generate a high number of Flow<= br> =C2=A0 =C2=A0Specifications.=C2=A0 This may stress the receiving systems, e= xceed their
=C2=A0 =C2=A0maximum capacity or may lead to unwanted Traffic Filtering Act= ions
=C2=A0 =C2=A0being applied to flows.

Is there any relevant guidance to give to receiving systems?

Appendix A

I don't know that just this one function is useful without some descrip= tion
of what format of input it requires.=C2=A0 For example, if a.components and= /or
b.components have elements that evaluate to "false", the first tw= o checks
could return incorrect results (the perhaps-more-obvious case where both comp_a and comp_b are None cannot happen due to the nature of zip_longest).=

Appendix B

=C2=A0 =C2=A0 =C2=A0 Section 7 defines all Traffic Filtering Action Extende= d
=C2=A0 =C2=A0 =C2=A0 communities as transitive extended communities.=C2=A0 = [RFC5575] defined
=C2=A0 =C2=A0 =C2=A0 the traffic-rate action to be non-transitive and did n= ot define
=C2=A0 =C2=A0 =C2=A0 the transitivity of the other Traffic Filtering Action= communities
=C2=A0 =C2=A0 =C2=A0 at all.

I assume the consequences of changing a community from non-transitive to transitive are well-known (but not to me) and that any operational
considerations for mixed deployments are already stated somewhere prominent=
to someone working with BGP.=C2=A0 (Where is that?)

=C2=A0 =C2=A0 =C2=A0 Section 7.7 contains general considerations on interfe= ring traffic
=C2=A0 =C2=A0 =C2=A0 actions.=C2=A0 Section 7.3 also cross-references this = section.

nit(?): the last "this section" refers to 7.7, not the location o= f the text
I'm quoting from (Appendix B).=C2=A0 I misread it the first time.



--00000000000099d4fb05a3f65c91-- From nobody Thu Apr 23 07:53:49 2020 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 F22743A095C for ; Thu, 23 Apr 2020 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8UkyqgNcUUI for ; Thu, 23 Apr 2020 07:53:38 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 43D5D3A0954 for ; Thu, 23 Apr 2020 07:53:38 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id q8so4913616eja.2 for ; Thu, 23 Apr 2020 07:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bMojy4PF392p3l78TxqDtWGftPiWY5wBFG7uk7qISDo=; b=QGPBgJgY3qZpetDvrZ+hJ/aj+raj2I0AGPzbDG3IbMY4fv0wo1cpULVnPzGYOasux4 72OUiinIZp8NvmC+y6S5nvC5hH58N+eygUi8RruCSZgahseGLc94UrHCM/dND8YCHpwc oFXGtNTobxCT2h/D8wxzkDAvH6DqEi1x6ATasztt8pPnAlU6F2UwfGcKDekztH9clJdG mPV5E2/l2HvSBJcyp+AuAl/+EwM+TGL1xhurWiwM6jZ+KBnpr8FZwVf2Lc0kfxv698p+ 8vxJp3pZnSknuALL+Rj6EtGu2NkTSa82PU8Gjvy8I6IKMQbRhNkSiW7Knag3TEIM7fg5 q90w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bMojy4PF392p3l78TxqDtWGftPiWY5wBFG7uk7qISDo=; b=A5x4tUXWyTxwzXWWlCNWguov5LK6pK22L1XujLOzyrRuhr19GWqXJVlxIVkQTVvf8c 8LpunvOx83OxzIpZVIkqaj768lZrB/O4PAgbSULjDC9i5g8NGXl6OQkEa4z9faEz1Ye5 MoxR8MVvHG6AEpSHQUI7pMQpQHlhJ+uYFLhF2SPt+kmQrYExSwT5g9okrZM/sX4mv1n6 7JAcE+QQ0nQb+TljIQVqKqW/itugWriKIBanpbnkTSJvdwyTnr8q4mhexbLSon1p9Q1Y ei1bW/k4KD0C6Th/JHNl3oGq0QGFVbM3Bpf4j3dqobHi0HwsazDVLaV/TmTNfFjFMLct JYkA== X-Gm-Message-State: AGi0PuY3frIk1JDqsFnFbY/FgKWr9AnzuQUHSBdwOMwQqo9r4z1+c38d DMiJKIcTSh5v6bWkeKRzi3c4QeLQjLft2IbL9QX1jQ== X-Google-Smtp-Source: APiQypK8PzBtGZQ6jDPxHspo54yjFBLZbHdYQwbwrHdS8rev0t4U8j+VZ+FnS5eAnT3pjW34dwjwgBBAdRYfkZf4b/U= X-Received: by 2002:a17:906:1fd6:: with SMTP id e22mr3049849ejt.150.1587653616520; Thu, 23 Apr 2020 07:53:36 -0700 (PDT) MIME-Version: 1.0 References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> <95C65325-EE11-42A1-8BAE-967BA2A0E448@tix.at> In-Reply-To: <95C65325-EE11-42A1-8BAE-967BA2A0E448@tix.at> From: Robert Raszuk Date: Thu, 23 Apr 2020 16:53:25 +0200 Message-ID: To: Christoph Loibl Cc: Benjamin Kaduk , The IESG , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000d6e92f05a3f669ac" Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 14:53:43 -0000 --000000000000d6e92f05a3f669ac Content-Type: text/plain; charset="UTF-8" That suggestion is not right. They can be received via RRs etc ... I think the text is fine as is. I think Benjamin perhaps thought that validation happens on ingress to the router. I am not sure if we want to highlight the real meaning - I think it is already described in other sections. Thx, R. On Thu, Apr 23, 2020 at 10:53 AM Christoph Loibl wrote: > Hi Benjamin, > > Thanks for your review. I opened cases for all of the issues you raised in > the github repo: > > https://github.com/stoffi92/rfc5575bis > > The discuss item you raised is this: > > https://github.com/stoffi92/rfc5575bis/issues/184 > > To resolve this I suggest the following change to the document: > > I suggest to change it to the following (I hope that Robert and Sue can > also have a look if this is still correct to the desired behaviour): > > OLD: > Contrary to the behavior specified for the non-VPN NLRI, Flow > Specifications are accepted by default, when received from remote PE > routers. > > The validation procedure (Section 6) and Traffic Filtering Actions > (Section 7) are the same as for IPv4. > > NEW: > Contrary to the behavior specified for the non-VPN NLRI, Flow > Specifications are accepted by default, when received from remote PE > routers. The validation procedure (Section 6) when Flow Specifications > are received from a remote CE are the same as for IPv4. > > Traffic Filtering Actions (Section 7) are the same as for IPv4. > > > Cheers Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > > > On 23.04.2020, at 02:42, Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-idr-rfc5575bis-22: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > There might be a minor internal inconsistency to tidy up (or I might be > > misunderstanding things). Section 8 states that: > > > > Contrary to the behavior specified for the non-VPN NLRI, Flow > > Specifications are accepted by default, when received from remote PE > > routers. > > > > As far as I can tell, this is referring to the text in Section 6 where > (for > > the non-VPN case) "By default a Flow Specification NLRI MUST be validated > > such that it is considered feasible if and only if all of the below is > true > > [...]". But immediately following what I quote above is a statement that > > "the validation proceure (section 6) [...] [is] the same as for IPv4", > which > > seems to be in conflict with this statement ("contrary to" vs. "the same > > as"). > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > The Abstract is perhaps pushing the length limits appropriate for an > > Abstract (vs. Introduction). > > > > Abstract > > > > Additionally, it defines two applications of that encoding format: > > one that can be used to automate inter-domain coordination of traffic > > filtering, such as what is required in order to mitigate > > (distributed) denial-of-service attacks, and a second application to > > > > This makes me think of the DOTS WG (but it's far from clear that we > should > > reference it in this text). > > > > Section 1 > > > > This document obsoletes "Dissemination of Flow Specification Rules" > > [RFC5575], the differences can be found in Appendix B. This document > > > > nit: comma splice > > > > A Flow Specification received from an external autonomous system will > > need to be validated against unicast routing before being accepted > > (Section 6). The Flow Specification received from an internal BGP > > peer within the same autonomous system [RFC4271] is assumed to have > > been validated prior to transmission within the internal BGP (iBGP) > > mesh of an autonomous system. If the aggregate traffic flow defined > > > > (Just to check, there's no particular harm in also validating iBGP > > flowspecs, just the extra computation burden of doing so, right?) > > > > systems that are able to detect malicious traffic flows. When > > automated systems are used, care should be taken to ensure their > > correctness as well as the limitations of the systems that receive > > and process the advertised Flow Specifications (see also Section 12). > > > > This seems to discuss making sure that the recipients of automated > > information handle it robustly; is it also worth some considerations on > > robustness of generating such automated information (something akin to a > > circuit breaker that would shut off the source if it started producing > > nonsensical output)? > > Also, nit: I think I parse this as "care should be taken to ensure [...] > the > > limitations of the systems that receive and process [flowspecs]", which > > doesn't quite seem like what was intended. > > > > Section 4 > > > > The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as > > one or more 2-tuples of the form . It consists > > of a 1- or 2-octet length field followed by a variable-length NLRI > > value. The length is expressed in octets. > > > > RFC 4760 only shows the one-octet length form; is there a good reference > for > > the 2-octet length? (Or is it "new" with 5575?) > > > > Section 4.2 > > > > I think we should say something about how multi-byte values are encoded, > > especially given that we implicitly allow for different encodings of a > given > > value (e.g., IP protocol could have padding, and small port numbers don't > > need to be encoded in 2 bytes). Even just making it more explicit that > > multiple encodings are allowed (and what the semantics are for any such > > "padding") would be worthwhile. Is there a maximum encoded length for > > anything other than the constraints of the 2-bit 'len' field? > > Interestingly, for DCSP we are much more strict -- why is the strictness > > needed there but not in general? Is this just to faithfully reproduce > RFC > > 5575, as implied by the discussion in Appendix B? > > (I would make this a DISCUSS point if I didn't think that we're acting > as if > > we're required to preserve the RFC 5575 behavior.) > > > > A NLRI value not encoded as specified in Section 4.2 is considered > > > > This *is* Section 4.2; perhaps "specified here" or "specified below"? > > > > Section 4.2.1.1, 4.2.1.2 > > > > While I don't anticipate needing a future extension to numeric_op, having > > the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper > any > > future extensibility efforts. > > (Similarly for the "Traffic-action" field in Section 7.3, and > > "Traffic-marking" from Section 7.5.) > > > > Section 4.2.2.3 > > > > This component uses the Numeric Operator (numeric_op) described in > > Section 4.2.1.1. Type 3 component values SHOULD be encoded as single > > octet (numeric_op len=00). > > > > Is it well-defined how I would encode the value if I ignored the SHOULD? > > I, for one, am not sure what I would do... > > > > Section 4.2.2.4, etc. > > > > (I agree with my esteemed colleagues that hardcoding TCP and UDP as > > "the only protocols with ports" is unnecessary.) > > > > system is unable to locate the transport header. Different > > implementations may or may not be able to decode the transport header > > in the presence of IP options or Encapsulating Security Payload (ESP) > > NULL [RFC4303] encryption. > > > > If an implementation cannot decode the transport header does it treat all > > such packets as matching or not matching? > > > > Section 4.2.2.7 > > > > In case of the presence of the ICMP type (code) component only ICMP > > packets can match the entire Flow Specification. The ICMP type > > > > I'm not sure why the parenthetical is needed given that there's a > separate > > NRLI type for "ICMP code". > > > > Section 5.1 > > > > component type. If the component types are the same, then a type- > > specific comparison is performed (see below) if the types are equal > > the algorithm continues with the next component. > > > > nit: there seems to be some missing punctuation or conjunction here. > > > > For all other component types, unless otherwise specified, the > > comparison is performed by comparing the component data as a binary > > string using the memcmp() function as defined by [ISO_IEC_9899]. For > > strings with equal lengths the lowest string (memcmp) has higher > > precedence. For strings of different lengths, the common prefix is > > compared. If the common prefix is not equal the string with the > > lowest prefix has higher precedence. If the common prefix is equal, > > the longest string is considered to have higher precedence than the > > shorter one. > > > > It is surprising to me that the comparison operator can return > "not-equal" > > for different encodings of a quantity that have the same semantic value > > (viz my previous note about encoding flexibility). That said, this > > procedure is well-defined and BGP speakers are not going to be > re-encoding > > the NRLI values as they propagate, so I don't see an interop problem. > > > > Section 6 > > > > By default a Flow Specification NLRI MUST be validated such that it > > is considered feasible if and only if all of the below is true: > > > > Perhaps "in the absence of explicit configuration otherwise," to more > > closely parallel the other case? > > > > BGP implementations MUST also enforce that the AS_PATH attribute of a > > route received via the External Border Gateway Protocol (eBGP) > > contains the neighboring AS in the left-most position of the AS_PATH > > attribute. While this rule is optional in the BGP specification, it > > becomes necessary to enforce it for security reasons. > > > > nit: missing word (e.g., "necessary to enforce it here" or "necessary to > > enforce it in processing flow specifications"). > > > > The best-match unicast route may change over the time independently > > of the Flow Specification NLRI. Therefore, a revalidation of the > > Flow Specification NLRI MUST be performed whenever unicast routes > > change. Revalidation is defined as retesting that clause a and > > clause b above are true. > > > > IMPORTANT: Why does clause c not need to be retested? > > > > The neighboring AS is the immediate destination of the traffic > > described by the Flow Specification. If it requests these flows to > > be dropped, that request can be honored without concern that it > > represents a denial of service in itself. Supposedly, the traffic is > > being dropped by the downstream autonomous system, and there is no > > added value in carrying the traffic to it. > > > > (This presumes that there is some integrity protection applied to the > > received data, which might be worth making more explicit.) > > Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as if/ > > > > Section 7 > > > > Please be consistent about "ASN" vs. "AS" in Table 2. > > > > Should the "traffic-action" and "traffic-marking" actions list the > encoded > > length for the reader's convenience? > > > > Section 7.1 > > > > The remaining 4 octets carry the maximum rate information in IEEE > > floating point [IEEE.754.1985] format, units being bytes per second. > > > > Thank you for being clear about the units! > > > > Section 7.2 > > > > Is there anything to say about what time interval a non-integer packet > rate > > should be evaluated over? > > > > Section 7.3 > > > > o T: Terminal Action (bit 47): When this bit is set, the traffic > > filtering engine will evaluate any subsequent Flow Specifications > > (as defined by the ordering procedure Section 5.1). If not set, > > the evaluation of the traffic filters stops when this Flow > > Specification is evaluated. > > > > Just to check I'm reading this right: when the "terminal action" bit is > set > > to one, it is *not* the terminal action, and the action *is* the terminal > > action when the "terminal action" bit is set to zero? That sounds > > backwards to my intuition (and maybe others'?). > > > > Section 7.4 > > > > Interferes with: No other BGP Flow Specification Traffic Filtering > > Action in this document. > > > > Do the different possible 'type's for this 'sub-type' interfere with each > > other? > > > > Section 7.6 > > > > Implementations should provide mechanisms that map an arbitrary BGP > > community value (normal or extended) to Traffic Filtering Actions > > that require different mappings in different systems in the network. > > > > nit(?): to my eye this reads better as "on different systems" (vs. "in"). > > > > For instance, providing packets with a worse-than-best-effort, per- > > hop behavior is a functionality that is likely to be implemented > > > > nit: no comma after worst-than-best-effort. > > > > Section 7.7 > > > > other (e.g. there may be more than one conflicting traffic-rate-bytes > > Traffic Filtering Action associated with a single Flow > > Specification). Traffic Filtering Action interference has no impact > > > > Maybe we should revise the earlier text about "Interferes with: No other > > [...]" to be explicit that it *does* self-interfere. > > > > behaviour (ie. match - replace - delete communities on administrative > > boundaries). See also Section 12. > > > > nit: could this parenthetical be expanded a little bit more? I feel like > > it's expected to be common knowledge among the main readership and so the > > current wording just serves as a trigger for this "well-known" (but not > to > > me) concept, as opposed to standing on its own. > > > > Section 8 > > > > [side note: I'd love for us to eventually stop using "VPN" for things > that > > don't encrypt the data passing over them. This doesn't seem like the > right > > place to start, though.] > > > > Section 9 > > > > Should either/both of these mechanisms be on or off by default? > > > > Section 12 > > > > I'd consider mentioning again that some of the NRLI components won't work > > properly on fragmented traffic and that unexpected fragmentation can > cause > > DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where > > fragmentation can occur anywhere on the path.) > > > > Is it worth saying anything about how the RT-redirect actions can direct > > traffic to an entity not expecting it (and, as such, potentially DoS > them)? > > > > It also struck me as noteworthy that we're letting DSCP values creep out > of > > a single administrative scope -- the filtering of inbound DSCP markings > > should probably be consistent with the traffic markings advertised to > that > > peer. (There is perhaps also some "information leakage" as to what > > semantics are assigned to given DSCP values within the network in > question, > > but I find it hard to get too worked up about that, especially since the > > inter-AS relationship is inherently pretty trusted.) > > > > As long as Flow Specifications are restricted to match the > > corresponding unicast routing paths for the relevant prefixes > > (Section 6), the security characteristics of this proposal are > > > > [There's an implicit "and both are received over trustworthy channels" in > > here. Perhaps it's okay to remain implicit, given how well-known BGP's > > security properties are...] > > > > Where the above mechanisms are not in place, this could open the door > > to further denial-of-service attacks such as unwanted traffic > > filtering, remarking or redirection. > > > > nit(?): I might just say "In particular, relaxing the validation > procedure > > could [...]". > > > > additional filtering. For example, the use of [RFC6811] to enhance > > filtering within an AS confederation. > > > > nit: incomplete sentence. > > > > Inter-provider routing is based on a web of trust. Neighboring > > autonomous systems are trusted to advertise valid reachability > > information. If this trust model is violated, a neighboring > > autonomous system may cause a denial-of-service attack by advertising > > reachability information for a given prefix for which it does not > > > > I guess it's also a well-known attack that malicious neighbor could also > > draw traffic to itself for snooping purposes without actually dropping > the > > traffic. But I'm not sure if there are any flowspec-specific > considerations > > relating to that scenario. > > > > provide service (unfiltered address space hijack). Since validation > > of the Flow Specification is tied to the announcement of the best > > unicast route, this may also cause this validation to fail and > > consequently prevent Flow Specifications from being accepted by a > > peer. Possible mitigations are [RFC6811] and [RFC8205]. > > > > nit: there's a lot of pronouns ("this") in here; it might be worth > > disambiguating a couple. > > > > Flow Specification BGP speakers (e.g. automated DDoS controllers) not > > properly programmed, algorithms that are not performing as expected, > > or simply rogue systems may announce unintended Flow Specifications, > > send updates at a high rate or generate a high number of Flow > > Specifications. This may stress the receiving systems, exceed their > > maximum capacity or may lead to unwanted Traffic Filtering Actions > > being applied to flows. > > > > Is there any relevant guidance to give to receiving systems? > > > > Appendix A > > > > I don't know that just this one function is useful without some > description > > of what format of input it requires. For example, if a.components and/or > > b.components have elements that evaluate to "false", the first two checks > > could return incorrect results (the perhaps-more-obvious case where both > > comp_a and comp_b are None cannot happen due to the nature of > zip_longest). > > > > Appendix B > > > > Section 7 defines all Traffic Filtering Action Extended > > communities as transitive extended communities. [RFC5575] defined > > the traffic-rate action to be non-transitive and did not define > > the transitivity of the other Traffic Filtering Action communities > > at all. > > > > I assume the consequences of changing a community from non-transitive to > > transitive are well-known (but not to me) and that any operational > > considerations for mixed deployments are already stated somewhere > prominent > > to someone working with BGP. (Where is that?) > > > > Section 7.7 contains general considerations on interfering traffic > > actions. Section 7.3 also cross-references this section. > > > > nit(?): the last "this section" refers to 7.7, not the location of the > text > > I'm quoting from (Appendix B). I misread it the first time. > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > --000000000000d6e92f05a3f669ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

That suggestion is not right.=C2=A0
They can be received via RRs etc ...=C2=A0

=
I think the text is fine as is. I think Benjamin perhaps thought that = validation happens=C2=A0on ingress to the router. I am not sure if we want = to highlight the real meaning - I think it is already described in other se= ctions.=C2=A0

Thx,
R.


On Thu, Apr 23, 2020 at 10:53 AM Christoph Loibl <c@tix.at> wrote:
Hi Benjamin,

Thanks for your review. I opened cases for all of the issues you raised in = the github repo:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/stoffi92/rfc557= 5bis

The discuss item you raised is this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/stof= fi92/rfc5575bis/issues/184

To resolve this I suggest the following change to the document:

I suggest to change it to the following (I hope that Robert and Sue can als= o have a look if this is still correct to the desired behaviour):

OLD:
=C2=A0 =C2=A0Contrary to the behavior specified for the non-VPN NLRI, Flow<= br> =C2=A0 =C2=A0Specifications are accepted by default, when received from rem= ote PE
=C2=A0 =C2=A0routers.

=C2=A0 =C2=A0The validation procedure (Section 6) and Traffic Filtering Act= ions
=C2=A0 =C2=A0(Section 7) are the same as for IPv4.

NEW:
=C2=A0 =C2=A0Contrary to the behavior specified for the non-VPN NLRI, Flow<= br> =C2=A0 =C2=A0Specifications are accepted by default, when received from rem= ote PE
=C2=A0 =C2=A0routers. The validation procedure (Section 6) when Flow Specif= ications
=C2=A0 =C2=A0are received from a remote CE are the same as for IPv4.

=C2=A0 =C2=A0Traffic Filtering Actions (Section 7) are the same as for IPv4= .


Cheers Christoph

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



> On 23.04.2020, at 02:42, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:=
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-idr-rfc5575bis-22: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/dra= ft-ietf-idr-rfc5575bis/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> There might be a minor internal inconsistency to tidy up (or I might b= e
> misunderstanding things).=C2=A0 Section 8 states that:
>
>=C2=A0 =C2=A0Contrary to the behavior specified for the non-VPN NLRI, F= low
>=C2=A0 =C2=A0Specifications are accepted by default, when received from= remote PE
>=C2=A0 =C2=A0routers.
>
> As far as I can tell, this is referring to the text in Section 6 where= (for
> the non-VPN case) "By default a Flow Specification NLRI MUST be v= alidated
> such that it is considered feasible if and only if all of the below is= true
> [...]".=C2=A0 But immediately following what I quote above is a s= tatement that
> "the validation proceure (section 6) [...] [is] the same as for I= Pv4", which
> seems to be in conflict with this statement ("contrary to" v= s. "the same
> as").
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> The Abstract is perhaps pushing the length limits appropriate for an > Abstract (vs. Introduction).
>
> Abstract
>
>=C2=A0 =C2=A0Additionally, it defines two applications of that encoding= format:
>=C2=A0 =C2=A0one that can be used to automate inter-domain coordination= of traffic
>=C2=A0 =C2=A0filtering, such as what is required in order to mitigate >=C2=A0 =C2=A0(distributed) denial-of-service attacks, and a second appl= ication to
>
> This makes me think of the DOTS WG (but it's far from clear that w= e should
> reference it in this text).
>
> Section 1
>
>=C2=A0 =C2=A0This document obsoletes "Dissemination of Flow Specif= ication Rules"
>=C2=A0 =C2=A0[RFC5575], the differences can be found in Appendix B.=C2= =A0 This document
>
> nit: comma splice
>
>=C2=A0 =C2=A0A Flow Specification received from an external autonomous = system will
>=C2=A0 =C2=A0need to be validated against unicast routing before being = accepted
>=C2=A0 =C2=A0(Section 6).=C2=A0 The Flow Specification received from an= internal BGP
>=C2=A0 =C2=A0peer within the same autonomous system [RFC4271] is assume= d to have
>=C2=A0 =C2=A0been validated prior to transmission within the internal B= GP (iBGP)
>=C2=A0 =C2=A0mesh of an autonomous system.=C2=A0 If the aggregate traff= ic flow defined
>
> (Just to check, there's no particular harm in also validating iBGP=
> flowspecs, just the extra computation burden of doing so, right?)
>
>=C2=A0 =C2=A0systems that are able to detect malicious traffic flows.= =C2=A0 When
>=C2=A0 =C2=A0automated systems are used, care should be taken to ensure= their
>=C2=A0 =C2=A0correctness as well as the limitations of the systems that= receive
>=C2=A0 =C2=A0and process the advertised Flow Specifications (see also S= ection 12).
>
> This seems to discuss making sure that the recipients of automated
> information handle it robustly; is it also worth some considerations o= n
> robustness of generating such automated information (something akin to= a
> circuit breaker that would shut off the source if it started producing=
> nonsensical output)?
> Also, nit: I think I parse this as "care should be taken to ensur= e [...] the
> limitations of the systems that receive and process [flowspecs]",= which
> doesn't quite seem like what was intended.
>
> Section 4
>
>=C2=A0 =C2=A0The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is= encoded as
>=C2=A0 =C2=A0one or more 2-tuples of the form <length, NLRI value>= ;.=C2=A0 It consists
>=C2=A0 =C2=A0of a 1- or 2-octet length field followed by a variable-len= gth NLRI
>=C2=A0 =C2=A0value.=C2=A0 The length is expressed in octets.
>
> RFC 4760 only shows the one-octet length form; is there a good referen= ce for
> the 2-octet length?=C2=A0 (Or is it "new" with 5575?)
>
> Section 4.2
>
> I think we should say something about how multi-byte values are encode= d,
> especially given that we implicitly allow for different encodings of a= given
> value (e.g., IP protocol could have padding, and small port numbers do= n't
> need to be encoded in 2 bytes).=C2=A0 Even just making it more explici= t that
> multiple encodings are allowed (and what the semantics are for any suc= h
> "padding") would be worthwhile.=C2=A0 Is there a maximum enc= oded length for
> anything other than the constraints of the 2-bit 'len' field?<= br> > Interestingly, for DCSP we are much more strict -- why is the strictne= ss
> needed there but not in general?=C2=A0 Is this just to faithfully repr= oduce RFC
> 5575, as implied by the discussion in Appendix B?
> (I would make this a DISCUSS point if I didn't think that we'r= e acting as if
> we're required to preserve the RFC 5575 behavior.)
>
>=C2=A0 =C2=A0A NLRI value not encoded as specified in Section 4.2 is co= nsidered
>
> This *is* Section 4.2; perhaps "specified here" or "spe= cified below"?
>
> Section 4.2.1.1, 4.2.1.2
>
> While I don't anticipate needing a future extension to numeric_op,= having
> the '0' field only be "SHOULD be set to 0" (vs. &quo= t;MUST") seems to hamper any
> future extensibility efforts.
> (Similarly for the "Traffic-action" field in Section 7.3, an= d
> "Traffic-marking" from Section 7.5.)
>
> Section 4.2.2.3
>
>=C2=A0 =C2=A0This component uses the Numeric Operator (numeric_op) desc= ribed in
>=C2=A0 =C2=A0Section 4.2.1.1.=C2=A0 Type 3 component values SHOULD be e= ncoded as single
>=C2=A0 =C2=A0octet (numeric_op len=3D00).
>
> Is it well-defined how I would encode the value if I ignored the SHOUL= D?
> I, for one, am not sure what I would do...
>
> Section 4.2.2.4, etc.
>
> (I agree with my esteemed colleagues that hardcoding TCP and UDP as > "the only protocols with ports" is unnecessary.)
>
>=C2=A0 =C2=A0system is unable to locate the transport header.=C2=A0 Dif= ferent
>=C2=A0 =C2=A0implementations may or may not be able to decode the trans= port header
>=C2=A0 =C2=A0in the presence of IP options or Encapsulating Security Pa= yload (ESP)
>=C2=A0 =C2=A0NULL [RFC4303] encryption.
>
> If an implementation cannot decode the transport header does it treat = all
> such packets as matching or not matching?
>
> Section 4.2.2.7
>
>=C2=A0 =C2=A0In case of the presence of the ICMP type (code) component = only ICMP
>=C2=A0 =C2=A0packets can match the entire Flow Specification.=C2=A0 The= ICMP type
>
> I'm not sure why the parenthetical is needed given that there'= s a separate
> NRLI type for "ICMP code".
>
> Section 5.1
>
>=C2=A0 =C2=A0component type.=C2=A0 If the component types are the same,= then a type-
>=C2=A0 =C2=A0specific comparison is performed (see below) if the types = are equal
>=C2=A0 =C2=A0the algorithm continues with the next component.
>
> nit: there seems to be some missing punctuation or conjunction here. >
>=C2=A0 =C2=A0For all other component types, unless otherwise specified,= the
>=C2=A0 =C2=A0comparison is performed by comparing the component data as= a binary
>=C2=A0 =C2=A0string using the memcmp() function as defined by [ISO_IEC_= 9899].=C2=A0 For
>=C2=A0 =C2=A0strings with equal lengths the lowest string (memcmp) has = higher
>=C2=A0 =C2=A0precedence.=C2=A0 For strings of different lengths, the co= mmon prefix is
>=C2=A0 =C2=A0compared.=C2=A0 If the common prefix is not equal the stri= ng with the
>=C2=A0 =C2=A0lowest prefix has higher precedence.=C2=A0 If the common p= refix is equal,
>=C2=A0 =C2=A0the longest string is considered to have higher precedence= than the
>=C2=A0 =C2=A0shorter one.
>
> It is surprising to me that the comparison operator can return "n= ot-equal"
> for different encodings of a quantity that have the same semantic valu= e
> (viz my previous note about encoding flexibility).=C2=A0 That said, th= is
> procedure is well-defined and BGP speakers are not going to be re-enco= ding
> the NRLI values as they propagate, so I don't see an interop probl= em.
>
> Section 6
>
>=C2=A0 =C2=A0By default a Flow Specification NLRI MUST be validated suc= h that it
>=C2=A0 =C2=A0is considered feasible if and only if all of the below is = true:
>
> Perhaps "in the absence of explicit configuration otherwise,"= ; to more
> closely parallel the other case?
>
>=C2=A0 =C2=A0BGP implementations MUST also enforce that the AS_PATH att= ribute of a
>=C2=A0 =C2=A0route received via the External Border Gateway Protocol (e= BGP)
>=C2=A0 =C2=A0contains the neighboring AS in the left-most position of t= he AS_PATH
>=C2=A0 =C2=A0attribute.=C2=A0 While this rule is optional in the BGP sp= ecification, it
>=C2=A0 =C2=A0becomes necessary to enforce it for security reasons.
>
> nit: missing word (e.g., "necessary to enforce it here" or &= quot;necessary to
> enforce it in processing flow specifications").
>
>=C2=A0 =C2=A0The best-match unicast route may change over the time inde= pendently
>=C2=A0 =C2=A0of the Flow Specification NLRI.=C2=A0 Therefore, a revalid= ation of the
>=C2=A0 =C2=A0Flow Specification NLRI MUST be performed whenever unicast= routes
>=C2=A0 =C2=A0change.=C2=A0 Revalidation is defined as retesting that cl= ause a and
>=C2=A0 =C2=A0clause b above are true.
>
> IMPORTANT: Why does clause c not need to be retested?
>
>=C2=A0 =C2=A0The neighboring AS is the immediate destination of the tra= ffic
>=C2=A0 =C2=A0described by the Flow Specification.=C2=A0 If it requests = these flows to
>=C2=A0 =C2=A0be dropped, that request can be honored without concern th= at it
>=C2=A0 =C2=A0represents a denial of service in itself.=C2=A0 Supposedly= , the traffic is
>=C2=A0 =C2=A0being dropped by the downstream autonomous system, and the= re is no
>=C2=A0 =C2=A0added value in carrying the traffic to it.
>
> (This presumes that there is some integrity protection applied to the<= br> > received data, which might be worth making more explicit.)
> Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is= as if/
>
> Section 7
>
> Please be consistent about "ASN" vs. "AS" in Table= 2.
>
> Should the "traffic-action" and "traffic-marking" = actions list the encoded
> length for the reader's convenience?
>
> Section 7.1
>
>=C2=A0 =C2=A0The remaining 4 octets carry the maximum rate information = in IEEE
>=C2=A0 =C2=A0floating point [IEEE.754.1985] format, units being bytes p= er second.
>
> Thank you for being clear about the units!
>
> Section 7.2
>
> Is there anything to say about what time interval a non-integer packet= rate
> should be evaluated over?
>
> Section 7.3
>
>=C2=A0 =C2=A0o=C2=A0 T: Terminal Action (bit 47): When this bit is set,= the traffic
>=C2=A0 =C2=A0 =C2=A0 filtering engine will evaluate any subsequent Flow= Specifications
>=C2=A0 =C2=A0 =C2=A0 (as defined by the ordering procedure Section 5.1)= .=C2=A0 If not set,
>=C2=A0 =C2=A0 =C2=A0 the evaluation of the traffic filters stops when t= his Flow
>=C2=A0 =C2=A0 =C2=A0 Specification is evaluated.
>
> Just to check I'm reading this right: when the "terminal acti= on" bit is set
> to one, it is *not* the terminal action, and the action *is* the termi= nal
> action when the "terminal action" bit is set to zero?=C2=A0 = That sounds
> backwards to my intuition (and maybe others'?).
>
> Section 7.4
>
>=C2=A0 =C2=A0Interferes with: No other BGP Flow Specification Traffic F= iltering
>=C2=A0 =C2=A0Action in this document.
>
> Do the different possible 'type's for this 'sub-type' = interfere with each
> other?
>
> Section 7.6
>
>=C2=A0 =C2=A0Implementations should provide mechanisms that map an arbi= trary BGP
>=C2=A0 =C2=A0community value (normal or extended) to Traffic Filtering = Actions
>=C2=A0 =C2=A0that require different mappings in different systems in th= e network.
>
> nit(?): to my eye this reads better as "on different systems"= ; (vs. "in").
>
>=C2=A0 =C2=A0For instance, providing packets with a worse-than-best-eff= ort, per-
>=C2=A0 =C2=A0hop behavior is a functionality that is likely to be imple= mented
>
> nit: no comma after worst-than-best-effort.
>
> Section 7.7
>
>=C2=A0 =C2=A0other (e.g. there may be more than one conflicting traffic= -rate-bytes
>=C2=A0 =C2=A0Traffic Filtering Action associated with a single Flow
>=C2=A0 =C2=A0Specification).=C2=A0 Traffic Filtering Action interferenc= e has no impact
>
> Maybe we should revise the earlier text about "Interferes with: N= o other
> [...]" to be explicit that it *does* self-interfere.
>
>=C2=A0 =C2=A0behaviour (ie. match - replace - delete communities on adm= inistrative
>=C2=A0 =C2=A0boundaries).=C2=A0 See also Section 12.
>
> nit: could this parenthetical be expanded a little bit more?=C2=A0 I f= eel like
> it's expected to be common knowledge among the main readership and= so the
> current wording just serves as a trigger for this "well-known&quo= t; (but not to
> me) concept, as opposed to standing on its own.
>
> Section 8
>
> [side note: I'd love for us to eventually stop using "VPN&quo= t; for things that
> don't encrypt the data passing over them.=C2=A0 This doesn't s= eem like the right
> place to start, though.]
>
> Section 9
>
> Should either/both of these mechanisms be on or off by default?
>
> Section 12
>
> I'd consider mentioning again that some of the NRLI components won= 't work
> properly on fragmented traffic and that unexpected fragmentation can c= ause
> DoS.=C2=A0 (This is particularly relevant for IPv4, as opposed to IPv6= , where
> fragmentation can occur anywhere on the path.)
>
> Is it worth saying anything about how the RT-redirect actions can dire= ct
> traffic to an entity not expecting it (and, as such, potentially DoS t= hem)?
>
> It also struck me as noteworthy that we're letting DSCP values cre= ep out of
> a single administrative scope -- the filtering of inbound DSCP marking= s
> should probably be consistent with the traffic markings advertised to = that
> peer.=C2=A0 (There is perhaps also some "information leakage"= ; as to what
> semantics are assigned to given DSCP values within the network in ques= tion,
> but I find it hard to get too worked up about that, especially since t= he
> inter-AS relationship is inherently pretty trusted.)
>
>=C2=A0 =C2=A0As long as Flow Specifications are restricted to match the=
>=C2=A0 =C2=A0corresponding unicast routing paths for the relevant prefi= xes
>=C2=A0 =C2=A0(Section 6), the security characteristics of this proposal= are
>
> [There's an implicit "and both are received over trustworthy = channels" in
> here.=C2=A0 Perhaps it's okay to remain implicit, given how well-k= nown BGP's
> security properties are...]
>
>=C2=A0 =C2=A0Where the above mechanisms are not in place, this could op= en the door
>=C2=A0 =C2=A0to further denial-of-service attacks such as unwanted traf= fic
>=C2=A0 =C2=A0filtering, remarking or redirection.
>
> nit(?): I might just say "In particular, relaxing the validation = procedure
> could [...]".
>
>=C2=A0 =C2=A0additional filtering.=C2=A0 For example, the use of [RFC68= 11] to enhance
>=C2=A0 =C2=A0filtering within an AS confederation.
>
> nit: incomplete sentence.
>
>=C2=A0 =C2=A0Inter-provider routing is based on a web of trust.=C2=A0 N= eighboring
>=C2=A0 =C2=A0autonomous systems are trusted to advertise valid reachabi= lity
>=C2=A0 =C2=A0information.=C2=A0 If this trust model is violated, a neig= hboring
>=C2=A0 =C2=A0autonomous system may cause a denial-of-service attack by = advertising
>=C2=A0 =C2=A0reachability information for a given prefix for which it d= oes not
>
> I guess it's also a well-known attack that malicious neighbor coul= d also
> draw traffic to itself for snooping purposes without actually dropping= the
> traffic.=C2=A0 But I'm not sure if there are any flowspec-specific= considerations
> relating to that scenario.
>
>=C2=A0 =C2=A0provide service (unfiltered address space hijack).=C2=A0 S= ince validation
>=C2=A0 =C2=A0of the Flow Specification is tied to the announcement of t= he best
>=C2=A0 =C2=A0unicast route, this may also cause this validation to fail= and
>=C2=A0 =C2=A0consequently prevent Flow Specifications from being accept= ed by a
>=C2=A0 =C2=A0peer.=C2=A0 Possible mitigations are [RFC6811] and [RFC820= 5].
>
> nit: there's a lot of pronouns ("this") in here; it migh= t be worth
> disambiguating a couple.
>
>=C2=A0 =C2=A0Flow Specification BGP speakers (e.g. automated DDoS contr= ollers) not
>=C2=A0 =C2=A0properly programmed, algorithms that are not performing as= expected,
>=C2=A0 =C2=A0or simply rogue systems may announce unintended Flow Speci= fications,
>=C2=A0 =C2=A0send updates at a high rate or generate a high number of F= low
>=C2=A0 =C2=A0Specifications.=C2=A0 This may stress the receiving system= s, exceed their
>=C2=A0 =C2=A0maximum capacity or may lead to unwanted Traffic Filtering= Actions
>=C2=A0 =C2=A0being applied to flows.
>
> Is there any relevant guidance to give to receiving systems?
>
> Appendix A
>
> I don't know that just this one function is useful without some de= scription
> of what format of input it requires.=C2=A0 For example, if a.component= s and/or
> b.components have elements that evaluate to "false", the fir= st two checks
> could return incorrect results (the perhaps-more-obvious case where bo= th
> comp_a and comp_b are None cannot happen due to the nature of zip_long= est).
>
> Appendix B
>
>=C2=A0 =C2=A0 =C2=A0 Section 7 defines all Traffic Filtering Action Ext= ended
>=C2=A0 =C2=A0 =C2=A0 communities as transitive extended communities.=C2= =A0 [RFC5575] defined
>=C2=A0 =C2=A0 =C2=A0 the traffic-rate action to be non-transitive and d= id not define
>=C2=A0 =C2=A0 =C2=A0 the transitivity of the other Traffic Filtering Ac= tion communities
>=C2=A0 =C2=A0 =C2=A0 at all.
>
> I assume the consequences of changing a community from non-transitive = to
> transitive are well-known (but not to me) and that any operational
> considerations for mixed deployments are already stated somewhere prom= inent
> to someone working with BGP.=C2=A0 (Where is that?)
>
>=C2=A0 =C2=A0 =C2=A0 Section 7.7 contains general considerations on int= erfering traffic
>=C2=A0 =C2=A0 =C2=A0 actions.=C2=A0 Section 7.3 also cross-references t= his section.
>
> nit(?): the last "this section" refers to 7.7, not the locat= ion of the text
> I'm quoting from (Appendix B).=C2=A0 I misread it the first time.<= br> >
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

--000000000000d6e92f05a3f669ac-- From nobody Thu Apr 23 09:13:57 2020 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 764E23A0BB5; Thu, 23 Apr 2020 09:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 SRkwtOSk1w8N; Thu, 23 Apr 2020 09:13:51 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 001B83A0BB8; Thu, 23 Apr 2020 09:13:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Robert Raszuk'" , "'Christoph Loibl'" Cc: , , "'idr@ietf. org'" , "'Benjamin Kaduk'" , "'The IESG'" References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> <95C65325-EE11-42A1-8BAE-967BA2A0E448@tix.at> In-Reply-To: Date: Thu, 23 Apr 2020 12:13:37 -0400 Message-ID: <018a01d6198a$264d9c10$72e8d430$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018B_01D61968.9F3F5770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHio2zJAolkNix40BeFqEjeljO6MQHe5iniAmTLY46oS69sYA== Content-Language: en-us X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 16:13:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018B_01D61968.9F3F5770 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert. =20 =20 Good point on the RRs. We should leave the text as is. =20 I sent a higher level question to determine what Ben is concerned about. = =20 Sue =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, April 23, 2020 10:53 AM To: Christoph Loibl Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; idr@ietf. = org; Benjamin Kaduk; The IESG Subject: Re: [Idr] Benjamin Kaduk's Discuss on = draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) =20 =20 That suggestion is not right.=20 =20 They can be received via RRs etc ...=20 =20 I think the text is fine as is. I think Benjamin perhaps thought that = validation happens on ingress to the router. I am not sure if we want to = highlight the real meaning - I think it is already described in other = sections.=20 =20 Thx, R. =20 =20 On Thu, Apr 23, 2020 at 10:53 AM Christoph Loibl wrote: Hi Benjamin, Thanks for your review. I opened cases for all of the issues you raised = in the github repo: https://github.com/stoffi92/rfc5575bis The discuss item you raised is this: https://github.com/stoffi92/rfc5575bis/issues/184 To resolve this I suggest the following change to the document: I suggest to change it to the following (I hope that Robert and Sue can = also have a look if this is still correct to the desired behaviour): OLD: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. The validation procedure (Section 6) and Traffic Filtering Actions (Section 7) are the same as for IPv4. NEW: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. The validation procedure (Section 6) when Flow = Specifications are received from a remote CE are the same as for IPv4.=20 Traffic Filtering Actions (Section 7) are the same as for IPv4.. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 23.04.2020, at 02:42, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-idr-rfc5575bis-22: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > There might be a minor internal inconsistency to tidy up (or I might = be > misunderstanding things). Section 8 states that: >=20 > Contrary to the behavior specified for the non-VPN NLRI, Flow > Specifications are accepted by default, when received from remote PE > routers. >=20 > As far as I can tell, this is referring to the text in Section 6 where = (for > the non-VPN case) "By default a Flow Specification NLRI MUST be = validated > such that it is considered feasible if and only if all of the below is = true > [...]". But immediately following what I quote above is a statement = that > "the validation proceure (section 6) [...] [is] the same as for IPv4", = which > seems to be in conflict with this statement ("contrary to" vs. "the = same > as"). >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The Abstract is perhaps pushing the length limits appropriate for an > Abstract (vs. Introduction). >=20 > Abstract >=20 > Additionally, it defines two applications of that encoding format: > one that can be used to automate inter-domain coordination of = traffic > filtering, such as what is required in order to mitigate > (distributed) denial-of-service attacks, and a second application to >=20 > This makes me think of the DOTS WG (but it's far from clear that we = should > reference it in this text). >=20 > Section 1 >=20 > This document obsoletes "Dissemination of Flow Specification Rules" > [RFC5575], the differences can be found in Appendix B. This = document >=20 > nit: comma splice >=20 > A Flow Specification received from an external autonomous system = will > need to be validated against unicast routing before being accepted > (Section 6). The Flow Specification received from an internal BGP > peer within the same autonomous system [RFC4271] is assumed to have > been validated prior to transmission within the internal BGP (iBGP) > mesh of an autonomous system. If the aggregate traffic flow defined >=20 > (Just to check, there's no particular harm in also validating iBGP > flowspecs, just the extra computation burden of doing so, right?) >=20 > systems that are able to detect malicious traffic flows. When > automated systems are used, care should be taken to ensure their > correctness as well as the limitations of the systems that receive > and process the advertised Flow Specifications (see also Section = 12). >=20 > This seems to discuss making sure that the recipients of automated > information handle it robustly; is it also worth some considerations = on > robustness of generating such automated information (something akin to = a > circuit breaker that would shut off the source if it started producing > nonsensical output)? > Also, nit: I think I parse this as "care should be taken to ensure = [...] the > limitations of the systems that receive and process [flowspecs]", = which > doesn't quite seem like what was intended. >=20 > Section 4 >=20 > The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded = as > one or more 2-tuples of the form . It consists > of a 1- or 2-octet length field followed by a variable-length NLRI > value. The length is expressed in octets. >=20 > RFC 4760 only shows the one-octet length form; is there a good = reference for > the 2-octet length? (Or is it "new" with 5575?) >=20 > Section 4.2 >=20 > I think we should say something about how multi-byte values are = encoded, > especially given that we implicitly allow for different encodings of a = given > value (e.g., IP protocol could have padding, and small port numbers = don't > need to be encoded in 2 bytes). Even just making it more explicit = that > multiple encodings are allowed (and what the semantics are for any = such > "padding") would be worthwhile. Is there a maximum encoded length for > anything other than the constraints of the 2-bit 'len' field? > Interestingly, for DCSP we are much more strict -- why is the = strictness > needed there but not in general? Is this just to faithfully reproduce = RFC > 5575, as implied by the discussion in Appendix B? > (I would make this a DISCUSS point if I didn't think that we're acting = as if > we're required to preserve the RFC 5575 behavior.) >=20 > A NLRI value not encoded as specified in Section 4.2 is considered >=20 > This *is* Section 4.2; perhaps "specified here" or "specified below"? >=20 > Section 4.2.1.1, 4.2.1.2 >=20 > While I don't anticipate needing a future extension to numeric_op, = having > the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to = hamper any > future extensibility efforts. > (Similarly for the "Traffic-action" field in Section 7.3, and > "Traffic-marking" from Section 7.5.) >=20 > Section 4.2.2.3 >=20 > This component uses the Numeric Operator (numeric_op) described in > Section 4.2.1.1. Type 3 component values SHOULD be encoded as = single > octet (numeric_op len=3D00). >=20 > Is it well-defined how I would encode the value if I ignored the = SHOULD? > I, for one, am not sure what I would do... >=20 > Section 4.2.2.4, etc. >=20 > (I agree with my esteemed colleagues that hardcoding TCP and UDP as > "the only protocols with ports" is unnecessary.) >=20 > system is unable to locate the transport header. Different > implementations may or may not be able to decode the transport = header > in the presence of IP options or Encapsulating Security Payload = (ESP) > NULL [RFC4303] encryption. >=20 > If an implementation cannot decode the transport header does it treat = all > such packets as matching or not matching? >=20 > Section 4.2.2.7 >=20 > In case of the presence of the ICMP type (code) component only ICMP > packets can match the entire Flow Specification. The ICMP type >=20 > I'm not sure why the parenthetical is needed given that there's a = separate > NRLI type for "ICMP code". >=20 > Section 5.1 >=20 > component type. If the component types are the same, then a type- > specific comparison is performed (see below) if the types are equal > the algorithm continues with the next component. >=20 > nit: there seems to be some missing punctuation or conjunction here. >=20 > For all other component types, unless otherwise specified, the > comparison is performed by comparing the component data as a binary > string using the memcmp() function as defined by [ISO_IEC_9899]. = For > strings with equal lengths the lowest string (memcmp) has higher > precedence. For strings of different lengths, the common prefix is > compared. If the common prefix is not equal the string with the > lowest prefix has higher precedence. If the common prefix is equal, > the longest string is considered to have higher precedence than the > shorter one. >=20 > It is surprising to me that the comparison operator can return = "not-equal" > for different encodings of a quantity that have the same semantic = value > (viz my previous note about encoding flexibility). That said, this > procedure is well-defined and BGP speakers are not going to be = re-encoding > the NRLI values as they propagate, so I don't see an interop problem. >=20 > Section 6 >=20 > By default a Flow Specification NLRI MUST be validated such that it > is considered feasible if and only if all of the below is true: >=20 > Perhaps "in the absence of explicit configuration otherwise," to more > closely parallel the other case? >=20 > BGP implementations MUST also enforce that the AS_PATH attribute of = a > route received via the External Border Gateway Protocol (eBGP) > contains the neighboring AS in the left-most position of the AS_PATH > attribute. While this rule is optional in the BGP specification, it > becomes necessary to enforce it for security reasons. >=20 > nit: missing word (e.g., "necessary to enforce it here" or "necessary = to > enforce it in processing flow specifications"). >=20 > The best-match unicast route may change over the time independently > of the Flow Specification NLRI. Therefore, a revalidation of the > Flow Specification NLRI MUST be performed whenever unicast routes > change. Revalidation is defined as retesting that clause a and > clause b above are true. >=20 > IMPORTANT: Why does clause c not need to be retested? >=20 > The neighboring AS is the immediate destination of the traffic > described by the Flow Specification. If it requests these flows to > be dropped, that request can be honored without concern that it > represents a denial of service in itself. Supposedly, the traffic = is > being dropped by the downstream autonomous system, and there is no > added value in carrying the traffic to it. >=20 > (This presumes that there is some integrity protection applied to the > received data, which might be worth making more explicit.) > Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as = if/ >=20 > Section 7 >=20 > Please be consistent about "ASN" vs. "AS" in Table 2. >=20 > Should the "traffic-action" and "traffic-marking" actions list the = encoded > length for the reader's convenience? >=20 > Section 7.1 >=20 > The remaining 4 octets carry the maximum rate information in IEEE > floating point [IEEE.754.1985] format, units being bytes per second. >=20 > Thank you for being clear about the units! >=20 > Section 7.2 >=20 > Is there anything to say about what time interval a non-integer packet = rate > should be evaluated over? >=20 > Section 7.3 >=20 > o T: Terminal Action (bit 47): When this bit is set, the traffic > filtering engine will evaluate any subsequent Flow Specifications > (as defined by the ordering procedure Section 5.1).. If not set, > the evaluation of the traffic filters stops when this Flow > Specification is evaluated. >=20 > Just to check I'm reading this right: when the "terminal action" bit = is set > to one, it is *not* the terminal action, and the action *is* the = terminal > action when the "terminal action" bit is set to zero? That sounds > backwards to my intuition (and maybe others'?). >=20 > Section 7.4 >=20 > Interferes with: No other BGP Flow Specification Traffic Filtering > Action in this document. >=20 > Do the different possible 'type's for this 'sub-type' interfere with = each > other? >=20 > Section 7.6 >=20 > Implementations should provide mechanisms that map an arbitrary BGP > community value (normal or extended) to Traffic Filtering Actions > that require different mappings in different systems in the network. >=20 > nit(?): to my eye this reads better as "on different systems" (vs. = "in"). >=20 > For instance, providing packets with a worse-than-best-effort, per- > hop behavior is a functionality that is likely to be implemented >=20 > nit: no comma after worst-than-best-effort. >=20 > Section 7.7 >=20 > other (e.g. there may be more than one conflicting = traffic-rate-bytes > Traffic Filtering Action associated with a single Flow > Specification). Traffic Filtering Action interference has no impact >=20 > Maybe we should revise the earlier text about "Interferes with: No = other > [...]" to be explicit that it *does* self-interfere. >=20 > behaviour (ie. match - replace - delete communities on = administrative > boundaries). See also Section 12. >=20 > nit: could this parenthetical be expanded a little bit more? I feel = like > it's expected to be common knowledge among the main readership and so = the > current wording just serves as a trigger for this "well-known" (but = not to > me) concept, as opposed to standing on its own. >=20 > Section 8 >=20 > [side note: I'd love for us to eventually stop using "VPN" for things = that > don't encrypt the data passing over them. This doesn't seem like the = right > place to start, though.] >=20 > Section 9 >=20 > Should either/both of these mechanisms be on or off by default? >=20 > Section 12 >=20 > I'd consider mentioning again that some of the NRLI components won't = work > properly on fragmented traffic and that unexpected fragmentation can = cause > DoS. (This is particularly relevant for IPv4, as opposed to IPv6, = where > fragmentation can occur anywhere on the path.) >=20 > Is it worth saying anything about how the RT-redirect actions can = direct > traffic to an entity not expecting it (and, as such, potentially DoS = them)? >=20 > It also struck me as noteworthy that we're letting DSCP values creep = out of > a single administrative scope -- the filtering of inbound DSCP = markings > should probably be consistent with the traffic markings advertised to = that > peer. (There is perhaps also some "information leakage" as to what > semantics are assigned to given DSCP values within the network in = question, > but I find it hard to get too worked up about that, especially since = the > inter-AS relationship is inherently pretty trusted.) >=20 > As long as Flow Specifications are restricted to match the > corresponding unicast routing paths for the relevant prefixes > (Section 6), the security characteristics of this proposal are >=20 > [There's an implicit "and both are received over trustworthy channels" = in > here. Perhaps it's okay to remain implicit, given how well-known = BGP's > security properties are...] >=20 > Where the above mechanisms are not in place, this could open the = door > to further denial-of-service attacks such as unwanted traffic > filtering, remarking or redirection. >=20 > nit(?): I might just say "In particular, relaxing the validation = procedure > could [...]". >=20 > additional filtering. For example, the use of [RFC6811] to enhance > filtering within an AS confederation. >=20 > nit: incomplete sentence. >=20 > Inter-provider routing is based on a web of trust. Neighboring > autonomous systems are trusted to advertise valid reachability > information. If this trust model is violated, a neighboring > autonomous system may cause a denial-of-service attack by = advertising > reachability information for a given prefix for which it does not >=20 > I guess it's also a well-known attack that malicious neighbor could = also > draw traffic to itself for snooping purposes without actually dropping = the > traffic. But I'm not sure if there are any flowspec-specific = considerations > relating to that scenario. >=20 > provide service (unfiltered address space hijack). Since validation > of the Flow Specification is tied to the announcement of the best > unicast route, this may also cause this validation to fail and > consequently prevent Flow Specifications from being accepted by a > peer. Possible mitigations are [RFC6811] and [RFC8205]. >=20 > nit: there's a lot of pronouns ("this") in here; it might be worth > disambiguating a couple. >=20 > Flow Specification BGP speakers (e.g. automated DDoS controllers) = not > properly programmed, algorithms that are not performing as expected, > or simply rogue systems may announce unintended Flow Specifications, > send updates at a high rate or generate a high number of Flow > Specifications. This may stress the receiving systems, exceed their > maximum capacity or may lead to unwanted Traffic Filtering Actions > being applied to flows. >=20 > Is there any relevant guidance to give to receiving systems? >=20 > Appendix A >=20 > I don't know that just this one function is useful without some = description > of what format of input it requires. For example, if a.components = and/or > b.components have elements that evaluate to "false", the first two = checks > could return incorrect results (the perhaps-more-obvious case where = both > comp_a and comp_b are None cannot happen due to the nature of = zip_longest). >=20 > Appendix B >=20 > Section 7 defines all Traffic Filtering Action Extended > communities as transitive extended communities. [RFC5575] = defined > the traffic-rate action to be non-transitive and did not define > the transitivity of the other Traffic Filtering Action = communities > at all. >=20 > I assume the consequences of changing a community from non-transitive = to > transitive are well-known (but not to me) and that any operational > considerations for mixed deployments are already stated somewhere = prominent > to someone working with BGP. (Where is that?) >=20 > Section 7.7 contains general considerations on interfering = traffic > actions. Section 7.3 also cross-references this section. >=20 > nit(?): the last "this section" refers to 7.7, not the location of the = text > I'm quoting from (Appendix B). I misread it the first time. >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_018B_01D61968.9F3F5770 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert.=C2=A0

 

Good point on the RRs. =C2=A0=C2=A0We should leave the text as = is.

 

I sent a higher level question to determine what Ben is concerned = about.

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert = Raszuk
Sent: Thursday, April 23, 2020 10:53 AM
To: = Christoph Loibl
Cc: draft-ietf-idr-rfc5575bis@ietf.org; = idr-chairs@ietf.org; idr@ietf. org; Benjamin Kaduk; The = IESG
Subject: Re: [Idr] Benjamin Kaduk's Discuss on = draft-ietf-idr-rfc5575bis-22: (with DISCUSS and = COMMENT)

 

 

That = suggestion is not right. 

 

They can be received via RRs etc = ... 

 

I = think the text is fine as is. I think Benjamin perhaps thought that = validation happens on ingress to the router. I am not sure if we = want to highlight the real meaning - I think it is already described in = other sections. 

 

Thx,

R.

 

 

On = Thu, Apr 23, 2020 at 10:53 AM Christoph Loibl <c@tix.at> = wrote:

Hi Benjamin,

Thanks for your = review. I opened cases for all of the issues you raised in the github = repo:

        https://github.com/stoffi92/rfc5575bis

The = discuss item you raised is this:

        https://github.com/stoffi92/rfc5575bis/issues/184
To resolve this I suggest the following change to the = document:

I suggest to change it to the following (I hope that = Robert and Sue can also have a look if this is still correct to the = desired behaviour):

OLD:
   Contrary to the behavior = specified for the non-VPN NLRI, Flow
   Specifications are = accepted by default, when received from remote PE
  =  routers.

   The validation procedure (Section 6) = and Traffic Filtering Actions
   (Section 7) are the same = as for IPv4.

NEW:
   Contrary to the behavior = specified for the non-VPN NLRI, Flow
   Specifications are = accepted by default, when received from remote PE
  =  routers. The validation procedure (Section 6) when Flow = Specifications
   are received from a remote CE are the = same as for IPv4.

   Traffic Filtering Actions = (Section 7) are the same as for IPv4..


Cheers = Christoph

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



> On = 23.04.2020, at 02:42, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
>
> = Benjamin Kaduk has entered the following ballot position for
> = draft-ietf-idr-rfc5575bis-22: Discuss
>
> When responding, = please keep the subject line intact and reply to all
> email = addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
> = Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The document, along with other = ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575= bis/
>
>
>
> = ----------------------------------------------------------------------> DISCUSS:
> = ---------------------------------------------------------------------->
> There might be a minor internal inconsistency to tidy up = (or I might be
> misunderstanding things).  Section 8 states = that:
>
>   Contrary to the behavior specified = for the non-VPN NLRI, Flow
>   Specifications are = accepted by default, when received from remote PE
>  =  routers.
>
> As far as I can tell, this is referring = to the text in Section 6 where (for
> the non-VPN case) "By = default a Flow Specification NLRI MUST be validated
> such that it = is considered feasible if and only if all of the below is true
> = [...]".  But immediately following what I quote above is a = statement that
> "the validation proceure (section 6) [...] = [is] the same as for IPv4", which
> seems to be in conflict = with this statement ("contrary to" vs. "the same
> = as").
>
>
> = ----------------------------------------------------------------------> COMMENT:
> = ---------------------------------------------------------------------->
> The Abstract is perhaps pushing the length limits = appropriate for an
> Abstract (vs. Introduction).
>
> = Abstract
>
>   Additionally, it defines two = applications of that encoding format:
>   one that can = be used to automate inter-domain coordination of traffic
>  =  filtering, such as what is required in order to = mitigate
>   (distributed) denial-of-service attacks, = and a second application to
>
> This makes me think of the = DOTS WG (but it's far from clear that we should
> reference it in = this text).
>
> Section 1
>
>   This = document obsoletes "Dissemination of Flow Specification = Rules"
>   [RFC5575], the differences can be found = in Appendix B.  This document
>
> nit: comma = splice
>
>   A Flow Specification received from = an external autonomous system will
>   need to be = validated against unicast routing before being accepted
>  =  (Section 6).  The Flow Specification received from an = internal BGP
>   peer within the same autonomous system = [RFC4271] is assumed to have
>   been validated prior to = transmission within the internal BGP (iBGP)
>   mesh of = an autonomous system.  If the aggregate traffic flow = defined
>
> (Just to check, there's no particular harm in = also validating iBGP
> flowspecs, just the extra computation = burden of doing so, right?)
>
>   systems that = are able to detect malicious traffic flows.  When
>  =  automated systems are used, care should be taken to ensure = their
>   correctness as well as the limitations of the = systems that receive
>   and process the advertised Flow = Specifications (see also Section 12).
>
> This seems to = discuss making sure that the recipients of automated
> information = handle it robustly; is it also worth some considerations on
> = robustness of generating such automated information (something akin to = a
> circuit breaker that would shut off the source if it started = producing
> nonsensical output)?
> Also, nit: I think I = parse this as "care should be taken to ensure [...] the
> = limitations of the systems that receive and process [flowspecs]", = which
> doesn't quite seem like what was intended.
> =
> Section 4
>
>   The NLRI field of the = MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
>   one = or more 2-tuples of the form <length, NLRI value>.  It = consists
>   of a 1- or 2-octet length field followed by = a variable-length NLRI
>   value.  The length is = expressed in octets.
>
> RFC 4760 only shows the one-octet = length form; is there a good reference for
> the 2-octet = length?  (Or is it "new" with 5575?)
>
> = Section 4.2
>
> I think we should say something about how = multi-byte values are encoded,
> especially given that we = implicitly allow for different encodings of a given
> value (e.g., = IP protocol could have padding, and small port numbers don't
> = need to be encoded in 2 bytes).  Even just making it more explicit = that
> multiple encodings are allowed (and what the semantics are = for any such
> "padding") would be worthwhile.  Is = there a maximum encoded length for
> anything other than the = constraints of the 2-bit 'len' field?
> Interestingly, for DCSP we = are much more strict -- why is the strictness
> needed there but = not in general?  Is this just to faithfully reproduce RFC
> = 5575, as implied by the discussion in Appendix B?
> (I would make = this a DISCUSS point if I didn't think that we're acting as if
> = we're required to preserve the RFC 5575 behavior.)
> =
>   A NLRI value not encoded as specified in Section = 4.2 is considered
>
> This *is* Section 4.2; perhaps = "specified here" or "specified below"?
> =
> Section 4.2.1.1, 4.2.1.2
>
> While I don't = anticipate needing a future extension to numeric_op, having
> the = '0' field only be "SHOULD be set to 0" (vs. "MUST") = seems to hamper any
> future extensibility efforts.
> = (Similarly for the "Traffic-action" field in Section 7.3, = and
> "Traffic-marking" from Section 7.5.)
> =
> Section 4.2.2.3
>
>   This component = uses the Numeric Operator (numeric_op) described in
>  =  Section 4.2.1.1.  Type 3 component values SHOULD be encoded = as single
>   octet (numeric_op len=3D00).
> =
> Is it well-defined how I would encode the value if I ignored = the SHOULD?
> I, for one, am not sure what I would do...
> =
> Section 4.2.2.4, etc.
>
> (I agree with my = esteemed colleagues that hardcoding TCP and UDP as
> "the = only protocols with ports" is unnecessary.)
>
>  =  system is unable to locate the transport header.  = Different
>   implementations may or may not be able to = decode the transport header
>   in the presence of IP = options or Encapsulating Security Payload (ESP)
>   NULL = [RFC4303] encryption.
>
> If an implementation cannot = decode the transport header does it treat all
> such packets as = matching or not matching?
>
> Section 4.2.2.7
> =
>   In case of the presence of the ICMP type (code) = component only ICMP
>   packets can match the entire = Flow Specification.  The ICMP type
>
> I'm not sure = why the parenthetical is needed given that there's a separate
> = NRLI type for "ICMP code".
>
> Section = 5.1
>
>   component type.  If the component = types are the same, then a type-
>   specific comparison = is performed (see below) if the types are equal
>   the = algorithm continues with the next component.
>
> nit: there = seems to be some missing punctuation or conjunction here.
> =
>   For all other component types, unless otherwise = specified, the
>   comparison is performed by comparing = the component data as a binary
>   string using the = memcmp() function as defined by [ISO_IEC_9899].  For
>  =  strings with equal lengths the lowest string (memcmp) has = higher
>   precedence.  For strings of different = lengths, the common prefix is
>   compared.  If the = common prefix is not equal the string with the
>  =  lowest prefix has higher precedence.  If the common prefix is = equal,
>   the longest string is considered to have = higher precedence than the
>   shorter one.
> =
> It is surprising to me that the comparison operator can return = "not-equal"
> for different encodings of a quantity that = have the same semantic value
> (viz my previous note about = encoding flexibility).  That said, this
> procedure is = well-defined and BGP speakers are not going to be re-encoding
> = the NRLI values as they propagate, so I don't see an interop = problem.
>
> Section 6
>
>   By = default a Flow Specification NLRI MUST be validated such that = it
>   is considered feasible if and only if all of the = below is true:
>
> Perhaps "in the absence of explicit = configuration otherwise," to more
> closely parallel the = other case?
>
>   BGP implementations MUST also = enforce that the AS_PATH attribute of a
>   route = received via the External Border Gateway Protocol (eBGP)
>  =  contains the neighboring AS in the left-most position of the = AS_PATH
>   attribute.  While this rule is optional = in the BGP specification, it
>   becomes necessary to = enforce it for security reasons.
>
> nit: missing word = (e.g., "necessary to enforce it here" or "necessary = to
> enforce it in processing flow specifications").
> =
>   The best-match unicast route may change over the = time independently
>   of the Flow Specification = NLRI.  Therefore, a revalidation of the
>   Flow = Specification NLRI MUST be performed whenever unicast = routes
>   change.  Revalidation is defined as = retesting that clause a and
>   clause b above are = true.
>
> IMPORTANT: Why does clause c not need to be = retested?
>
>   The neighboring AS is the = immediate destination of the traffic
>   described by = the Flow Specification.  If it requests these flows = to
>   be dropped, that request can be honored without = concern that it
>   represents a denial of service in = itself.  Supposedly, the traffic is
>   being = dropped by the downstream autonomous system, and there is = no
>   added value in carrying the traffic to = it.
>
> (This presumes that there is some integrity = protection applied to the
> received data, which might be worth = making more explicit.)
> Also, nit: I'd suggest s/Supposedly,/The = reasoning is that this is as if/
>
> Section 7
> =
> Please be consistent about "ASN" vs. "AS" = in Table 2.
>
> Should the "traffic-action" and = "traffic-marking" actions list the encoded
> length for = the reader's convenience?
>
> Section 7.1
> =
>   The remaining 4 octets carry the maximum rate = information in IEEE
>   floating point [IEEE.754.1985] = format, units being bytes per second.
>
> Thank you for = being clear about the units!
>
> Section 7.2
> =
> Is there anything to say about what time interval a non-integer = packet rate
> should be evaluated over?
>
> Section = 7.3
>
>   o  T: Terminal Action (bit 47): = When this bit is set, the traffic
>      filtering = engine will evaluate any subsequent Flow Specifications
>  =     (as defined by the ordering procedure Section 5.1)..  = If not set,
>      the evaluation of the traffic = filters stops when this Flow
>      Specification = is evaluated.
>
> Just to check I'm reading this right: = when the "terminal action" bit is set
> to one, it is = *not* the terminal action, and the action *is* the terminal
> = action when the "terminal action" bit is set to zero?  = That sounds
> backwards to my intuition (and maybe = others'?).
>
> Section 7.4
>
>  =  Interferes with: No other BGP Flow Specification Traffic = Filtering
>   Action in this document.
>
> = Do the different possible 'type's for this 'sub-type' interfere with = each
> other?
>
> Section 7.6
>
>  =  Implementations should provide mechanisms that map an arbitrary = BGP
>   community value (normal or extended) to Traffic = Filtering Actions
>   that require different mappings in = different systems in the network.
>
> nit(?): to my eye = this reads better as "on different systems" (vs. = "in").
>
>   For instance, providing = packets with a worse-than-best-effort, per-
>   hop = behavior is a functionality that is likely to be implemented
> =
> nit: no comma after worst-than-best-effort.
>
> = Section 7.7
>
>   other (e.g. there may be more = than one conflicting traffic-rate-bytes
>   Traffic = Filtering Action associated with a single Flow
>  =  Specification).  Traffic Filtering Action interference has no = impact
>
> Maybe we should revise the earlier text about = "Interferes with: No other
> [...]" to be explicit that = it *does* self-interfere.
>
>   behaviour (ie. = match - replace - delete communities on administrative
>  =  boundaries).  See also Section 12.
>
> nit: = could this parenthetical be expanded a little bit more?  I feel = like
> it's expected to be common knowledge among the main = readership and so the
> current wording just serves as a trigger = for this "well-known" (but not to
> me) concept, as = opposed to standing on its own.
>
> Section 8
> =
> [side note: I'd love for us to eventually stop using = "VPN" for things that
> don't encrypt the data passing = over them.  This doesn't seem like the right
> place to = start, though.]
>
> Section 9
>
> Should = either/both of these mechanisms be on or off by default?
> =
> Section 12
>
> I'd consider mentioning again that = some of the NRLI components won't work
> properly on fragmented = traffic and that unexpected fragmentation can cause
> DoS.  = (This is particularly relevant for IPv4, as opposed to IPv6, = where
> fragmentation can occur anywhere on the path.)
> =
> Is it worth saying anything about how the RT-redirect actions = can direct
> traffic to an entity not expecting it (and, as such, = potentially DoS them)?
>
> It also struck me as noteworthy = that we're letting DSCP values creep out of
> a single = administrative scope -- the filtering of inbound DSCP markings
> = should probably be consistent with the traffic markings advertised to = that
> peer.  (There is perhaps also some "information = leakage" as to what
> semantics are assigned to given DSCP = values within the network in question,
> but I find it hard to get = too worked up about that, especially since the
> inter-AS = relationship is inherently pretty trusted.)
>
>  =  As long as Flow Specifications are restricted to match = the
>   corresponding unicast routing paths for the = relevant prefixes
>   (Section 6), the security = characteristics of this proposal are
>
> [There's an = implicit "and both are received over trustworthy channels" = in
> here.  Perhaps it's okay to remain implicit, given how = well-known BGP's
> security properties are...]
> =
>   Where the above mechanisms are not in place, this = could open the door
>   to further denial-of-service = attacks such as unwanted traffic
>   filtering, = remarking or redirection.
>
> nit(?): I might just say = "In particular, relaxing the validation procedure
> could = [...]".
>
>   additional filtering.  = For example, the use of [RFC6811] to enhance
>  =  filtering within an AS confederation.
>
> nit: = incomplete sentence.
>
>   Inter-provider routing = is based on a web of trust.  Neighboring
>  =  autonomous systems are trusted to advertise valid = reachability
>   information.  If this trust model = is violated, a neighboring
>   autonomous system may = cause a denial-of-service attack by advertising
>  =  reachability information for a given prefix for which it does = not
>
> I guess it's also a well-known attack that = malicious neighbor could also
> draw traffic to itself for = snooping purposes without actually dropping the
> traffic.  = But I'm not sure if there are any flowspec-specific = considerations
> relating to that scenario.
>
>  =  provide service (unfiltered address space hijack).  Since = validation
>   of the Flow Specification is tied to the = announcement of the best
>   unicast route, this may = also cause this validation to fail and
>   consequently = prevent Flow Specifications from being accepted by a
>  =  peer.  Possible mitigations are [RFC6811] and = [RFC8205].
>
> nit: there's a lot of pronouns = ("this") in here; it might be worth
> disambiguating a = couple.
>
>   Flow Specification BGP speakers = (e.g. automated DDoS controllers) not
>   properly = programmed, algorithms that are not performing as = expected,
>   or simply rogue systems may announce = unintended Flow Specifications,
>   send updates at a = high rate or generate a high number of Flow
>  =  Specifications.  This may stress the receiving systems, = exceed their
>   maximum capacity or may lead to = unwanted Traffic Filtering Actions
>   being applied to = flows.
>
> Is there any relevant guidance to give to = receiving systems?
>
> Appendix A
>
> I don't = know that just this one function is useful without some = description
> of what format of input it requires.  For = example, if a.components and/or
> b.components have elements that = evaluate to "false", the first two checks
> could return = incorrect results (the perhaps-more-obvious case where both
> = comp_a and comp_b are None cannot happen due to the nature of = zip_longest).
>
> Appendix B
>
>    =   Section 7 defines all Traffic Filtering Action = Extended
>      communities as transitive extended = communities.  [RFC5575] defined
>      the = traffic-rate action to be non-transitive and did not = define
>      the transitivity of the other Traffic = Filtering Action communities
>      at all.
> =
> I assume the consequences of changing a community from = non-transitive to
> transitive are well-known (but not to me) and = that any operational
> considerations for mixed deployments are = already stated somewhere prominent
> to someone working with = BGP.  (Where is that?)
>
>      Section = 7.7 contains general considerations on interfering traffic
>  =     actions.  Section 7.3 also cross-references this = section.
>
> nit(?): the last "this section" = refers to 7.7, not the location of the text
> I'm quoting from = (Appendix B).  I misread it the first time.
>
> =
>
> = _______________________________________________
> Idr mailing = list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

------=_NextPart_000_018B_01D61968.9F3F5770-- From nobody Thu Apr 23 12:20:00 2020 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 4D1103A1260; Thu, 23 Apr 2020 12:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 km3lUH8gQkad; Thu, 23 Apr 2020 12:19:55 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 00D4A3A125F; Thu, 23 Apr 2020 12:19:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , , References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> In-Reply-To: <158760254746.26942.2049621502527864651@ietfa.amsl.com> Date: Thu, 23 Apr 2020 15:19:45 -0400 Message-ID: <020d01d619a4$26f91f80$74eb5e80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHio2zJAolkNix40BeFqEjeljO6Maht+ugQ Content-Language: en-us X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 19:19:59 -0000 Ben: First of all thank you for your detailed review. We really appreciate this detailed review during a revision of a deployed protocol. Christoph has added each of your comments to the github repository for this draft. Two clarifying questions that need pulling out besides your DISCUSS. (see Robert's comment on the RR implication on the DISCUSS). I'm pulling these to the front for ease of responding to the Section 12: Your comment: I'd consider mentioning again that some of the NRLI components won't work properly on fragmented traffic and that unexpected fragmentation can cause DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where fragmentation can occur anywhere on the path.) -------- Clarifying questions: The RFC5575bis (and RFC5575) is simply providing filters for a firewall function. Is there an RFC that suggestions the appropriate cautions for firewall filters.? If so, could we mention that people implementing RFC5575bis should simply be aware of BCPs regarding firewalls regarding DoS? Your comment: Is it worth saying anything about how the RT-redirect actions can direct traffic to an entity not expecting it (and, as such, potentially DoS them)? Clarifying question Redirect also occurs with the firewalls? RFC5575bis is simply enabling that function with multicast of the Filter prefixes. Is there a BCP regarding firewalls that use redirect? I have been trying to monitor the new threats discussion. Your comment: :It also struck me as noteworthy that we're letting DSCP values creep out of a single administrative scope -- the filtering of inbound DSCP markings should probably be consistent with the traffic markings advertised to that peer." The DSCP markings seem to cross boundaries with MPLS. If there is a BCP regarding DSCP marking, should we reference this as well? Thank you for your careful review. Susan Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Benjamin Kaduk via Datatracker Sent: Wednesday, April 22, 2020 8:42 PM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There might be a minor internal inconsistency to tidy up (or I might be misunderstanding things). Section 8 states that: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. As far as I can tell, this is referring to the text in Section 6 where (for the non-VPN case) "By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true [...]". But immediately following what I quote above is a statement that "the validation proceure (section 6) [...] [is] the same as for IPv4", which seems to be in conflict with this statement ("contrary to" vs. "the same as"). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract is perhaps pushing the length limits appropriate for an Abstract (vs. Introduction). Abstract Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to This makes me think of the DOTS WG (but it's far from clear that we should reference it in this text). Section 1 This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], the differences can be found in Appendix B. This document nit: comma splice A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted (Section 6). The Flow Specification received from an internal BGP peer within the same autonomous system [RFC4271] is assumed to have been validated prior to transmission within the internal BGP (iBGP) mesh of an autonomous system. If the aggregate traffic flow defined (Just to check, there's no particular harm in also validating iBGP flowspecs, just the extra computation burden of doing so, right?) systems that are able to detect malicious traffic flows. When automated systems are used, care should be taken to ensure their correctness as well as the limitations of the systems that receive and process the advertised Flow Specifications (see also Section 12). This seems to discuss making sure that the recipients of automated information handle it robustly; is it also worth some considerations on robustness of generating such automated information (something akin to a circuit breaker that would shut off the source if it started producing nonsensical output)? Also, nit: I think I parse this as "care should be taken to ensure [...] the limitations of the systems that receive and process [flowspecs]", which doesn't quite seem like what was intended. Section 4 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as one or more 2-tuples of the form . It consists of a 1- or 2-octet length field followed by a variable-length NLRI value. The length is expressed in octets. RFC 4760 only shows the one-octet length form; is there a good reference for the 2-octet length? (Or is it "new" with 5575?) Section 4.2 I think we should say something about how multi-byte values are encoded, especially given that we implicitly allow for different encodings of a given value (e.g., IP protocol could have padding, and small port numbers don't need to be encoded in 2 bytes). Even just making it more explicit that multiple encodings are allowed (and what the semantics are for any such "padding") would be worthwhile. Is there a maximum encoded length for anything other than the constraints of the 2-bit 'len' field? Interestingly, for DCSP we are much more strict -- why is the strictness needed there but not in general? Is this just to faithfully reproduce RFC 5575, as implied by the discussion in Appendix B? (I would make this a DISCUSS point if I didn't think that we're acting as if we're required to preserve the RFC 5575 behavior.) A NLRI value not encoded as specified in Section 4.2 is considered This *is* Section 4.2; perhaps "specified here" or "specified below"? Section 4.2.1.1, 4.2.1.2 While I don't anticipate needing a future extension to numeric_op, having the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper any future extensibility efforts. (Similarly for the "Traffic-action" field in Section 7.3, and "Traffic-marking" from Section 7.5.) Section 4.2.2.3 This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 3 component values SHOULD be encoded as single octet (numeric_op len=00). Is it well-defined how I would encode the value if I ignored the SHOULD? I, for one, am not sure what I would do... Section 4.2.2.4, etc. (I agree with my esteemed colleagues that hardcoding TCP and UDP as "the only protocols with ports" is unnecessary.) system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. If an implementation cannot decode the transport header does it treat all such packets as matching or not matching? Section 4.2.2.7 In case of the presence of the ICMP type (code) component only ICMP packets can match the entire Flow Specification. The ICMP type I'm not sure why the parenthetical is needed given that there's a separate NRLI type for "ICMP code". Section 5.1 component type. If the component types are the same, then a type- specific comparison is performed (see below) if the types are equal the algorithm continues with the next component. nit: there seems to be some missing punctuation or conjunction here. For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. It is surprising to me that the comparison operator can return "not-equal" for different encodings of a quantity that have the same semantic value (viz my previous note about encoding flexibility). That said, this procedure is well-defined and BGP speakers are not going to be re-encoding the NRLI values as they propagate, so I don't see an interop problem. Section 6 By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true: Perhaps "in the absence of explicit configuration otherwise," to more closely parallel the other case? BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it for security reasons. nit: missing word (e.g., "necessary to enforce it here" or "necessary to enforce it in processing flow specifications"). The best-match unicast route may change over the time independently of the Flow Specification NLRI. Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change. Revalidation is defined as retesting that clause a and clause b above are true. IMPORTANT: Why does clause c not need to be retested? The neighboring AS is the immediate destination of the traffic described by the Flow Specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it. (This presumes that there is some integrity protection applied to the received data, which might be worth making more explicit.) Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as if/ Section 7 Please be consistent about "ASN" vs. "AS" in Table 2. Should the "traffic-action" and "traffic-marking" actions list the encoded length for the reader's convenience? Section 7.1 The remaining 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. Thank you for being clear about the units! Section 7.2 Is there anything to say about what time interval a non-integer packet rate should be evaluated over? Section 7.3 o T: Terminal Action (bit 47): When this bit is set, the traffic filtering engine will evaluate any subsequent Flow Specifications (as defined by the ordering procedure Section 5.1). If not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated. Just to check I'm reading this right: when the "terminal action" bit is set to one, it is *not* the terminal action, and the action *is* the terminal action when the "terminal action" bit is set to zero? That sounds backwards to my intuition (and maybe others'?). Section 7.4 Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. Do the different possible 'type's for this 'sub-type' interfere with each other? Section 7.6 Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to Traffic Filtering Actions that require different mappings in different systems in the network. nit(?): to my eye this reads better as "on different systems" (vs. "in"). For instance, providing packets with a worse-than-best-effort, per- hop behavior is a functionality that is likely to be implemented nit: no comma after worst-than-best-effort. Section 7.7 other (e.g. there may be more than one conflicting traffic-rate-bytes Traffic Filtering Action associated with a single Flow Specification). Traffic Filtering Action interference has no impact Maybe we should revise the earlier text about "Interferes with: No other [...]" to be explicit that it *does* self-interfere. behaviour (ie. match - replace - delete communities on administrative boundaries). See also Section 12. nit: could this parenthetical be expanded a little bit more? I feel like it's expected to be common knowledge among the main readership and so the current wording just serves as a trigger for this "well-known" (but not to me) concept, as opposed to standing on its own. Section 8 [side note: I'd love for us to eventually stop using "VPN" for things that don't encrypt the data passing over them. This doesn't seem like the right place to start, though.] Section 9 Should either/both of these mechanisms be on or off by default? Section 12 I'd consider mentioning again that some of the NRLI components won't work properly on fragmented traffic and that unexpected fragmentation can cause DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where fragmentation can occur anywhere on the path.) Is it worth saying anything about how the RT-redirect actions can direct traffic to an entity not expecting it (and, as such, potentially DoS them)? It also struck me as noteworthy that we're letting DSCP values creep out of a single administrative scope -- the filtering of inbound DSCP markings should probably be consistent with the traffic markings advertised to that peer. (There is perhaps also some "information leakage" as to what semantics are assigned to given DSCP values within the network in question, but I find it hard to get too worked up about that, especially since the inter-AS relationship is inherently pretty trusted.) As long as Flow Specifications are restricted to match the corresponding unicast routing paths for the relevant prefixes (Section 6), the security characteristics of this proposal are [There's an implicit "and both are received over trustworthy channels" in here. Perhaps it's okay to remain implicit, given how well-known BGP's security properties are...] Where the above mechanisms are not in place, this could open the door to further denial-of-service attacks such as unwanted traffic filtering, remarking or redirection. nit(?): I might just say "In particular, relaxing the validation procedure could [...]". additional filtering. For example, the use of [RFC6811] to enhance filtering within an AS confederation. nit: incomplete sentence. Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not I guess it's also a well-known attack that malicious neighbor could also draw traffic to itself for snooping purposes without actually dropping the traffic. But I'm not sure if there are any flowspec-specific considerations relating to that scenario. provide service (unfiltered address space hijack). Since validation of the Flow Specification is tied to the announcement of the best unicast route, this may also cause this validation to fail and consequently prevent Flow Specifications from being accepted by a peer. Possible mitigations are [RFC6811] and [RFC8205]. nit: there's a lot of pronouns ("this") in here; it might be worth disambiguating a couple. Flow Specification BGP speakers (e.g. automated DDoS controllers) not properly programmed, algorithms that are not performing as expected, or simply rogue systems may announce unintended Flow Specifications, send updates at a high rate or generate a high number of Flow Specifications. This may stress the receiving systems, exceed their maximum capacity or may lead to unwanted Traffic Filtering Actions being applied to flows. Is there any relevant guidance to give to receiving systems? Appendix A I don't know that just this one function is useful without some description of what format of input it requires. For example, if a.components and/or b.components have elements that evaluate to "false", the first two checks could return incorrect results (the perhaps-more-obvious case where both comp_a and comp_b are None cannot happen due to the nature of zip_longest). Appendix B Section 7 defines all Traffic Filtering Action Extended communities as transitive extended communities. [RFC5575] defined the traffic-rate action to be non-transitive and did not define the transitivity of the other Traffic Filtering Action communities at all. I assume the consequences of changing a community from non-transitive to transitive are well-known (but not to me) and that any operational considerations for mixed deployments are already stated somewhere prominent to someone working with BGP. (Where is that?) Section 7.7 contains general considerations on interfering traffic actions. Section 7.3 also cross-references this section. nit(?): the last "this section" refers to 7.7, not the location of the text I'm quoting from (Appendix B). I misread it the first time. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Apr 23 12:28:36 2020 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 0B40A3A1273; Thu, 23 Apr 2020 12:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 1eD4OcqiWaiT; Thu, 23 Apr 2020 12:28:31 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 E9E953A125F; Thu, 23 Apr 2020 12:28:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , , References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> In-Reply-To: <158760254746.26942.2049621502527864651@ietfa.amsl.com> Date: Thu, 23 Apr 2020 15:28:22 -0400 Message-ID: <020f01d619a5$5a7e6760$0f7b3620$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHio2zJAolkNix40BeFqEjeljO6MahuAdrA Content-Language: en-us X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 19:28:34 -0000 Ben: This is an information point response for your review rather than a clarifying question. Your comment: I assume the consequences of changing a community from non-transitive to transitive are well-known (but not to me) and that any operational considerations for mixed deployments are already stated somewhere prominent to someone working with BGP. (Where is that?) RFC4271 gives transitive versus non-transitive issues in section 5. Unrecognized transitive optional attributes - accepted and passed Unrecognized non-transitive are quietly ignored. For additional error handling see RFC7606. Quietly ignoring can lead to unknown drops. Not desired for this feature If we are using it to multicast filters. Cheers, Sue PS Christoph added all of your comments to the github repository. Please let him know if you would like to participate in the discussion of the nits. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Benjamin Kaduk via Datatracker Sent: Wednesday, April 22, 2020 8:42 PM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-idr-rfc5575bis-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There might be a minor internal inconsistency to tidy up (or I might be misunderstanding things). Section 8 states that: Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. As far as I can tell, this is referring to the text in Section 6 where (for the non-VPN case) "By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true [...]". But immediately following what I quote above is a statement that "the validation proceure (section 6) [...] [is] the same as for IPv4", which seems to be in conflict with this statement ("contrary to" vs. "the same as"). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract is perhaps pushing the length limits appropriate for an Abstract (vs. Introduction). Abstract Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to This makes me think of the DOTS WG (but it's far from clear that we should reference it in this text). Section 1 This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], the differences can be found in Appendix B. This document nit: comma splice A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted (Section 6). The Flow Specification received from an internal BGP peer within the same autonomous system [RFC4271] is assumed to have been validated prior to transmission within the internal BGP (iBGP) mesh of an autonomous system. If the aggregate traffic flow defined (Just to check, there's no particular harm in also validating iBGP flowspecs, just the extra computation burden of doing so, right?) systems that are able to detect malicious traffic flows. When automated systems are used, care should be taken to ensure their correctness as well as the limitations of the systems that receive and process the advertised Flow Specifications (see also Section 12). This seems to discuss making sure that the recipients of automated information handle it robustly; is it also worth some considerations on robustness of generating such automated information (something akin to a circuit breaker that would shut off the source if it started producing nonsensical output)? Also, nit: I think I parse this as "care should be taken to ensure [...] the limitations of the systems that receive and process [flowspecs]", which doesn't quite seem like what was intended. Section 4 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as one or more 2-tuples of the form . It consists of a 1- or 2-octet length field followed by a variable-length NLRI value. The length is expressed in octets. RFC 4760 only shows the one-octet length form; is there a good reference for the 2-octet length? (Or is it "new" with 5575?) Section 4.2 I think we should say something about how multi-byte values are encoded, especially given that we implicitly allow for different encodings of a given value (e.g., IP protocol could have padding, and small port numbers don't need to be encoded in 2 bytes). Even just making it more explicit that multiple encodings are allowed (and what the semantics are for any such "padding") would be worthwhile. Is there a maximum encoded length for anything other than the constraints of the 2-bit 'len' field? Interestingly, for DCSP we are much more strict -- why is the strictness needed there but not in general? Is this just to faithfully reproduce RFC 5575, as implied by the discussion in Appendix B? (I would make this a DISCUSS point if I didn't think that we're acting as if we're required to preserve the RFC 5575 behavior.) A NLRI value not encoded as specified in Section 4.2 is considered This *is* Section 4.2; perhaps "specified here" or "specified below"? Section 4.2.1.1, 4.2.1.2 While I don't anticipate needing a future extension to numeric_op, having the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper any future extensibility efforts. (Similarly for the "Traffic-action" field in Section 7.3, and "Traffic-marking" from Section 7.5.) Section 4.2.2.3 This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 3 component values SHOULD be encoded as single octet (numeric_op len=00). Is it well-defined how I would encode the value if I ignored the SHOULD? I, for one, am not sure what I would do... Section 4.2.2.4, etc. (I agree with my esteemed colleagues that hardcoding TCP and UDP as "the only protocols with ports" is unnecessary.) system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. If an implementation cannot decode the transport header does it treat all such packets as matching or not matching? Section 4.2.2.7 In case of the presence of the ICMP type (code) component only ICMP packets can match the entire Flow Specification. The ICMP type I'm not sure why the parenthetical is needed given that there's a separate NRLI type for "ICMP code". Section 5.1 component type. If the component types are the same, then a type- specific comparison is performed (see below) if the types are equal the algorithm continues with the next component. nit: there seems to be some missing punctuation or conjunction here. For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. It is surprising to me that the comparison operator can return "not-equal" for different encodings of a quantity that have the same semantic value (viz my previous note about encoding flexibility). That said, this procedure is well-defined and BGP speakers are not going to be re-encoding the NRLI values as they propagate, so I don't see an interop problem. Section 6 By default a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the below is true: Perhaps "in the absence of explicit configuration otherwise," to more closely parallel the other case? BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it for security reasons. nit: missing word (e.g., "necessary to enforce it here" or "necessary to enforce it in processing flow specifications"). The best-match unicast route may change over the time independently of the Flow Specification NLRI. Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change. Revalidation is defined as retesting that clause a and clause b above are true. IMPORTANT: Why does clause c not need to be retested? The neighboring AS is the immediate destination of the traffic described by the Flow Specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it. (This presumes that there is some integrity protection applied to the received data, which might be worth making more explicit.) Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as if/ Section 7 Please be consistent about "ASN" vs. "AS" in Table 2. Should the "traffic-action" and "traffic-marking" actions list the encoded length for the reader's convenience? Section 7.1 The remaining 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. Thank you for being clear about the units! Section 7.2 Is there anything to say about what time interval a non-integer packet rate should be evaluated over? Section 7.3 o T: Terminal Action (bit 47): When this bit is set, the traffic filtering engine will evaluate any subsequent Flow Specifications (as defined by the ordering procedure Section 5.1). If not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated. Just to check I'm reading this right: when the "terminal action" bit is set to one, it is *not* the terminal action, and the action *is* the terminal action when the "terminal action" bit is set to zero? That sounds backwards to my intuition (and maybe others'?). Section 7.4 Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. Do the different possible 'type's for this 'sub-type' interfere with each other? Section 7.6 Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to Traffic Filtering Actions that require different mappings in different systems in the network. nit(?): to my eye this reads better as "on different systems" (vs. "in"). For instance, providing packets with a worse-than-best-effort, per- hop behavior is a functionality that is likely to be implemented nit: no comma after worst-than-best-effort. Section 7.7 other (e.g. there may be more than one conflicting traffic-rate-bytes Traffic Filtering Action associated with a single Flow Specification). Traffic Filtering Action interference has no impact Maybe we should revise the earlier text about "Interferes with: No other [...]" to be explicit that it *does* self-interfere. behaviour (ie. match - replace - delete communities on administrative boundaries). See also Section 12. nit: could this parenthetical be expanded a little bit more? I feel like it's expected to be common knowledge among the main readership and so the current wording just serves as a trigger for this "well-known" (but not to me) concept, as opposed to standing on its own. Section 8 [side note: I'd love for us to eventually stop using "VPN" for things that don't encrypt the data passing over them. This doesn't seem like the right place to start, though.] Section 9 Should either/both of these mechanisms be on or off by default? Section 12 I'd consider mentioning again that some of the NRLI components won't work properly on fragmented traffic and that unexpected fragmentation can cause DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where fragmentation can occur anywhere on the path.) Is it worth saying anything about how the RT-redirect actions can direct traffic to an entity not expecting it (and, as such, potentially DoS them)? It also struck me as noteworthy that we're letting DSCP values creep out of a single administrative scope -- the filtering of inbound DSCP markings should probably be consistent with the traffic markings advertised to that peer. (There is perhaps also some "information leakage" as to what semantics are assigned to given DSCP values within the network in question, but I find it hard to get too worked up about that, especially since the inter-AS relationship is inherently pretty trusted.) As long as Flow Specifications are restricted to match the corresponding unicast routing paths for the relevant prefixes (Section 6), the security characteristics of this proposal are [There's an implicit "and both are received over trustworthy channels" in here. Perhaps it's okay to remain implicit, given how well-known BGP's security properties are...] Where the above mechanisms are not in place, this could open the door to further denial-of-service attacks such as unwanted traffic filtering, remarking or redirection. nit(?): I might just say "In particular, relaxing the validation procedure could [...]". additional filtering. For example, the use of [RFC6811] to enhance filtering within an AS confederation. nit: incomplete sentence. Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not I guess it's also a well-known attack that malicious neighbor could also draw traffic to itself for snooping purposes without actually dropping the traffic. But I'm not sure if there are any flowspec-specific considerations relating to that scenario. provide service (unfiltered address space hijack). Since validation of the Flow Specification is tied to the announcement of the best unicast route, this may also cause this validation to fail and consequently prevent Flow Specifications from being accepted by a peer. Possible mitigations are [RFC6811] and [RFC8205]. nit: there's a lot of pronouns ("this") in here; it might be worth disambiguating a couple. Flow Specification BGP speakers (e.g. automated DDoS controllers) not properly programmed, algorithms that are not performing as expected, or simply rogue systems may announce unintended Flow Specifications, send updates at a high rate or generate a high number of Flow Specifications. This may stress the receiving systems, exceed their maximum capacity or may lead to unwanted Traffic Filtering Actions being applied to flows. Is there any relevant guidance to give to receiving systems? Appendix A I don't know that just this one function is useful without some description of what format of input it requires. For example, if a.components and/or b.components have elements that evaluate to "false", the first two checks could return incorrect results (the perhaps-more-obvious case where both comp_a and comp_b are None cannot happen due to the nature of zip_longest). Appendix B Section 7 defines all Traffic Filtering Action Extended communities as transitive extended communities. [RFC5575] defined the traffic-rate action to be non-transitive and did not define the transitivity of the other Traffic Filtering Action communities at all. I assume the consequences of changing a community from non-transitive to transitive are well-known (but not to me) and that any operational considerations for mixed deployments are already stated somewhere prominent to someone working with BGP. (Where is that?) Section 7.7 contains general considerations on interfering traffic actions. Section 7.3 also cross-references this section. nit(?): the last "this section" refers to 7.7, not the location of the text I'm quoting from (Appendix B). I misread it the first time. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Apr 23 16:44:49 2020 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 B9A073A0A4F; Thu, 23 Apr 2020 16:44:11 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158768545161.15314.16342930539755480152@ietfa.amsl.com> Date: Thu, 23 Apr 2020 16:44:11 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-23.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 23:44:12 -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 : Dissemination of Flow Specification Rules Authors : Christoph Loibl Susan Hares Robert Raszuk Danny McPherson Martin Bacher Filename : draft-ietf-idr-rfc5575bis-23.txt Pages : 37 Date : 2020-04-23 Abstract: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. Other applications (e.g. centralized control of traffic in a SDN or NFV context) are also possible. Other documents may specify Flow Specification extensions. The information is carried via BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. This document obsoletes both RFC5575 and RFC7674. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-23 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-23 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 Apr 23 16:53:34 2020 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 34C653A0A68 for ; Thu, 23 Apr 2020 16:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 xXRJ6z9JRgY0 for ; Thu, 23 Apr 2020 16:53:29 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 777693A0A79 for ; Thu, 23 Apr 2020 16:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=Message-Id:In-Reply-To:To:References:Date:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jA+ihj35cGszRTTCmr8xE24xAOcDuotUYniz5XOSvnA=; b=sEZz3sbBvlOL3ukhrh0ZSrnbPb X9yRDt4WkP/s/Emfiea4SaYjV7OgFrHpCKXyVZhq/94OmSTiu1/+3QVH5DLoC5MJY7gBweYbITjDh p0318Tol/C/6Duna7TxUnD7YKf955wnFDa0cGfJGZIkOdR1HRi4o8cxfULL2nMAUWVyB/ATICnRMF y+Tn7YlQIdvCVLKdw1ADI5Wj0ObS3EtLiChU9cLwr3OEKGWn+CNcYEntww7C/X9dpu16YhT3MNq0W OQnZl+7IzF83zjBxi/2+0PfHSM8ubrDjLqpRNaoF5N+ht2/p1BcKVltSLVm0+p3I1CKsYmlRfszer 1Tq6BCfA==; Received: from 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.66.207]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jRlen-0009a5-AF for idr@ietf.org; Fri, 24 Apr 2020 01:53:26 +0200 From: Christoph Loibl Content-Type: multipart/alternative; boundary="Apple-Mail=_CBF37504-6E19-4B98-A075-9F701C6F99FC" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 24 Apr 2020 01:53:18 +0200 References: <158768545161.15314.16342930539755480152@ietfa.amsl.com> To: IDR List In-Reply-To: <158768545161.15314.16342930539755480152@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 24 Apr 2020 01:53:25 +0200 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-23.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 23:53:33 -0000 --Apple-Mail=_CBF37504-6E19-4B98-A075-9F701C6F99FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I just uploaded a -23 of draft-ietf-idr-rfc5575bis-23 to address most of = the smaller issues and nits that have been found in the latest reviews. = It also solves the discuss from Alissa that has been discussed on the = list yesterday. The discuss from Benjamin has not (if needed) required = any changes to the document yet. The issues have been tracked and can be reviewed on GH: https://github.com/stoffi92/rfc5575bis/issues = But I will also send a complete report to the list for reference. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 24.04.2020, at 01:44, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Dissemination of Flow Specification Rules > Authors : Christoph Loibl > Susan Hares > Robert Raszuk > Danny McPherson > Martin Bacher > Filename : draft-ietf-idr-rfc5575bis-23.txt > Pages : 37 > Date : 2020-04-23 >=20 > Abstract: > This document defines a Border Gateway Protocol Network Layer > Reachability Information (BGP NLRI) encoding format that can be used > to distribute traffic Flow Specifications. This allows the routing > system to propagate information regarding more specific components = of > the traffic aggregate defined by an IP destination prefix. >=20 > It also specifies BGP Extended Community encoding formats, that can > be used to propagate Traffic Filtering Actions along with the Flow > Specification NLRI. Those Traffic Filtering Actions encode actions = a > routing system can take if the packet matches the Flow = Specification. >=20 > Additionally, it defines two applications of that encoding format: > one that can be used to automate inter-domain coordination of = traffic > filtering, such as what is required in order to mitigate > (distributed) denial-of-service attacks, and a second application to > provide traffic filtering in the context of a BGP/MPLS VPN service. > Other applications (e.g. centralized control of traffic in a SDN or > NFV context) are also possible. Other documents may specify Flow > Specification extensions. >=20 > The information is carried via BGP, thereby reusing protocol > algorithms, operational experience, and administrative processes = such > as inter-provider peering agreements. >=20 > This document obsoletes both RFC5575 and RFC7674. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-23 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-23 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc5575bis-23 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_CBF37504-6E19-4B98-A075-9F701C6F99FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I = just uploaded a -23 of draft-ietf-idr-rfc5575bis-23 to address most = of the smaller issues and nits that have been found in the latest = reviews. It also solves the discuss from Alissa that has been discussed = on the list yesterday. The discuss from Benjamin has not (if needed) = required any changes to the document yet.

The issues have been tracked and can be = reviewed on GH:

= https://github.com/stoffi92/rfc5575bis/issues

But I will also send a = complete report to the list for reference.

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



On 24.04.2020, at 01:44, internet-drafts@ietf.org wrote:


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 =           : = Dissemination of Flow Specification Rules
=        Authors =         : Christoph Loibl
=             &n= bsp;           &nbs= p;Susan Hares
=             &n= bsp;           &nbs= p;Robert Raszuk
=             &n= bsp;           &nbs= p;Danny McPherson
=             &n= bsp;           &nbs= p;Martin Bacher
Filename =        : = draft-ietf-idr-rfc5575bis-23.txt
Pages =           : 37
= Date =            : = 2020-04-23

Abstract:
=   This document defines a Border Gateway Protocol Network = Layer
  Reachability Information (BGP NLRI) = encoding format that can be used
  to = distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more = specific components of
  the traffic aggregate = defined by an IP destination prefix.

=   It also specifies BGP Extended Community encoding formats, = that can
  be used to propagate Traffic = Filtering Actions along with the Flow
=   Specification NLRI.  Those Traffic Filtering Actions = encode actions a
  routing system can take if = the packet matches the Flow Specification.

=   Additionally, it defines two applications of that encoding = format:
  one that can be used to automate = inter-domain coordination of traffic
=   filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a = second application to
  provide traffic = filtering in the context of a BGP/MPLS VPN service.
=   Other applications (e.g. centralized control of traffic in a = SDN or
  NFV context) are also possible. =  Other documents may specify Flow
=   Specification extensions.

=   The information is carried via BGP, thereby reusing = protocol
  algorithms, operational experience, = and administrative processes such
  as = inter-provider peering agreements.

=   This document obsoletes both RFC5575 and RFC7674.


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

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-23
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis= -23

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc5575bis-2= 3


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

= --Apple-Mail=_CBF37504-6E19-4B98-A075-9F701C6F99FC-- From nobody Thu Apr 23 18:46:12 2020 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 B2EDC3A0D2D; Thu, 23 Apr 2020 18:46:09 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kybvg93kbG8j; Thu, 23 Apr 2020 18:46:08 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4BD543A0891; Thu, 23 Apr 2020 18:45:50 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03O1jTJb026491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 21:45:32 -0400 Date: Thu, 23 Apr 2020 18:45:29 -0700 From: Benjamin Kaduk To: Robert Raszuk Cc: The IESG , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, "idr@ietf. org" , Jie Dong , Alvaro Retana Message-ID: <20200424014529.GQ27494@kduck.mit.edu> References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 01:46:10 -0000 Hi Robert, On Thu, Apr 23, 2020 at 04:49:43PM +0200, Robert Raszuk wrote: > Hi Benjamin > > Acceptance and validation are completely different things. > > By acceptance we say that router control plane accepted the update > message (as opposed to dropping it due to non intersecting RTs in VPNs). > > Validation however is executed on accepted routes to check if such routes - > or to be more precise paths - are eligible to be used for best path > selection and therefor for local installation into data plane. > > Hope that clarifies the discuss :) That does help clarify quite a bit, and I'm glad that I added my disclaimer about misunderstanding things :) I will of course drop the Discuss point. >From just the previous messages in the thread I wasn't sure whether the "accept" operation was meant to happen before or after validation, so thank you for spelling it out clearly. (Also thanks to everyone for being patient with my misunderstanding!) The string "accept" appears 7 times, and the Section-1 usage seems to be what tripped me up ("A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted") -- note the "before". Section 12 perhaps has something similar ("[...], this may also cause this validation to fail and consequently prevent Flow Specifications from being accepted by a peer."). I'll leave it up to you as to whether any rewording is appropriate in those two places. Anyway, armed with this new knowledge I can see that I was wrongly interpreting what the text about "contrary to the behavior specified for the non-VPN NLRI" was referring to. I'm still not 100% sure what it is intending to refer to, though -- is it even something in this document (like the "Standard BGP policy mechanisms, such as UPDATE filtering by NLRI prefix as well as community matching and manipulation, must apply to the Flow Specification defined NLRI-type, especially in an inter- domain environment." in Section 3) vs. just general knowledge of how things work? From nobody Thu Apr 23 19:12:45 2020 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 254E03A0D91; Thu, 23 Apr 2020 19:12:17 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDJpALtYdhp9; Thu, 23 Apr 2020 19:12:15 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 BDAFD3A0D90; Thu, 23 Apr 2020 19:12:14 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03O2C9KC001042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 22:12:12 -0400 Date: Thu, 23 Apr 2020 19:12:09 -0700 From: Benjamin Kaduk To: Susan Hares Cc: "'The IESG'" , draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org Message-ID: <20200424021209.GR27494@kduck.mit.edu> References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> <020d01d619a4$26f91f80$74eb5e80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020d01d619a4$26f91f80$74eb5e80$@ndzh.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 02:12:19 -0000 Hi Sue, On Thu, Apr 23, 2020 at 03:19:45PM -0400, Susan Hares wrote: > Ben: > > First of all thank you for your detailed review. > > We really appreciate this detailed review during a revision of a deployed > protocol. I'm regularly surprised by what sorts of things can become stale in -bis documents -- the usual culprit is IANA considerations, but sometimes there are stale references or section numbers in references, so I try to read through the whole thing if I have time. > Christoph has added each of your comments to the github repository for this > draft. > > > Two clarifying questions that need pulling out besides your DISCUSS. > (see Robert's comment on the RR implication on the DISCUSS). > I'm pulling these to the front for ease of responding to the > > Section 12: > Your comment: > I'd consider mentioning again that some of the NRLI components won't work > properly on fragmented traffic and that unexpected fragmentation can cause > DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where > fragmentation can occur anywhere on the path.) > -------- > Clarifying questions: > The RFC5575bis (and RFC5575) is simply providing filters for a firewall > function. > Is there an RFC that suggestions the appropriate cautions for firewall > filters.? > If so, could we mention that people implementing RFC5575bis should > simply be aware of BCPs regarding firewalls regarding DoS? I don't know offhand of a good reference for this point (but maybe one of my fellow ADs does!) -- my sense is that it's mostly just general institutional knowledge. For example, RFC 7597 mentions the need to reassemble before tunneling fragmented packets, and RFC 4301 has extensive discussion about fragment handling in IPsec and the design rational. So I was mostly just envisioning a single sentence along the lines of "Note that selectors that match on port number will match only the first fragment of fragmented packets, which may not be the desired behavior when fragmentation occurs". > Your comment: > Is it worth saying anything about how the RT-redirect actions can direct > traffic to an entity not expecting it (and, as such, potentially DoS them)? > > Clarifying question > Redirect also occurs with the firewalls? > RFC5575bis is simply enabling that function with multicast of the > Filter prefixes. Is there a BCP regarding firewalls that use redirect? Similarly to the above, I don't know of one offhand. (I'm also not sure that it's even worth mentioning this topic in the document -- it's getting a bit far afield.) > I have been trying to monitor the new threats discussion. > > Your comment: > :It also struck me as noteworthy that we're letting DSCP values creep out of > a single administrative scope -- the filtering of inbound DSCP markings > should probably be consistent with the traffic markings advertised to that > peer." > > The DSCP markings seem to cross boundaries with MPLS. > If there is a BCP regarding DSCP marking, should we reference this as well? Interestingly, I don't see such a BCP, and the best references here might be the original protocol spec/architecture (2474/2475) that discuss ingress and classifier behavior to enforce policy. RFC 4594 has something pretty close, though, for many of the service classes: o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods, defined in [RFC2475]. So perhaps this document would say something like "when advertising extended communities for traffic-marking with DSCP, an AS should ensure that the advertised values will be accepted by its DSCP ingress policy and classifiers, per [RFC 2475]". Sorry that I don't have great answers for most of these, Ben From nobody Fri Apr 24 02:49:32 2020 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 13BB93A1120; Fri, 24 Apr 2020 02:49:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <158772176873.17533.3566124086139075762@ietfa.amsl.com> Date: Fri, 24 Apr 2020 02:49:29 -0700 Archived-At: Subject: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 09:49:30 -0000 Robert Wilton has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't know if this is a valid discuss point, so happy to be educated that it is always written this way and I'll remove my discuss ... I note that in 5 places this document has text that states the equivalent to "SHOULD be set to 0 on encoding, and MUST be ignored during decoding." (example given below). Doesn't this make extending this in future more risky because if new meaning are given to these bits then there could be senders already transmitting non 0 values which a receiver might then misinterpret? Hence, I was surprised that the constraints did not also include a MUST on the encoding side (i.e. be strict in what you send ...), i.e. "MUST be set to 0 on encoding, and MUST be ignored during decoding." Example: The extended is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | reserved | reserved | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | r.| DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Traffic Marking Extended Community Encoding o DSCP: new DSCP value for the transiting IP packet. o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored during decoding. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I also had a few minor comments on this document: 4.1. Length Encoding o If the NLRI length is smaller than 240 (0xf0 hex) octets, the length field can be encoded as a single octet. o Otherwise, it is encoded as an extended-length 2-octet value in which the most significant nibble of the first octet is all ones. This describes the first nibble in binary, and then later it is shown in hex. It might be more clear to write ... in which the most significant nibble has the hex value 0xf. In Figure 1 above, values less-than 240 are encoded using two hex digits (0xnn). Values above 239 are encoded using 3 hex digits (0xfnnn). The highest value that can be represented with this encoding is 4095. For example the length value of 239 is encoded as 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). 4.2. NLRI Value Encoding Components MUST follow strict type ordering by increasing numerical order. A given component type may (exactly once) or may not be present in the Flow Specification. If present, it MUST precede any component of higher numeric type value. I wasn't sure, but wondering whether "may (exactly once) or may not be" should be "MAY (exactly once) be"? 5.1. Ordering of Flow Specifications For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. I think that the intended comparison here is clear, but I was wondering whether this text should flag endian concerns at all. E.g. if the component data has been stored in memory and any numeric values have had endian conversion performed on them then a naive memcmp() could give a different answer. From nobody Fri Apr 24 05:02:07 2020 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 7D4DF3A0AF7; Fri, 24 Apr 2020 05:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 g2Gf2aYvXR4o; Fri, 24 Apr 2020 05:01:47 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 72D663A0AF8; Fri, 24 Apr 2020 05:01:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Robert Wilton'" , "'The IESG'" Cc: , , , "'Jie Dong'" , References: <158772176873.17533.3566124086139075762@ietfa.amsl.com> In-Reply-To: <158772176873.17533.3566124086139075762@ietfa.amsl.com> Date: Fri, 24 Apr 2020 08:01:11 -0400 Message-ID: <005f01d61a30$0cc55660$26500320$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHINDy2br9xeCeFuf7NVzp77Es8JKij8HTA X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 12:01:49 -0000 Robert:=20 Thank you for your question. I'm pulling the DISCUSS to the front.=20 The Discuss in the phrases:=20 "SHOULD be set to 0 on encoding, and MUST be ignored during decoding."=20 is actually language used in many past routing drafts for expansion = purposes.=20 The difficultly in deploying new code is in the partial deployments.=20 The "must be ignored" clause allows the transmitter to change to something besides zero.=20 This is a RFC5575bis document based past history of these=20 statements in routing code.=20 I've taken the remainder of your comments as editorial comments.=20 Our authoring team loads these comments into github, and you are welcome = to=20 Contribute to the resolutions.=20 Susan Hares=20 -----Original Message----- From: Robert Wilton via Datatracker [mailto:noreply@ietf.org]=20 Sent: Friday, April 24, 2020 5:49 AM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org; Jie Dong; aretana.ietf@gmail.com; jie.dong@huawei.com Subject: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with = DISCUSS and COMMENT) Robert Wilton has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't know if this is a valid discuss point, so happy to be educated = that it is always written this way and I'll remove my discuss ... I note that in 5 places this document has text that states the = equivalent to "SHOULD be set to 0 on encoding, and MUST be ignored = during decoding." (example given below). Doesn't this make extending this in future more risky because if new = meaning are given to these bits then there could be senders already = transmitting non 0 values which a receiver might then misinterpret? Hence, I was surprised that the constraints did not also include a MUST = on the encoding side (i.e. be strict in what you send ...), i.e. "MUST = be set to 0 on encoding, and MUST be ignored during decoding." Example: The extended is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | reserved | reserved | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | r.| DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Traffic Marking Extended Community Encoding o DSCP: new DSCP value for the transiting IP packet. o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored during decoding. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I also had a few minor comments on this document: 4.1. Length Encoding o If the NLRI length is smaller than 240 (0xf0 hex) octets, the length field can be encoded as a single octet. o Otherwise, it is encoded as an extended-length 2-octet value in which the most significant nibble of the first octet is all ones. This describes the first nibble in binary, and then later it is shown in = hex.=20 It might be more clear to write ... in which the most significant nibble = has the hex value 0xf. In Figure 1 above, values less-than 240 are encoded using two hex digits (0xnn). Values above 239 are encoded using 3 hex digits (0xfnnn). The highest value that can be represented with this encoding is 4095. For example the length value of 239 is encoded as 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). 4.2. NLRI Value Encoding Components MUST follow strict type ordering by increasing numerical order. A given component type may (exactly once) or may not be present in the Flow Specification. If present, it MUST precede any component of higher numeric type value. I wasn't sure, but wondering whether "may (exactly once) or may not be" = should be "MAY (exactly once) be"? Sue: (treating as a "editorial) Does this work for you?=20 Old/A given component type may (exactly once) or may not be present in the flow Specification/ New/Each given component type may or may not be present in the=20 Flow Specification. If a type is present, it may be present only once./ 5.1. Ordering of Flow Specifications For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. I think that the intended comparison here is clear, but I was wondering = whether this text should flag endian concerns at all. E.g. if the = component data has been stored in memory and any numeric values have had = endian conversion performed on them then a naive memcmp() could give a = different answer. [Sue]: (treating as a "editorial)=20 If you have a suggestion on endian statements, please let us know.=20 We provide links to from other BGP specifications for the types.=20 Appendix A was intended to provide an example of the flow rule = comparison.=20 Do you think this helps?=20 The example encodings in section 4 were intended to provide examples for implementers.=20 From nobody Fri Apr 24 05:53:06 2020 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 751D83A0061; Fri, 24 Apr 2020 05:52:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158773276945.29291.10778364756332567625@ietfa.amsl.com> Date: Fri, 24 Apr 2020 05:52:49 -0700 Archived-At: Subject: [Idr] Alissa Cooper's No Objection on draft-ietf-idr-rfc5575bis-23: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 12:52:50 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Fri Apr 24 06:14:54 2020 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 2FD213A0CDC; Fri, 24 Apr 2020 06:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 paUtTypgibkG; Fri, 24 Apr 2020 06:14:30 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2124.outbound.protection.outlook.com [40.107.89.124]) (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 6B18F3A0CDB; Fri, 24 Apr 2020 06:14:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QwSi4Jt9/zvYRbPcfxmvcBvxsamuSF7teXFw9Pw7I8L4grYwY5P0cDikaSge6fcqs1NpagHMR2jujFhrHfJGYrqKSDSpWbGCC9rdDojIW/os9wFMDZNBLLLRwVgBVWiLLQ5n2Ix/x8s2Z94na8Bt8GG2hvVucyossaXJxwAP7rU8x1GGm1bCMbcMxtQHRoFtdEasQlY65piZPal5/69yUE750gRDyDGfZ7PDUu9qX7rESTf/RRDJNGK7h3NayowtNpWo1QbwX4HBwqdxat88qQ7j0JXjmIYKRqaGDkfp3P8mOJ7PUlMusXxZSfweYIQSXjvNShLuXl1XMCtAQz2qXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hqDMcH3r9pVXOkzsE85RTYvh7K+vgmLB4jKqB8RxaWw=; b=nrxmURS3W31DINSSNrjYclkrvuYdnfbj1GV1PvtPQmMdiXDtfHuQI4jWOKHBFloLYlGZh9KUKyyad8XuNifSMB3oHTNXPQy5+F4Z/wTtOkLFuDe/0OF/VkpV7LIFBhNO6CYV83gIBMDyR37Jn08nOh2dkp4pPbfzlMeB3MFI/zXE1d/h6iiXt86iTkArOp6/A4ltQrwZ3vewUlYFKiwbbbswHMPckZBBjYDm0g9ggcuGUXozbnpcDJVQxSdakS+o4mvB329dDuoCV01y25C6zJ3CQZTZq44MRwtifQqb3BdK7T035Y9BLB4yQ0H8UGoMEC/JllLTxEzZonH4QWIbOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hqDMcH3r9pVXOkzsE85RTYvh7K+vgmLB4jKqB8RxaWw=; b=ZlqfQlFMa7V4h5jgYMTkF/ScdkuM4sojxe4+X3OC8SJEV4ve6ggcOcfMG1lSSz+DbamRBmhek72y/VCtjhb3xT0CMnHRFUT9SF41h+3AWNMgE6nQfA+v91L+QJofUA2FHsiV6OaHSRR9QzBqm8RPbGuu6/B7N3L/z5IRx2LaIe4= Received: from BL0PR0901MB3684.namprd09.prod.outlook.com (2603:10b6:207:38::18) by BL0PR0901MB4196.namprd09.prod.outlook.com (2603:10b6:208:1cd::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Fri, 24 Apr 2020 13:14:28 +0000 Received: from BL0PR0901MB3684.namprd09.prod.outlook.com ([fe80::91f0:cc49:a918:b41d]) by BL0PR0901MB3684.namprd09.prod.outlook.com ([fe80::91f0:cc49:a918:b41d%6]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 13:14:28 +0000 From: "Sriram, Kotikalapudi (Fed)" To: GROW WG , "idr@ietf.org" CC: "draft-heitz-idr-wklc@ietf.org" , "Hannachi, Lilia (IntlAssoc)" Thread-Topic: Measurements on Regular, Extended, and Large Communities Thread-Index: AQHWGe3MXOXky3BBr0yxtCqjBaxXEqiIN71N Date: Fri, 24 Apr 2020 13:14:28 +0000 Message-ID: References: In-Reply-To: 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.197.182] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9422f15f-34b2-4fcb-564b-08d7e8516b26 x-ms-traffictypediagnostic: BL0PR0901MB4196:|BL0PR0901MB4196: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR0901MB3684.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(366004)(396003)(136003)(39860400002)(346002)(76116006)(316002)(2940100002)(9686003)(66946007)(54906003)(66446008)(64756008)(66556008)(66476007)(81156014)(55016002)(110136005)(71200400001)(478600001)(186003)(5660300002)(107886003)(26005)(6506007)(86362001)(7696005)(4326008)(52536014)(8676002)(450100002)(8936002)(2906002)(33656002); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vZOZuQIGvkfm2JJAdHfEbv1zPGe63ImhtAsHCPzmcNkRyH8j3bZFmQXYZiKEK09sg9Z//O5PpnbCbvy/nN8rauysmG4KtPg0MurRte13/wKx+z3z1qivINuF33zbljXNbhXMQqroWJ6MdpeMnehKIB9hnb3zKfT1ExaKt8cCtD9CrJNCIWHsdwoMBLYARQAl/s70W56xzYOUGDS/AzywSLV3McmEQWocigRJbN8HgGsu5bHsX02fLxIBG/R4J3pIb7WjLigAYvECRnqRF463ttc5+FCR72aRdv/ewRJ17CsmbY/xKWQ7Z9asbl0YjRErgPgKDRYWPkOk7UL6LmiRessdK3LVx97MPPABL0jxIw+QDIw9h1Dgb3HhoLkUZNVMcr6VOCYummW4bTBKbBaQgVAehObph94f2oZI2thlJFj/YcitAhVPPQqg53dL+jCq x-ms-exchange-antispam-messagedata: c+5gkTOMoLNQheub3urLywHCpOGvvKSCUecCQXzNYCIfqJ9Nt9pMmAJQ9/jO4g1Lgsn+22Y2Cq6O+YLFnYOGmQytRwKPAAL+/RkkktZjSTLSlkQR2W2rUTgoCqKLzHtOCJinQhewws2M+R5aNSd2qw== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 9422f15f-34b2-4fcb-564b-08d7e8516b26 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 13:14:28.2384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5RY5eBsYKFwZJXf+SkXKL0SIJSjIWJ1whdlas3a7pGtdXhdO6dbSeDcoHp3kpGod63F0UvnKeQgWpkpbd2UrJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB4196 Archived-At: Subject: [Idr] Measurements on Regular, Extended, and Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 13:14:33 -0000 Please see measurements below on Regular, Extended (EC), and Large Communit= ies (LC).=0A= Analysis is based on data from many newer Routeviews collectors. =0A= ** Question: Any insights why we don't see any ECs at all? **=0A= OTOH, we do see good numbers of LCs even though there is no IANA registry f= or them yet.=0A= Distribution of path lengths in updates with Communities/LCs is also shown = below.=0A= =0A= Sriram=0A= =0A= P.S. Thank you to Lilia Hannachi (NIST) for the detailed analysis.=0A= =0A= *********************************************************************=0A= Community ANALYSIS (Collector : napafrica 2020-04-02:00)=0A= *********************************************************************=0A= # Updates =3D 479381 (Total)=0A= # COMMUNITY =3D 329323 (68%)=0A= (AS path length distribution =3D 2:11504 3:114361 4:120531 5:49992 6:= 17917 7:3974 8:1623 9:584 10:130 11:268 12:62 13:2)=0A= # LARGE_COMMUNITY =3D 49515 (10%)=0A= (AS path length distribution =3D 2:4004 3:22893 4:16388 5:4966 6:864 = 7:313 8:42 10:22 11:1)=0A= # EXTENDED COMMUNITIES =3D 0 (0%)=0A= =0A= *********************************************************************=0A= Community ANALYSIS (Collector : amsix 2020-04-02:08)=0A= *********************************************************************=0A= # Updates =3D 395487 (Total)=0A= # COMMUNITY =3D 115900 (29%)=0A= (AS path length distribution =3D 2:6038 3:28532 4:42006 5:23086 6:795= 8 7:2333 8:425 9:98 10:90 11:45 12:19 13:6)=0A= # LARGE_COMMUNITY =3D 11530 (2%)=0A= (AS path length distribution =3D 2:1321 3:4583 4:3871 5:1467 6:214 7= :55 8:15 9:4)=0A= # EXTENDED COMMUNITIES =3D 0 (0%)=0A= =0A= From nobody Fri Apr 24 06:44:11 2020 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 67A1D3A0832; Fri, 24 Apr 2020 06:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 header.b=ObCyFjz1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fVuvlBNr 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 AInuAxdYHy1n; Fri, 24 Apr 2020 06:43:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8F83A082C; Fri, 24 Apr 2020 06:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10926; q=dns/txt; s=iport; t=1587735821; x=1588945421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Srj6c71N9+mixv3r94J4k73iLI1iiIeOVQaP7iUAlNM=; b=ObCyFjz19uJc41+dGeIdIXjO0mwy0l4CKr8f0TtrnG3qMIukcuwTn+/t GHtPnVatmgg/Jv6yKlg7DkFREyuVwTP699FI6omVlJCvbd9bxclp4bu7I /NWNZSwauGGeLHiXdRptQp+pRpkZ3icEaiHhZ8YryNLi3z8IDjoINetER M=; IronPort-PHdr: =?us-ascii?q?9a23=3AnKOzSR9sbd6A8v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSaCEnnK/jCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAADN66Je/4QNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBPIEzBwEBCwGBUyQFKAVsWCAECyoKhBWDRgOEWYYXgl+BAYh1jjq?= =?us-ascii?q?BLhSBEANUCwEBAQwBASMKAgQBAYREAheCDyQ0CQ4CAwEBCwEBBQEBAQIBBQR?= =?us-ascii?q?thVYMhXEBAQEBAgESEREMAQE3AQsEAgEIDgMEAQEDAiMDAgICHxEUAQgIAgQ?= =?us-ascii?q?BDQUIDA6DBYJLAw4gAQMLpwECgTmIYXaBMoMAAQEFgUZBgx8NC4IOAwaBDio?= =?us-ascii?q?BgmKJVhqBQT+BEUOCGDU+gh5JAgECAYEsARIBEhEVgnsygi2ONC2CVp9sMko?= =?us-ascii?q?KgkWIDIV0hTUEhF+CWohWkUGPeIlFgkOLMIVGAgQCBAUCDgEBBYFSOWZYEQd?= =?us-ascii?q?wFYMkUBgNkTQMFxVuAQgBgkKFFIVCdAIzAgYIAQEDCXyLaYEzAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,311,1583193600"; d="scan'208";a="757316121" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 13:43:39 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 03ODhdHb003270 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2020 13:43:39 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 08:43:39 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 08:43:39 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Apr 2020 08:43:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MHadptvPm6OT3/fUfMKyqGO4I26xcyl1DQOERe5EoP16k+lzX8V2fJ5HyEDLambB/zx7itxh+a2dEUHKzgQHG5JK0/lc9xc/+//iyee61SKgwqpa7XBn0E4ASMmqSvLQW//i+EUTFY1Dh3hVha0goCdLOkjvgg5HN1WiAIf66laY+rJyUZQzk437ek6aDuPyQk7lxhPcRellDh59kmkA5y+E8NhqECPVisx3a9yMtoIpH+F0JexIVNjuL5Yc4jS0BNCwoT8HorW3W15FbkUr4DcyTtqANWGjPg1LWgJQukx9hL7IOTmSVMzruvKQRevaw+189O03s6GmeOvj0f6K2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Srj6c71N9+mixv3r94J4k73iLI1iiIeOVQaP7iUAlNM=; b=kj3NCk4WRUBS20JeoWdJ0I8PwNZS/rdyNdDYqqXW484U/+5grvSqR7mqyXAizz+mqEJ6uIzQIdgkvIcKKJNa/BR/IrClgBrfsxzG24TyU1VOnWsDDEcVSu081LW1HylgYMO8tC0HzTeOmLo8+WLaZqDfUf3NP9ge6FeOUFYp+HMh+eNrjKRfuNVPZs6by85kCm5fnE7uMVVc3XL64koCzTEnN7v/B1MPRDMv5BIwQJDOUy9Mv8hTRMoU5Me8kBA5MiUKl797dqSS+1BwjrLSyAp8foH39fe0T+SFlrwT4rbQFVLG5aQprucJpTCz6sKic9G6DBmTnPKi69PSoEkyDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Srj6c71N9+mixv3r94J4k73iLI1iiIeOVQaP7iUAlNM=; b=fVuvlBNr1z7Fi4pvnkv++nPgTNbdUJ/x5nSvPFWoFNlg3zm9gFMYTN7sVLiYMlWKX38szeI+oXlnbH0PsS7DpIU9M43FMUtayrE5Bd7TEoxO0+MdWkh/5zoYc85OJkVamO7ZKAE3bvyFmzSH/r8rsOM8gAFX1EXv5ek8nKgN4Bo= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4462.namprd11.prod.outlook.com (2603:10b6:208:18f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Fri, 24 Apr 2020 13:43:38 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 13:43:38 +0000 From: "Rob Wilton (rwilton)" To: Susan Hares , "'The IESG'" , "aretana.ietf@gmail.com" CC: "draft-ietf-idr-rfc5575bis@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , "'Jie Dong'" Thread-Topic: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Thread-Index: AQHWGh3EsbZFlJO8wUqFD9efKbLE/6iIK9uAgAAA0GA= Date: Fri, 24 Apr 2020 13:43:36 +0000 Message-ID: References: <158772176873.17533.3566124086139075762@ietfa.amsl.com> <005f01d61a30$0cc55660$26500320$@ndzh.com> In-Reply-To: <005f01d61a30$0cc55660$26500320$@ndzh.com> 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=rwilton@cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45d6579c-dba0-42a9-5615-08d7e8557e1d x-ms-traffictypediagnostic: MN2PR11MB4462: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(136003)(376002)(366004)(5660300002)(55016002)(54906003)(110136005)(86362001)(71200400001)(4326008)(33656002)(9686003)(966005)(81156014)(8676002)(7696005)(478600001)(8936002)(66446008)(66946007)(66556008)(64756008)(66476007)(186003)(52536014)(316002)(76116006)(6506007)(26005)(53546011)(2906002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DYpe93ChM1556tJTDKDwtKQpGHOG5FVmD1l4m+jRPpdxXg913SJRrw2DPl73lJAOlYMJAIOdr2Y1Y+K4lNvOCVR9sEY1tHFNBv4LK6rdoFploN1GxYieR+ImDJZmKiNN1l3FLbx1hVnLhivpYcuK/WYUh6zvxQ24JIapnFyRCVAkM5Zzw4CFXKJtHzQFaJthQKlW6hA2TSya6vV5iWoseYDefjdm6wfVihavWwJ+tipvrohjEaSb6VgOzqQ6LX9oU7kRnfUxdh4Kgmc4wlGErido9UDHyov8cdvZHJwjtubUlJHGGEJF+/Iapp3rFrlGQJd8M5tDMIJg0U1IkGaK/6gWlgoQe6tyy/hThCDYYQoUXtP2VdTO7ZoJO6cx0KIaaIYfbwMkbq8s26Hh6qt8HFZI/uZG5Nr8EkDkQsZxhWZbchkERI4J9Bus3T7Ql1+20S0M+yeayac8v/fx7uui3N0UzF31Godgb4J2NoVxjnVKBSl6oH7jzvLuzUOKxRNaN0q/Mf2GCAaXJ6toPTWbUQ== x-ms-exchange-antispam-messagedata: YIoAZdGdp7KbaTmHZOrG7bhYjbDBecyl0OfCDJr+S/UYV+9mW07bhxHHGi1tOPsQ+os7IMTLHzga53MyFZzUhMlxbuiDM3Wc27QCB7tuxxLWV3en2WJNs+mS6UiiO9qRQaTIBjCCSLJOlgk5FAOo7Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 45d6579c-dba0-42a9-5615-08d7e8557e1d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 13:43:37.4125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EWIte4RNqaisn5YupxlsGOzHJWU1jsbzGRUGErdacz32FUkO4jwt6exX3jHsTmo6ofcjHULXBZU4aGgOkXXYmQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4462 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 13:43:44 -0000 SGkgU3VzYW4sDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlIGFuZCBleHBsYW5hdGlv bi4NCg0KUGxlYXNlIHNlZSBpbmxpbmUgLi4uDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KPiBTZW50OiAyNCBB cHJpbCAyMDIwIDEzOjAxDQo+IFRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNj by5jb20+OyAnVGhlIElFU0cnIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1pZHIt cmZjNTU3NWJpc0BpZXRmLm9yZzsgaWRyLWNoYWlyc0BpZXRmLm9yZzsgaWRyQGlldGYub3JnOw0K PiAnSmllIERvbmcnIDxqaWUuZG9uZ0BodWF3ZWkuY29tPjsgYXJldGFuYS5pZXRmQGdtYWlsLmNv bQ0KPiBTdWJqZWN0OiBSRTogUm9iZXJ0IFdpbHRvbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1p ZHItcmZjNTU3NWJpcy0yMzoNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IFJv YmVydDoNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBxdWVzdGlvbi4gICBJJ20gcHVsbGluZyB0 aGUgRElTQ1VTUyB0byB0aGUgZnJvbnQuDQo+IA0KPiBUaGUgRGlzY3VzcyBpbiB0aGUgcGhyYXNl czoNCj4gDQo+ICJTSE9VTEQgYmUgc2V0IHRvIDAgb24gZW5jb2RpbmcsIGFuZCBNVVNUIGJlIGln bm9yZWQgZHVyaW5nIGRlY29kaW5nLiINCj4gDQo+IGlzIGFjdHVhbGx5IGxhbmd1YWdlIHVzZWQg aW4gbWFueSBwYXN0IHJvdXRpbmcgZHJhZnRzIGZvciBleHBhbnNpb24NCj4gcHVycG9zZXMuDQpb UlddIA0KDQpZZXMuIEkgYXBwcmVjaWF0ZSB0aGF0IGhpc3RvcmljYWwgcHJlY2VkZW50IGhvbGRz IGEgbG90IG9mIHdlaWdodC4gIFByaW9yIHRvIG15IGRpc2N1c3MgSSBoYWQgdHJpZWQgdG8gcXVp Y2tseSBmaW5kIGV4YW1wbGVzIG9mIHRoaXMsIGJ1dCB3YXMgbG9va2luZyBpbiB0aGUgd3Jvbmcg ZG9jdW1lbnRzLiA7LSkNCg0KDQo+IA0KPiBUaGUgZGlmZmljdWx0bHkgaW4gZGVwbG95aW5nIG5l dyBjb2RlIGlzIGluIHRoZSBwYXJ0aWFsIGRlcGxveW1lbnRzLg0KPiBUaGUgIm11c3QgYmUgaWdu b3JlZCIgY2xhdXNlIGFsbG93cyB0aGUgdHJhbnNtaXR0ZXIgdG8gY2hhbmdlDQo+IHRvIHNvbWV0 aGluZyBiZXNpZGVzIHplcm8uDQpbUlddIA0KWWVzLCBpdCBpcyB0aGUgcGFydGlhbCBkZXBsb3lt ZW50cyB0aGF0IGlzIGNvbmNlcm5pbmcgbWUuDQoNCkJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5 IHRoYXQgbWVhbnMgdGhlIHNlbmRlciBpcyBhICJTSE9VTEQgYmUgMCIgbm90IGEgIk1VU1QgYmUg MCI/DQoNCkluIHRoZSBpbnRlcm9wIGNhc2UgZWl0aGVyIHNlbmRlciBvciByZWNlaXZlciBjb3Vs ZCBiZSB1cGdyYWRlZCwgc28gd2h5IHRoZSBhc3ltbWV0cnk/DQoNCk15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCB0aGVzZSBmaWVsZHMgc2hvdWxkIGJlIHNldCB0byAwIHVubGVzcyB0aGVyZSBpcyBh IG5ldyBzcGVjaWZpY2F0aW9uIHRoYXQgZ2l2ZXMgdGhlbSBtZWFuaW5nIHdoaWNoIGFmZmVjdHMg Ym90aCBzZW5kZXIgYW5kIHJlY2VpdmVyLg0KDQoNCj4gDQo+IFRoaXMgaXMgYSBSRkM1NTc1Ymlz IGRvY3VtZW50IGJhc2VkIHBhc3QgaGlzdG9yeSBvZiB0aGVzZQ0KPiBzdGF0ZW1lbnRzIGluIHJv dXRpbmcgY29kZS4NCltSV10NCkkgYWdyZWUsIGFuZCBJIGhhdmUgbm8gaW50ZW50aW9uIG9mIHVu ZHVseSBob2xkaW5nIHVwIGEgZG9jdW1lbnQsIGJ1dCBqdXN0IHdhbnQgdG8gY2hlY2sgdGhhdCB0 aGlzIGlzIGJlaW5nIGV4cHJlc3NlZCBpbiB0aGUgbW9zdCBjb3JyZWN0IGFuZCB1bmRlcnN0YW5k YWJsZSB3YXkuDQoNCg0KPiANCj4gSSd2ZSB0YWtlbiB0aGUgcmVtYWluZGVyIG9mIHlvdXIgY29t bWVudHMgYXMgZWRpdG9yaWFsIGNvbW1lbnRzLg0KPiBPdXIgYXV0aG9yaW5nIHRlYW0gbG9hZHMg dGhlc2UgY29tbWVudHMgaW50byBnaXRodWIsIGFuZCB5b3UgYXJlIHdlbGNvbWUNCj4gdG8NCj4g Q29udHJpYnV0ZSB0byB0aGUgcmVzb2x1dGlvbnMuDQpbUlddIA0KVGhhdCBzb3VuZHMgZmluZSwg dGhhbmsgeW91Lg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KPiANCj4gU3VzYW4gSGFyZXMNCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvYmVydCBXaWx0b24gdmlhIERh dGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gU2VudDogRnJpZGF5LCBBcHJp bCAyNCwgMjAyMCA1OjQ5IEFNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogZHJhZnQtaWV0Zi1pZHIt cmZjNTU3NWJpc0BpZXRmLm9yZzsgaWRyLWNoYWlyc0BpZXRmLm9yZzsgaWRyQGlldGYub3JnOw0K PiBKaWUgRG9uZzsgYXJldGFuYS5pZXRmQGdtYWlsLmNvbTsgamllLmRvbmdAaHVhd2VpLmNvbQ0K PiBTdWJqZWN0OiBSb2JlcnQgV2lsdG9uJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWlkci1yZmM1 NTc1YmlzLTIzOiAod2l0aA0KPiBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gUm9iZXJ0IFdp bHRvbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJh ZnQtaWV0Zi1pZHItcmZjNTU3NWJpcy0yMzogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiAN Cj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLXJmYzU1NzVi aXMvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiANCj4gSSBkb24ndCBrbm93IGlmIHRoaXMgaXMgYSB2YWxpZCBkaXNjdXNzIHBvaW50 LCBzbyBoYXBweSB0byBiZSBlZHVjYXRlZA0KPiB0aGF0IGl0IGlzIGFsd2F5cyB3cml0dGVuIHRo aXMgd2F5IGFuZCBJJ2xsIHJlbW92ZSBteSBkaXNjdXNzIC4uLg0KPiANCj4gSSBub3RlIHRoYXQg aW4gNSBwbGFjZXMgdGhpcyBkb2N1bWVudCBoYXMgdGV4dCB0aGF0IHN0YXRlcyB0aGUgZXF1aXZh bGVudA0KPiB0byAiU0hPVUxEIGJlIHNldCB0byAwIG9uIGVuY29kaW5nLCBhbmQgTVVTVCBiZSBp Z25vcmVkIGR1cmluZyBkZWNvZGluZy4iDQo+IChleGFtcGxlIGdpdmVuIGJlbG93KS4NCj4gDQo+ IERvZXNuJ3QgdGhpcyBtYWtlIGV4dGVuZGluZyB0aGlzIGluIGZ1dHVyZSBtb3JlIHJpc2t5IGJl Y2F1c2UgaWYgbmV3DQo+IG1lYW5pbmcgYXJlIGdpdmVuIHRvIHRoZXNlIGJpdHMgdGhlbiB0aGVy ZSBjb3VsZCBiZSBzZW5kZXJzIGFscmVhZHkNCj4gdHJhbnNtaXR0aW5nIG5vbiAwIHZhbHVlcyB3 aGljaCBhIHJlY2VpdmVyIG1pZ2h0IHRoZW4gbWlzaW50ZXJwcmV0Pw0KPiANCj4gSGVuY2UsIEkg d2FzIHN1cnByaXNlZCB0aGF0IHRoZSBjb25zdHJhaW50cyBkaWQgbm90IGFsc28gaW5jbHVkZSBh IE1VU1Qgb24NCj4gdGhlIGVuY29kaW5nIHNpZGUgKGkuZS4gYmUgc3RyaWN0IGluIHdoYXQgeW91 IHNlbmQgLi4uKSwgaS5lLiAiTVVTVCBiZSBzZXQNCj4gdG8gMCBvbiBlbmNvZGluZywgYW5kIE1V U1QgYmUgaWdub3JlZCBkdXJpbmcgZGVjb2RpbmcuIg0KPiANCj4gRXhhbXBsZToNCj4gICAgVGhl IGV4dGVuZGVkIGlzIGVuY29kZWQgYXMgZm9sbG93czoNCj4gDQo+ICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gICAg ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxDQo+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgICB8ICAgcmVzZXJ2ZWQgICAgfCAgIHJl c2VydmVkICAgIHwgICByZXNlcnZlZCAgICB8ICAgcmVzZXJ2ZWQgICAgfA0KPiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQo+ICAgICAgfCAgIHJlc2VydmVkICAgIHwgci58ICAgIERTQ1AgICB8DQo+ICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0KPiAgICAgICAgICAgIEZpZ3VyZSA2 OiBUcmFmZmljIE1hcmtpbmcgRXh0ZW5kZWQgQ29tbXVuaXR5IEVuY29kaW5nDQo+IA0KPiAgICBv ICBEU0NQOiBuZXcgRFNDUCB2YWx1ZSBmb3IgdGhlIHRyYW5zaXRpbmcgSVAgcGFja2V0Lg0KPiAN Cj4gICAgbyAgcmVzZXJ2ZWQsIHIuOiBTSE9VTEQgYmUgc2V0IHRvIDAgb24gZW5jb2RpbmcsIGFu ZCBNVVNUIGJlIGlnbm9yZWQNCj4gICAgICAgZHVyaW5nIGRlY29kaW5nLg0KPiANCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSGksDQo+IA0K PiBJIGFsc28gaGFkIGEgZmV3IG1pbm9yIGNvbW1lbnRzIG9uIHRoaXMgZG9jdW1lbnQ6DQo+IA0K PiA0LjEuICBMZW5ndGggRW5jb2RpbmcNCj4gDQo+ICAgIG8gIElmIHRoZSBOTFJJIGxlbmd0aCBp cyBzbWFsbGVyIHRoYW4gMjQwICgweGYwIGhleCkgb2N0ZXRzLCB0aGUNCj4gICAgICAgbGVuZ3Ro IGZpZWxkIGNhbiBiZSBlbmNvZGVkIGFzIGEgc2luZ2xlIG9jdGV0Lg0KPiANCj4gICAgbyAgT3Ro ZXJ3aXNlLCBpdCBpcyBlbmNvZGVkIGFzIGFuIGV4dGVuZGVkLWxlbmd0aCAyLW9jdGV0IHZhbHVl IGluDQo+ICAgICAgIHdoaWNoIHRoZSBtb3N0IHNpZ25pZmljYW50IG5pYmJsZSBvZiB0aGUgZmly c3Qgb2N0ZXQgaXMgYWxsIG9uZXMuDQo+IA0KPiBUaGlzIGRlc2NyaWJlcyB0aGUgZmlyc3Qgbmli YmxlIGluIGJpbmFyeSwgYW5kIHRoZW4gbGF0ZXIgaXQgaXMgc2hvd24gaW4NCj4gaGV4Lg0KPiBJ dCBtaWdodCBiZSBtb3JlIGNsZWFyIHRvIHdyaXRlIC4uLiBpbiB3aGljaCB0aGUgbW9zdCBzaWdu aWZpY2FudCBuaWJibGUNCj4gaGFzIHRoZSBoZXggdmFsdWUgMHhmLg0KPiANCj4gICAgSW4gRmln dXJlIDEgYWJvdmUsIHZhbHVlcyBsZXNzLXRoYW4gMjQwIGFyZSBlbmNvZGVkIHVzaW5nIHR3byBo ZXgNCj4gICAgZGlnaXRzICgweG5uKS4gIFZhbHVlcyBhYm92ZSAyMzkgYXJlIGVuY29kZWQgdXNp bmcgMyBoZXggZGlnaXRzDQo+ICAgICgweGZubm4pLiAgVGhlIGhpZ2hlc3QgdmFsdWUgdGhhdCBj YW4gYmUgcmVwcmVzZW50ZWQgd2l0aCB0aGlzDQo+ICAgIGVuY29kaW5nIGlzIDQwOTUuICBGb3Ig ZXhhbXBsZSB0aGUgbGVuZ3RoIHZhbHVlIG9mIDIzOSBpcyBlbmNvZGVkIGFzDQo+ICAgIDB4ZWYg KHNpbmdsZSBvY3RldCkgd2hpbGUgMjQwIGlzIGVuY29kZWQgYXMgMHhmMGYwICgyLW9jdGV0KS4N Cj4gDQo+IDQuMi4gIE5MUkkgVmFsdWUgRW5jb2RpbmcNCj4gDQo+ICAgIENvbXBvbmVudHMgTVVT VCBmb2xsb3cgc3RyaWN0IHR5cGUgb3JkZXJpbmcgYnkgaW5jcmVhc2luZyBudW1lcmljYWwNCj4g ICAgb3JkZXIuICBBIGdpdmVuIGNvbXBvbmVudCB0eXBlIG1heSAoZXhhY3RseSBvbmNlKSBvciBt YXkgbm90IGJlDQo+ICAgIHByZXNlbnQgaW4gdGhlIEZsb3cgU3BlY2lmaWNhdGlvbi4gIElmIHBy ZXNlbnQsIGl0IE1VU1QgcHJlY2VkZSBhbnkNCj4gICAgY29tcG9uZW50IG9mIGhpZ2hlciBudW1l cmljIHR5cGUgdmFsdWUuDQo+IA0KPiBJIHdhc24ndCBzdXJlLCBidXQgd29uZGVyaW5nIHdoZXRo ZXIgIm1heSAoZXhhY3RseSBvbmNlKSBvciBtYXkgbm90IGJlIg0KPiBzaG91bGQgYmUgIk1BWSAo ZXhhY3RseSBvbmNlKSBiZSI/DQo+IA0KPiBTdWU6ICAodHJlYXRpbmcgYXMgYSAiZWRpdG9yaWFs KQ0KPiANCj4gRG9lcyB0aGlzIHdvcmsgZm9yIHlvdT8NCj4gT2xkL0EgZ2l2ZW4gY29tcG9uZW50 IHR5cGUgbWF5IChleGFjdGx5IG9uY2UpIG9yIG1heSBub3QgYmUNCj4gcHJlc2VudCBpbiB0aGUg ZmxvdyBTcGVjaWZpY2F0aW9uLw0KPiANCj4gTmV3L0VhY2ggZ2l2ZW4gY29tcG9uZW50IHR5cGUg bWF5IG9yIG1heSBub3QgYmUgcHJlc2VudCBpbiB0aGUNCj4gRmxvdyBTcGVjaWZpY2F0aW9uLiAg SWYgYSB0eXBlIGlzIHByZXNlbnQsIGl0IG1heSBiZSBwcmVzZW50IG9ubHkgb25jZS4vDQo+IA0K PiANCj4gNS4xLiAgT3JkZXJpbmcgb2YgRmxvdyBTcGVjaWZpY2F0aW9ucw0KPiANCj4gICAgRm9y IGFsbCBvdGhlciBjb21wb25lbnQgdHlwZXMsIHVubGVzcyBvdGhlcndpc2Ugc3BlY2lmaWVkLCB0 aGUNCj4gICAgY29tcGFyaXNvbiBpcyBwZXJmb3JtZWQgYnkgY29tcGFyaW5nIHRoZSBjb21wb25l bnQgZGF0YSBhcyBhIGJpbmFyeQ0KPiAgICBzdHJpbmcgdXNpbmcgdGhlIG1lbWNtcCgpIGZ1bmN0 aW9uIGFzIGRlZmluZWQgYnkgW0lTT19JRUNfOTg5OV0uICBGb3INCj4gICAgc3RyaW5ncyB3aXRo IGVxdWFsIGxlbmd0aHMgdGhlIGxvd2VzdCBzdHJpbmcgKG1lbWNtcCkgaGFzIGhpZ2hlcg0KPiAg ICBwcmVjZWRlbmNlLiAgRm9yIHN0cmluZ3Mgb2YgZGlmZmVyZW50IGxlbmd0aHMsIHRoZSBjb21t b24gcHJlZml4IGlzDQo+ICAgIGNvbXBhcmVkLiAgSWYgdGhlIGNvbW1vbiBwcmVmaXggaXMgbm90 IGVxdWFsIHRoZSBzdHJpbmcgd2l0aCB0aGUNCj4gICAgbG93ZXN0IHByZWZpeCBoYXMgaGlnaGVy IHByZWNlZGVuY2UuICBJZiB0aGUgY29tbW9uIHByZWZpeCBpcyBlcXVhbCwNCj4gICAgdGhlIGxv bmdlc3Qgc3RyaW5nIGlzIGNvbnNpZGVyZWQgdG8gaGF2ZSBoaWdoZXIgcHJlY2VkZW5jZSB0aGFu IHRoZQ0KPiAgICBzaG9ydGVyIG9uZS4NCj4gDQo+IEkgdGhpbmsgdGhhdCB0aGUgaW50ZW5kZWQg Y29tcGFyaXNvbiBoZXJlIGlzIGNsZWFyLCBidXQgSSB3YXMgd29uZGVyaW5nDQo+IHdoZXRoZXIg dGhpcyB0ZXh0IHNob3VsZCBmbGFnIGVuZGlhbiBjb25jZXJucyBhdCBhbGwuICBFLmcuIGlmIHRo ZQ0KPiBjb21wb25lbnQgZGF0YSBoYXMgYmVlbiBzdG9yZWQgaW4gbWVtb3J5IGFuZCBhbnkgbnVt ZXJpYyB2YWx1ZXMgaGF2ZSBoYWQNCj4gZW5kaWFuIGNvbnZlcnNpb24gcGVyZm9ybWVkIG9uIHRo ZW0gdGhlbiBhIG5haXZlIG1lbWNtcCgpIGNvdWxkIGdpdmUgYQ0KPiBkaWZmZXJlbnQgYW5zd2Vy Lg0KPiANCj4gW1N1ZV06ICAodHJlYXRpbmcgYXMgYSAiZWRpdG9yaWFsKQ0KPiBJZiB5b3UgaGF2 ZSBhIHN1Z2dlc3Rpb24gb24gZW5kaWFuIHN0YXRlbWVudHMsIHBsZWFzZSBsZXQgdXMga25vdy4N Cj4gV2UgIHByb3ZpZGUgbGlua3MgdG8gZnJvbSBvdGhlciBCR1Agc3BlY2lmaWNhdGlvbnMgIGZv ciB0aGUgdHlwZXMuDQo+IEFwcGVuZGl4IEEgd2FzIGludGVuZGVkIHRvIHByb3ZpZGUgYW4gZXhh bXBsZSBvZiB0aGUgZmxvdyBydWxlIGNvbXBhcmlzb24uDQo+IERvIHlvdSB0aGluayB0aGlzIGhl bHBzPw0KPiANCj4gVGhlIGV4YW1wbGUgZW5jb2RpbmdzIGluIHNlY3Rpb24gNCB3ZXJlIGludGVu ZGVkIHRvIHByb3ZpZGUgZXhhbXBsZXMNCj4gZm9yIGltcGxlbWVudGVycy4NCj4gDQo+IA0KPiAN Cg0K From nobody Fri Apr 24 06:50:25 2020 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 B7EB23A0474; Fri, 24 Apr 2020 06:50:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158773622329.9749.4475217266475729122@ietfa.amsl.com> Date: Fri, 24 Apr 2020 06:50:23 -0700 Archived-At: Subject: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 13:50:24 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is clear, easy to read (I appreciated the given examples). Alas, due to overload of work, I had only a quick browse through the document with specific focus points and found nothing EXCEPT why having two different documents ? One for IPv4 (with the core elements of the protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than surprized to say the least... hence my DISCUSS... This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note to make a cluster of this document and draft-ietf-idr-flow-spec-v6 so that they are published together with adjacent RFC numbers. Merging the two documents would be preferred but I understand that this is more work (albeit a missed opportunity). Please find below a couple on non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also second Erik K.'s comment on non-TCP/UDP ports. From nobody Fri Apr 24 06:50:42 2020 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 CC3C33A08EC; Fri, 24 Apr 2020 06:50:33 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 QDQvri76FwzA; Fri, 24 Apr 2020 06:50:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C963A0D2B; Fri, 24 Apr 2020 06:50:32 -0700 (PDT) X-Envelope-To: grow@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 03ODoQKN087245 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2020 14:50:27 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: "Sriram, Kotikalapudi (Fed)" Cc: GROW WG , "idr@ietf.org" , "Hannachi, Lilia (IntlAssoc)" , "draft-heitz-idr-wklc@ietf.org" References: From: Nick Hilliard Message-ID: Date: Fri, 24 Apr 2020 14:50:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.13 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] [GROW] Measurements on Regular, Extended, and Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 13:50:40 -0000 Sriram, Kotikalapudi (Fed) wrote on 24/04/2020 14:14: > ** Question: Any insights why we don't see any ECs at all? ** possibilities: - there are many types of EC and router config grammar is implemented inconsistently across different platforms, and there's no guarantee that the grammar is capable of expressing anything other than the commoner types - they can't handle asn32:asn32, so there's no compelling reason to prefer them over rfc1997 communities. - the more common EC types already have specific meanings, e.g. RT/SOO/etc I've never seen them in the wild used for generic purposes. It's always rfc1997, or more recently LC. Nick From nobody Fri Apr 24 06:58:32 2020 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 D61823A041D; Fri, 24 Apr 2020 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 wbymxJgwkLER; Fri, 24 Apr 2020 06:58:23 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 C7BAD3A0C0F; Fri, 24 Apr 2020 06:58:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: =?utf-8?Q?'=C3=89ric_Vyncke'?= , "'The IESG'" Cc: , , References: <158773622329.9749.4475217266475729122@ietfa.amsl.com> In-Reply-To: <158773622329.9749.4475217266475729122@ietfa.amsl.com> Date: Fri, 24 Apr 2020 09:58:15 -0400 Message-ID: <012201d61a40$66f798e0$34e6caa0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQDH3wr1V03HAdKDI16OurUS47Z8OqqkwR/w X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 13:58:25 -0000 Eric: We have a rule in IDR to not submit this for publication until we have 2 = implementations. =20 We do not have 2 vendors who will indicate the v6 support is deployed. =20 The original document (RFC5575) did not have v6, and the IESG asked the = IDR group to work on the v6 draft.=20 The same authors have a v6 version of text in WG LC. We've call for = implementation reports and receive none on the v6.=20 If you would like to help us find v6 with Flow-specification = deployments, we would be happy to forward the v6 version to the IESG.=20 Our long term game-plan was one document with v4 and v6 support.=20 Sue Hares=20 (author and IDR co-chair) -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of =C3=89ric Vyncke = via Datatracker Sent: Friday, April 24, 2020 9:50 AM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org Subject: [Idr] =C3=89ric Vyncke's Discuss on = draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) =C3=89ric Vyncke has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is clear, = easy to read (I appreciated the given examples). Alas, due to overload of work, I had only a quick browse through the = document with specific focus points and found nothing EXCEPT why having = two different documents ? One for IPv4 (with the core elements of the = protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than surprized to say = the least... hence my DISCUSS... This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note = to make a cluster of this document and draft-ietf-idr-flow-spec-v6 so = that they are published together with adjacent RFC numbers. Merging the = two documents would be preferred but I understand that this is more work = (albeit a missed opportunity). Please find below a couple on non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -=C3=A9ric ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also second Erik K.'s comment on non-TCP/UDP ports. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Apr 24 07:01:51 2020 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 682703A0659 for ; Fri, 24 Apr 2020 07:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.923 X-Spam-Level: *** X-Spam-Status: No, score=3.923 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=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 dn9-opN0uM55 for ; Fri, 24 Apr 2020 07:01:48 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 84C303A0645 for ; Fri, 24 Apr 2020 07:01:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Fri, 24 Apr 2020 10:01:42 -0400 Message-ID: <012701d61a40$e29e69b0$a7db3d10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01D61A1F.5B8DB410" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdYaQMwvy2Eynv0WRwitQg6kEctbYQ== X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-flow-spec-v6-11.txt - has passed WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 14:01:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0128_01D61A1F.5B8DB410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings: The draft-ietf-idr-flow-spec-v6-11.txt has passed WG LC. This draft is waiting for 2 implementations so it will be placed in implementation wait. Cheerily, Susan Hares ------=_NextPart_000_0128_01D61A1F.5B8DB410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings: =

 

The draft-ietf-idr-flow-spec-v6-11.txt has passed WG = LC.  This draft is waiting for 2 implementations so it will be = placed in implementation wait.

 

Cheerily, = Susan Hares

------=_NextPart_000_0128_01D61A1F.5B8DB410-- From nobody Fri Apr 24 07:28:07 2020 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 B716C3A0755; Fri, 24 Apr 2020 07:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 oCCOGH4vF41P; Fri, 24 Apr 2020 07:27:56 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 CA7FE3A0746; Fri, 24 Apr 2020 07:27:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: =?utf-8?Q?'=C3=89ric_Vyncke'?= , "'The IESG'" Cc: , , References: <158773622329.9749.4475217266475729122@ietfa.amsl.com> <012201d61a40$66f798e0$34e6caa0$@ndzh.com> In-Reply-To: <012201d61a40$66f798e0$34e6caa0$@ndzh.com> Date: Fri, 24 Apr 2020 10:27:50 -0400 Message-ID: <015f01d61a44$8958e110$9c0aa330$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQDH3wr1V03HAdKDI16OurUS47Z8OgHGzLzpqpaROcA= X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 14:27:58 -0000 Eric: [author hat on]=20 My co-authors remind me that we have three manuals which indicate 4 = implementations (2 Cisco, 1 Huawei, 1 Arbor Networks), and it is = possible we have missed other flow specifications. =20 Cisco: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configurati= on/xe-16/irg-xe-16-book/C3PL-BGP-Flowspec-Client.html Arbor Networks Netscout=20 https://archive.nanog.org/sites/default/files/wed.general.trafficdiversio= n.serodio.10.pdf Huawei:=20 https://support.huawei.com/enterprise/en/doc/EDOC1100028534?section=3Dj03= 4&topicName=3Dconfiguring-dynamic-bgp-ipv6-flow-specification [Author hat off]=20 [WG co-chair hat on]=20 Our usual checking involves getting the interoperability details which = the IDR chairs (in my WG co-chair hat) has not received. So, the bottom = line is that this in process - but it is behind the v4. =20 The WG also has draft-ietf-idr-bgp-flowspec-oid-11.txt (for intra-AS = work) that updates the RFC5575bis has past WG LC. Large networks have = deployed this as well, and wished it rolled into RFC5575bis. =20 The WG desired to get something out the door to correct the inaccuracies = in RFC5575bis. =20 [WG co-chair hat on]=20 =20 We are glad to take instruction from the IESG regarding these drafts. =20 Sue Hares=20 -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Friday, April 24, 2020 9:58 AM To: '=C3=89ric Vyncke'; 'The IESG' Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org Subject: RE: [Idr] =C3=89ric Vyncke's Discuss on = draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Eric: We have a rule in IDR to not submit this for publication until we have 2 = implementations. =20 We do not have 2 vendors who will indicate the v6 support is deployed. =20 The original document (RFC5575) did not have v6, and the IESG asked the = IDR group to work on the v6 draft.=20 The same authors have a v6 version of text in WG LC. We've call for = implementation reports and receive none on the v6.=20 If you would like to help us find v6 with Flow-specification = deployments, we would be happy to forward the v6 version to the IESG.=20 Our long term game-plan was one document with v4 and v6 support.=20 Sue Hares=20 (author and IDR co-chair) -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of =C3=89ric Vyncke = via Datatracker Sent: Friday, April 24, 2020 9:50 AM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org Subject: [Idr] =C3=89ric Vyncke's Discuss on = draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) =C3=89ric Vyncke has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is clear, = easy to read (I appreciated the given examples). Alas, due to overload of work, I had only a quick browse through the = document with specific focus points and found nothing EXCEPT why having = two different documents ? One for IPv4 (with the core elements of the = protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than surprized to say = the least... hence my DISCUSS... This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note = to make a cluster of this document and draft-ietf-idr-flow-spec-v6 so = that they are published together with adjacent RFC numbers. Merging the = two documents would be preferred but I understand that this is more work = (albeit a missed opportunity). Please find below a couple on non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -=C3=A9ric ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also second Erik K.'s comment on non-TCP/UDP ports. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Apr 24 07:32:09 2020 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 DC9233A08B9 for ; Fri, 24 Apr 2020 07:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.624 X-Spam-Level: ** X-Spam-Status: No, score=2.624 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=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 ifXIi0wF7ZKT for ; Fri, 24 Apr 2020 07:32:04 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 7CA923A08B5 for ; Fri, 24 Apr 2020 07:32:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Fri, 24 Apr 2020 10:31:59 -0400 Message-ID: <016101d61a45$1d7e2440$587a6cc0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01D61A23.966E5900" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdYaRRy6bVI0MFGzRKipBAjY9uiYJg== X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-bgp-flowspec-oid-11 - has past WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 14:32:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0162_01D61A23.966E5900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings: draft-ietf-idr-bgp-flowspec-oid-11.txt has past WG last call. The shepherd would appreciate the co-authors providing implementation reports on the IDR wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implem entations Cheerily, Susan Hares Co-chair and shepherd ------=_NextPart_000_0162_01D61A23.966E5900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings: =

 

draft-ietf-idr-bgp-flowspec-oid-11.txt has past WG = last call.

 

The shepherd would appreciate the co-authors providing = implementation reports on the IDR wiki at:

 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-= bgp-flowspec-oid%20implementations

 

Cheerily, = Susan Hares

Co-chair and shepherd =

 

 

 

------=_NextPart_000_0162_01D61A23.966E5900-- From nobody Fri Apr 24 07:50:02 2020 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 3F4263A0986; Fri, 24 Apr 2020 07:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: idr@ietf.org, last-call@ietf.org, draft-ietf-idr-capabilities-registry-change.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158773980020.30877.3733079568668640715@ietfa.amsl.com> Reply-To: Kyle Rose Date: Fri, 24 Apr 2020 07:50:00 -0700 Archived-At: Subject: [Idr] Secdir last call review of draft-ietf-idr-capabilities-registry-change-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 14:50:01 -0000 Reviewer: Kyle Rose Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready. It describes a policy change regarding assignment of BGP capability codes, with no novel security implications. From nobody Fri Apr 24 08:04:50 2020 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 2E25B3A0A09; Fri, 24 Apr 2020 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 No_J65sU2hEN; Fri, 24 Apr 2020 08:04:45 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 9EC553A0A06; Fri, 24 Apr 2020 08:04:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Rob Wilton \(rwilton\)'" , "'The IESG'" , Cc: , , , "'Jie Dong'" References: <158772176873.17533.3566124086139075762@ietfa.amsl.com> <005f01d61a30$0cc55660$26500320$@ndzh.com> In-Reply-To: Date: Fri, 24 Apr 2020 11:04:18 -0400 Message-ID: <018801d61a49$a19f1320$e4dd3960$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHINDy2br9xeCeFuf7NVzp77Es8JAEbfDJhAkhyTeuoiQlMcA== X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 15:04:48 -0000 Rob:=20 Pulling your remaining question to the front: Your question is a good one:=20 But I don't understand why that means the=20 sender is a "SHOULD be 0" not a "MUST be 0"? This text is inherited from RFC5575.=20 Originally (which is not in any document)=20 this was set because prototype implementations of=20 RFC5575 had set it to a 1 during a rushed deployment.=20 =20 Whether these implementation still exist in the=20 smaller boxes boxes from major vendors - I do not know.=20 One of the habits of IDR is not to break existing BGP.=20 I was torn whether RFC5575bis state "MUST" and go on.=20 I left it at "SHOULD" because it is a BIS. =20 AFAIK the place this will change this is on the protocol testers.=20 Older boxes will break.=20 So that's the reasoning, and the author team was torn between=20 fixing the "SHOULD" to a "MUST" and breaking things.=20 Robert Razuk or other people on the IDR list might have additional = comments on this one.=20 Sue Hares=20 -----Original Message----- From: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]=20 Sent: Friday, April 24, 2020 9:44 AM To: Susan Hares; 'The IESG'; aretana.ietf@gmail.com Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org; 'Jie Dong' Subject: RE: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: = (with DISCUSS and COMMENT) Hi Susan, Thanks for the quick response and explanation. Please see inline ... > -----Original Message----- > From: Susan Hares > Sent: 24 April 2020 13:01 > To: Rob Wilton (rwilton) ; 'The IESG'=20 > > Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org;=20 > idr@ietf.org; 'Jie Dong' ; aretana.ietf@gmail.com > Subject: RE: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: > (with DISCUSS and COMMENT) >=20 > Robert: >=20 > Thank you for your question. I'm pulling the DISCUSS to the front. >=20 > The Discuss in the phrases: >=20 > "SHOULD be set to 0 on encoding, and MUST be ignored during decoding." >=20 > is actually language used in many past routing drafts for expansion=20 > purposes. [RW]=20 Yes. I appreciate that historical precedent holds a lot of weight. = Prior to my discuss I had tried to quickly find examples of this, but = was looking in the wrong documents. ;-) >=20 > The difficultly in deploying new code is in the partial deployments. > The "must be ignored" clause allows the transmitter to change to=20 > something besides zero. [RW] Yes, it is the partial deployments that is concerning me. But I don't understand why that means the sender is a "SHOULD be 0" not = a "MUST be 0"? In the interop case either sender or receiver could be upgraded, so why = the asymmetry? My understanding is that these fields should be set to 0 unless there is = a new specification that gives them meaning which affects both sender = and receiver. >=20 > This is a RFC5575bis document based past history of these statements=20 > in routing code. [RW] I agree, and I have no intention of unduly holding up a document, but = just want to check that this is being expressed in the most correct and = understandable way. >=20 > I've taken the remainder of your comments as editorial comments. > Our authoring team loads these comments into github, and you are=20 > welcome to Contribute to the resolutions. [RW] That sounds fine, thank you. Regards, Rob >=20 > Susan Hares >=20 > -----Original Message----- > From: Robert Wilton via Datatracker [mailto:noreply@ietf.org] > Sent: Friday, April 24, 2020 5:49 AM > To: The IESG > Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org;=20 > idr@ietf.org; Jie Dong; aretana.ietf@gmail.com; jie.dong@huawei.com > Subject: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23:=20 > (with DISCUSS and COMMENT) >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-idr-rfc5575bis-23: Discuss >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I don't know if this is a valid discuss point, so happy to be educated = > that it is always written this way and I'll remove my discuss ... >=20 > I note that in 5 places this document has text that states the=20 > equivalent to "SHOULD be set to 0 on encoding, and MUST be ignored = during decoding." > (example given below). >=20 > Doesn't this make extending this in future more risky because if new=20 > meaning are given to these bits then there could be senders already=20 > transmitting non 0 values which a receiver might then misinterpret? >=20 > Hence, I was surprised that the constraints did not also include a=20 > MUST on the encoding side (i.e. be strict in what you send ...), i.e.=20 > "MUST be set to 0 on encoding, and MUST be ignored during decoding." >=20 > Example: > The extended is encoded as follows: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | reserved | reserved | reserved | reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | reserved | r.| DSCP | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 6: Traffic Marking Extended Community Encoding >=20 > o DSCP: new DSCP value for the transiting IP packet. >=20 > o reserved, r.: SHOULD be set to 0 on encoding, and MUST be = ignored > during decoding. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hi, >=20 > I also had a few minor comments on this document: >=20 > 4.1. Length Encoding >=20 > o If the NLRI length is smaller than 240 (0xf0 hex) octets, the > length field can be encoded as a single octet. >=20 > o Otherwise, it is encoded as an extended-length 2-octet value in > which the most significant nibble of the first octet is all = ones. >=20 > This describes the first nibble in binary, and then later it is shown=20 > in hex. > It might be more clear to write ... in which the most significant=20 > nibble has the hex value 0xf. >=20 > In Figure 1 above, values less-than 240 are encoded using two hex > digits (0xnn). Values above 239 are encoded using 3 hex digits > (0xfnnn). The highest value that can be represented with this > encoding is 4095. For example the length value of 239 is encoded = as > 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). >=20 > 4.2. NLRI Value Encoding >=20 > Components MUST follow strict type ordering by increasing numerical > order. A given component type may (exactly once) or may not be > present in the Flow Specification. If present, it MUST precede any > component of higher numeric type value. >=20 > I wasn't sure, but wondering whether "may (exactly once) or may not = be" > should be "MAY (exactly once) be"? >=20 > Sue: (treating as a "editorial) >=20 > Does this work for you? > Old/A given component type may (exactly once) or may not be present in = > the flow Specification/ >=20 > New/Each given component type may or may not be present in the Flow=20 > Specification. If a type is present, it may be present only once./ >=20 >=20 > 5.1. Ordering of Flow Specifications >=20 > For all other component types, unless otherwise specified, the > comparison is performed by comparing the component data as a binary > string using the memcmp() function as defined by [ISO_IEC_9899]. = For > strings with equal lengths the lowest string (memcmp) has higher > precedence. For strings of different lengths, the common prefix is > compared. If the common prefix is not equal the string with the > lowest prefix has higher precedence. If the common prefix is = equal, > the longest string is considered to have higher precedence than the > shorter one. >=20 > I think that the intended comparison here is clear, but I was=20 > wondering whether this text should flag endian concerns at all. E.g.=20 > if the component data has been stored in memory and any numeric values = > have had endian conversion performed on them then a naive memcmp()=20 > could give a different answer. >=20 > [Sue]: (treating as a "editorial) > If you have a suggestion on endian statements, please let us know. > We provide links to from other BGP specifications for the types. > Appendix A was intended to provide an example of the flow rule = comparison. > Do you think this helps? >=20 > The example encodings in section 4 were intended to provide examples=20 > for implementers. >=20 >=20 >=20 From nobody Fri Apr 24 09:24:33 2020 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 58D023A0E2D; Fri, 24 Apr 2020 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.6 X-Spam-Level: X-Spam-Status: No, score=-14.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, 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 header.b=PYpW0btW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wMaBM+2s 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 68M6FYxH3T85; Fri, 24 Apr 2020 09:24:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47773A0E27; Fri, 24 Apr 2020 09:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14632; q=dns/txt; s=iport; t=1587745468; x=1588955068; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IAG4n4r2+cGUt52agHc6YiWK1iNlO7n3UPRUe0FS9LM=; b=PYpW0btWgi/BZhOOdycN0gHRGTBhVRR1eRLo+qHlqR9V9/WL2x2R+17Y vz/QKvtF5URsgzkGtQOGOND/mRzsvA44Ki9UKzPDzsKg4zWZzBQ8C3ct/ QPyv4A3NbW7wqHpyvjB8IiHql6UTXfDFebTa9O0ZPCu4e91YjOh7xxRUR A=; IronPort-PHdr: =?us-ascii?q?9a23=3A5w/ZPRDNeb1RFf29s9RxUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuHrazA9GuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAABFEqNe/4ENJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBPIEzBwEBCwGBUyQFKAVsWCAECyoKhBWDRgOEWYYXgl+BAYh1jjq?= =?us-ascii?q?BLhSBEANUCwEBAQwBASMKAgQBAYREAheCDyQ0CQ4CAwEBCwEBBQEBAQIBBQR?= =?us-ascii?q?thVYMhXEBAQEBAgESEREMAQE3AQsEAgEIDgMEAQEDAiMDAgICHxEUAQgIAgQ?= =?us-ascii?q?BDQUIDA6DBYJLAw4gAQMLpxsCgTmIYXaBMoMAAQEFgUZBgx8NC4IOAwaBDio?= =?us-ascii?q?BgmKJVhqBQT+BEUOCGDU+gh5JAgECAYEsARIBEhEVgnsygi2ONC0CglSfbDJ?= =?us-ascii?q?KCoJFiAyFdIU1BIRfglqIVpFBj3iJRYJDizCFRgIEAgQFAg4BAQWBUjlmWBE?= =?us-ascii?q?HcBU7gmlQGA2RNAwXFW4BCAGCQoUUhUJ0AjMCBggBAQMJfItpgTMBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,311,1583193600"; d="scan'208";a="750165430" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 16:24:27 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 03OGORwu008320 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2020 16:24:27 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 11:24:27 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 11:24:26 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Apr 2020 12:24:25 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N6qI7rX5KtypI95GroMdrhFjW1iSuD7ldm1ZrUwcrInC0TSCSdeDnPIYpUEswmxEGaA9g3tA4WBovVLhUYkJ3jWlii5zXoKNePqg7xkqAN5dgP+/xDFW4B2Phpbyd7KEA42rXljQCzfG3KjC1XB8MLgFNWtg6wsivsgXJAmzWCtFdyITN2Fcu82FZTI2URCK++3qXL4lryUQX04eMxhoAmI1NJTFPHU0SoqgIrZbIzEPiRolh3K18KeWfNibAisdeP2naYpXAl5UtT/qFo3wFoTXSdvDQaYr37gu/4dap5Sr12croKOpylF40SmAcTLroU76GzqEZcCqWScriGJaDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IAG4n4r2+cGUt52agHc6YiWK1iNlO7n3UPRUe0FS9LM=; b=HdAGbW1+lmrBqq529l8vfy23IUe0n5oWvoyNm47bOlww5n9hPYwdvthZK+T1fxJUdJC5fBp8HfCiyN20MsduM5C3VfvmKwTTyiwnbhx3v9QORZgDhEnzoO++YOur/Opf2DoCiXGyHee619+p3I7sAX3evgOVGnKSrA04zEk2coX4nRErZWut2FU2LjtZhOpq+43ZLg2Nxff+OadavGbgWH7E4bdCoLBwq/m/7gMjzptpfKhVll4kRqSdT9myjPwzJ+H4KsoODs7nqq+1UXLTlbkEV+dIXCwwCBX1Z4dgGsCYO+pCLhdC9AEjZzkGu6tl5rKSh/yS/Uf7EiGlfG0Iaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IAG4n4r2+cGUt52agHc6YiWK1iNlO7n3UPRUe0FS9LM=; b=wMaBM+2s8A43pB/1Esix+WoOV4z4NYpCKvYMmxWbUWn7ruyYk5dGyQYhi7hbAEyZXG6DItoMrfA4W1wC8rLhVlQp1EofADskELMblz1JgYj4Iu63csc8Ai7EC4uXOFzCAmgsQZKVv4SiyhT55OfzhjgN/W/jkUR8NphaEWAKYak= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB3933.namprd11.prod.outlook.com (2603:10b6:208:13d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Fri, 24 Apr 2020 16:24:24 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 16:24:24 +0000 From: "Rob Wilton (rwilton)" To: Susan Hares , "'The IESG'" , "aretana.ietf@gmail.com" CC: "draft-ietf-idr-rfc5575bis@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , "'Jie Dong'" Thread-Topic: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Thread-Index: AQHWGh3EsbZFlJO8wUqFD9efKbLE/6iIK9uAgAAA0GCAADJaAIAADjTw Date: Fri, 24 Apr 2020 16:24:24 +0000 Message-ID: References: <158772176873.17533.3566124086139075762@ietfa.amsl.com> <005f01d61a30$0cc55660$26500320$@ndzh.com> <018801d61a49$a19f1320$e4dd3960$@ndzh.com> In-Reply-To: <018801d61a49$a19f1320$e4dd3960$@ndzh.com> 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=rwilton@cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 518f014f-df6b-46d2-31e0-08d7e86bf3ba x-ms-traffictypediagnostic: MN2PR11MB3933: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(366004)(396003)(39860400002)(346002)(81156014)(7696005)(26005)(6506007)(71200400001)(53546011)(8676002)(4326008)(316002)(186003)(8936002)(966005)(33656002)(478600001)(86362001)(52536014)(76116006)(64756008)(9686003)(66476007)(66446008)(66556008)(66946007)(2906002)(5660300002)(54906003)(55016002)(110136005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NpTTfNXtOWchSXUn0g9qRXm3zyKGiyc5cYTESGlTduoxohHhgAS4UFxEhBdBKdD/q2MHxRNL7+0mLTRDrkfl85RIVWZTEvT9DRzRkOzAuJ0okOXdVMV+DsZD/izxCQwpDMpxygR/T9HnNVmYzQgOBGZI+dGlB4WKSJ6KRN0vpeWv25T6KB68ifNI0NUKjdOuUir8IQ7osAx7XxuAMl7RxuruJL/C+uokqiRgprfPAh6vz5s4u8HcIktZOHsoDsQcC9faurWItjUH9CuysEYY+/8RgW7Rl+PrqMhXMTTXpvew5XwAKJI/38wArXFsln8Uz+aCstgA/xm+YCJg/ixNFojR9FotTObiSD8GaTxkTDmwxBKhTCaQUtwGEZ5JhXgfDULb47Evk0n0f2AVmrs/zs0M1hLI1rrkOlwQ/nhBqA2xk5WfC7+asaTnETLQV070E13AxFr/ljEnjfhMdVvW1XGvyfAH4iULl2QGrdrud4stIxr+Mu/LT/CY1+lcvfudFVRQb7gupTsl6nOK4yvoQw== x-ms-exchange-antispam-messagedata: KLQLYKQ94COo1Khz5eXMHEpvpw/VUjoAU69eoB9/lF80YrsmMMmLgIafPqtOtYCqskMljLfaycygbtVjE8TzJqaoREav0lysqJOtpyh3W7TPLt0EaG0AIZ4YxD1uAujbr2rOWuzlQkzQTmWHq53+KQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 518f014f-df6b-46d2-31e0-08d7e86bf3ba X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 16:24:24.1716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XP0ZMagjUAajNRgRCu5gifu5IXMGRA8SKFrQkgzVx25uIctRsDD1E8/7H336ST/WCllDf7ActesZcX38rN1tig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3933 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 16:24:32 -0000 SGkgU3VlLA0KDQpXZSBkaXNjdXNzZWQgdGhpcyBpbiB0aGUgdGVsZWNoYXQgdG9kYXkuICBJIHRo aW5rIHRoYXQgQWx2YXJvIGludGVuZHMgdG8gY29tbWVudC4NCg0KUGxlYXNlIHNlZSBpbmxpbmUg Li4uDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdXNhbiBIYXJl cyA8c2hhcmVzQG5kemguY29tPg0KPiBTZW50OiAyNCBBcHJpbCAyMDIwIDE2OjA0DQo+IFRvOiBS b2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyAnVGhlIElFU0cnIDxpZXNn QGlldGYub3JnPjsNCj4gYXJldGFuYS5pZXRmQGdtYWlsLmNvbQ0KPiBDYzogZHJhZnQtaWV0Zi1p ZHItcmZjNTU3NWJpc0BpZXRmLm9yZzsgaWRyLWNoYWlyc0BpZXRmLm9yZzsgaWRyQGlldGYub3Jn Ow0KPiAnSmllIERvbmcnIDxqaWUuZG9uZ0BodWF3ZWkuY29tPg0KPiBTdWJqZWN0OiBSRTogUm9i ZXJ0IFdpbHRvbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pZHItcmZjNTU3NWJpcy0yMzoNCj4g KHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IFJvYjoNCj4gDQo+IFB1bGxpbmcgeW91 ciByZW1haW5pbmcgcXVlc3Rpb24gdG8gdGhlIGZyb250Og0KPiANCj4gWW91ciBxdWVzdGlvbiBp cyBhIGdvb2Qgb25lOg0KPiBCdXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGF0IG1lYW5zIHRo ZQ0KPiBzZW5kZXIgaXMgYSAiU0hPVUxEIGJlIDAiIG5vdCBhICJNVVNUIGJlIDAiPw0KPiANCj4g VGhpcyB0ZXh0IGlzIGluaGVyaXRlZCBmcm9tIFJGQzU1NzUuDQo+IA0KPiBPcmlnaW5hbGx5ICh3 aGljaCBpcyBub3QgaW4gYW55IGRvY3VtZW50KQ0KPiB0aGlzIHdhcyBzZXQgYmVjYXVzZSBwcm90 b3R5cGUgaW1wbGVtZW50YXRpb25zIG9mDQo+IFJGQzU1NzUgaGFkIHNldCBpdCB0byBhIDEgZHVy aW5nIGEgcnVzaGVkIGRlcGxveW1lbnQuDQo+IA0KPiBXaGV0aGVyIHRoZXNlIGltcGxlbWVudGF0 aW9uIHN0aWxsIGV4aXN0IGluIHRoZQ0KPiBzbWFsbGVyIGJveGVzIGJveGVzIGZyb20gbWFqb3Ig dmVuZG9ycyAtIEkgZG8gbm90IGtub3cuDQo+IA0KPiBPbmUgb2YgdGhlIGhhYml0cyBvZiBJRFIg aXMgbm90IHRvIGJyZWFrIGV4aXN0aW5nIEJHUC4NCltSV10gDQpZZXMsIGFuZCBJIGZ1bGx5IHN1 cHBvcnQgdGhhdCBwcmFnbWF0aWMgYWltLg0KDQoNCj4gDQo+IEkgd2FzIHRvcm4gd2hldGhlciBS RkM1NTc1YmlzIHN0YXRlICJNVVNUIiBhbmQgZ28gb24uDQo+IEkgbGVmdCBpdCBhdCAiU0hPVUxE IiBiZWNhdXNlIGl0IGlzIGEgQklTLg0KPiANCj4gQUZBSUsgdGhlIHBsYWNlIHRoaXMgd2lsbCBj aGFuZ2UgdGhpcyBpcyBvbiB0aGUgcHJvdG9jb2wgdGVzdGVycy4NCj4gT2xkZXIgYm94ZXMgd2ls bCBicmVhay4NCltSV10gDQpCdXQgdGhhdCBtaWdodCBiZSBhIGdvb2QgdGhpbmcsIHJpZ2h0PyAg SS5lLiBpZiB0aGUgcHJvdG9jb2wgdGVzdGVyIGZsYWdzIHVwIGltcGxlbWVudGF0aW9ucyB0aGF0 IGFyZSBzdGlsbCBzZXR0aW5nIHRoZXNlIHZhbHVlcyB0byAxIHJhdGhlciB0aGFuIDAgdGhlbiB0 aGV5IGNhbiBiZSBmaXhlZD8gIEhlbmNlIHJlZHVjaW5nIHRoZSByaXNrIG9mIGludGVyb3AgcHJv YmxlbXMgaWYgdGhlc2UgYml0cyBhcmUgZXZlciB1c2VkIGZvciBmdXR1cmUgZXh0ZW5zaW9ucy4N Cg0KPiANCj4gU28gdGhhdCdzIHRoZSByZWFzb25pbmcsIGFuZCB0aGUgYXV0aG9yIHRlYW0gd2Fz IHRvcm4gYmV0d2Vlbg0KPiBmaXhpbmcgdGhlICJTSE9VTEQiIHRvIGEgIk1VU1QiIGFuZCBicmVh a2luZyB0aGluZ3MuDQo+IA0KPiBSb2JlcnQgUmF6dWsgb3Igb3RoZXIgcGVvcGxlIG9uIHRoZSBJ RFIgbGlzdCBtaWdodCBoYXZlIGFkZGl0aW9uYWwNCj4gY29tbWVudHMgb24gdGhpcyBvbmUuDQo+ IA0KPiBTdWUgSGFyZXMNCltSV10gDQpSZWdhcmRzLA0KUm9iDQoNCj4gDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb2IgV2lsdG9uIChyd2lsdG9uKSBbbWFpbHRv OnJ3aWx0b25AY2lzY28uY29tXQ0KPiBTZW50OiBGcmlkYXksIEFwcmlsIDI0LCAyMDIwIDk6NDQg QU0NCj4gVG86IFN1c2FuIEhhcmVzOyAnVGhlIElFU0cnOyBhcmV0YW5hLmlldGZAZ21haWwuY29t DQo+IENjOiBkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzQGlldGYub3JnOyBpZHItY2hhaXJzQGll dGYub3JnOyBpZHJAaWV0Zi5vcmc7DQo+ICdKaWUgRG9uZycNCj4gU3ViamVjdDogUkU6IFJvYmVy dCBXaWx0b24ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXMtMjM6DQo+ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBTdXNhbiwNCj4gDQo+IFRoYW5rcyBm b3IgdGhlIHF1aWNrIHJlc3BvbnNlIGFuZCBleHBsYW5hdGlvbi4NCj4gDQo+IFBsZWFzZSBzZWUg aW5saW5lIC4uLg0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBG cm9tOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KPiA+IFNlbnQ6IDI0IEFwcmlsIDIw MjAgMTM6MDENCj4gPiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29t PjsgJ1RoZSBJRVNHJw0KPiA+IDxpZXNnQGlldGYub3JnPg0KPiA+IENjOiBkcmFmdC1pZXRmLWlk ci1yZmM1NTc1YmlzQGlldGYub3JnOyBpZHItY2hhaXJzQGlldGYub3JnOw0KPiA+IGlkckBpZXRm Lm9yZzsgJ0ppZSBEb25nJyA8amllLmRvbmdAaHVhd2VpLmNvbT47IGFyZXRhbmEuaWV0ZkBnbWFp bC5jb20NCj4gPiBTdWJqZWN0OiBSRTogUm9iZXJ0IFdpbHRvbidzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1pZHItcmZjNTU3NWJpcy0yMzoNCj4gPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0K PiA+DQo+ID4gUm9iZXJ0Og0KPiA+DQo+ID4gVGhhbmsgeW91IGZvciB5b3VyIHF1ZXN0aW9uLiAg IEknbSBwdWxsaW5nIHRoZSBESVNDVVNTIHRvIHRoZSBmcm9udC4NCj4gPg0KPiA+IFRoZSBEaXNj dXNzIGluIHRoZSBwaHJhc2VzOg0KPiA+DQo+ID4gIlNIT1VMRCBiZSBzZXQgdG8gMCBvbiBlbmNv ZGluZywgYW5kIE1VU1QgYmUgaWdub3JlZCBkdXJpbmcgZGVjb2RpbmcuIg0KPiA+DQo+ID4gaXMg YWN0dWFsbHkgbGFuZ3VhZ2UgdXNlZCBpbiBtYW55IHBhc3Qgcm91dGluZyBkcmFmdHMgZm9yIGV4 cGFuc2lvbg0KPiA+IHB1cnBvc2VzLg0KPiBbUlddDQo+IA0KPiBZZXMuIEkgYXBwcmVjaWF0ZSB0 aGF0IGhpc3RvcmljYWwgcHJlY2VkZW50IGhvbGRzIGEgbG90IG9mIHdlaWdodC4gIFByaW9yDQo+ IHRvIG15IGRpc2N1c3MgSSBoYWQgdHJpZWQgdG8gcXVpY2tseSBmaW5kIGV4YW1wbGVzIG9mIHRo aXMsIGJ1dCB3YXMNCj4gbG9va2luZyBpbiB0aGUgd3JvbmcgZG9jdW1lbnRzLiA7LSkNCj4gDQo+ IA0KPiA+DQo+ID4gVGhlIGRpZmZpY3VsdGx5IGluIGRlcGxveWluZyBuZXcgY29kZSBpcyBpbiB0 aGUgcGFydGlhbCBkZXBsb3ltZW50cy4NCj4gPiBUaGUgIm11c3QgYmUgaWdub3JlZCIgY2xhdXNl IGFsbG93cyB0aGUgdHJhbnNtaXR0ZXIgdG8gY2hhbmdlIHRvDQo+ID4gc29tZXRoaW5nIGJlc2lk ZXMgemVyby4NCj4gW1JXXQ0KPiBZZXMsIGl0IGlzIHRoZSBwYXJ0aWFsIGRlcGxveW1lbnRzIHRo YXQgaXMgY29uY2VybmluZyBtZS4NCj4gDQo+IEJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRo YXQgbWVhbnMgdGhlIHNlbmRlciBpcyBhICJTSE9VTEQgYmUgMCIgbm90IGENCj4gIk1VU1QgYmUg MCI/DQo+IA0KPiBJbiB0aGUgaW50ZXJvcCBjYXNlIGVpdGhlciBzZW5kZXIgb3IgcmVjZWl2ZXIg Y291bGQgYmUgdXBncmFkZWQsIHNvIHdoeQ0KPiB0aGUgYXN5bW1ldHJ5Pw0KPiANCj4gTXkgdW5k ZXJzdGFuZGluZyBpcyB0aGF0IHRoZXNlIGZpZWxkcyBzaG91bGQgYmUgc2V0IHRvIDAgdW5sZXNz IHRoZXJlIGlzIGENCj4gbmV3IHNwZWNpZmljYXRpb24gdGhhdCBnaXZlcyB0aGVtIG1lYW5pbmcg d2hpY2ggYWZmZWN0cyBib3RoIHNlbmRlciBhbmQNCj4gcmVjZWl2ZXIuDQo+IA0KPiANCj4gPg0K PiA+IFRoaXMgaXMgYSBSRkM1NTc1YmlzIGRvY3VtZW50IGJhc2VkIHBhc3QgaGlzdG9yeSBvZiB0 aGVzZSBzdGF0ZW1lbnRzDQo+ID4gaW4gcm91dGluZyBjb2RlLg0KPiBbUlddDQo+IEkgYWdyZWUs IGFuZCBJIGhhdmUgbm8gaW50ZW50aW9uIG9mIHVuZHVseSBob2xkaW5nIHVwIGEgZG9jdW1lbnQs IGJ1dCBqdXN0DQo+IHdhbnQgdG8gY2hlY2sgdGhhdCB0aGlzIGlzIGJlaW5nIGV4cHJlc3NlZCBp biB0aGUgbW9zdCBjb3JyZWN0IGFuZA0KPiB1bmRlcnN0YW5kYWJsZSB3YXkuDQo+IA0KPiANCj4g Pg0KPiA+IEkndmUgdGFrZW4gdGhlIHJlbWFpbmRlciBvZiB5b3VyIGNvbW1lbnRzIGFzIGVkaXRv cmlhbCBjb21tZW50cy4NCj4gPiBPdXIgYXV0aG9yaW5nIHRlYW0gbG9hZHMgdGhlc2UgY29tbWVu dHMgaW50byBnaXRodWIsIGFuZCB5b3UgYXJlDQo+ID4gd2VsY29tZSB0byBDb250cmlidXRlIHRv IHRoZSByZXNvbHV0aW9ucy4NCj4gW1JXXQ0KPiBUaGF0IHNvdW5kcyBmaW5lLCB0aGFuayB5b3Uu DQo+IA0KPiBSZWdhcmRzLA0KPiBSb2INCj4gDQo+IA0KPiA+DQo+ID4gU3VzYW4gSGFyZXMNCj4g Pg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUm9iZXJ0IFdpbHRv biB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0KPiA+IFNlbnQ6IEZy aWRheSwgQXByaWwgMjQsIDIwMjAgNTo0OSBBTQ0KPiA+IFRvOiBUaGUgSUVTRw0KPiA+IENjOiBk cmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzQGlldGYub3JnOyBpZHItY2hhaXJzQGlldGYub3JnOw0K PiA+IGlkckBpZXRmLm9yZzsgSmllIERvbmc7IGFyZXRhbmEuaWV0ZkBnbWFpbC5jb207IGppZS5k b25nQGh1YXdlaS5jb20NCj4gPiBTdWJqZWN0OiBSb2JlcnQgV2lsdG9uJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLTIzOg0KPiA+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQo+ID4NCj4gPiBSb2JlcnQgV2lsdG9uIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXMtMjM6IERpc2N1 c3MNCj4gPg0KPiA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+IHRoaXMgaW50cm9k dWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+IFBsZWFzZSByZWZlciB0 bw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuDQo+ID4NCj4gPg0KPiA+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0 aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLw0KPiA+ DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBESVNDVVNTOg0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPg0KPiA+IEkgZG9uJ3Qga25vdyBpZiB0aGlzIGlzIGEgdmFsaWQgZGlzY3VzcyBw b2ludCwgc28gaGFwcHkgdG8gYmUgZWR1Y2F0ZWQNCj4gPiB0aGF0IGl0IGlzIGFsd2F5cyB3cml0 dGVuIHRoaXMgd2F5IGFuZCBJJ2xsIHJlbW92ZSBteSBkaXNjdXNzIC4uLg0KPiA+DQo+ID4gSSBu b3RlIHRoYXQgaW4gNSBwbGFjZXMgdGhpcyBkb2N1bWVudCBoYXMgdGV4dCB0aGF0IHN0YXRlcyB0 aGUNCj4gPiBlcXVpdmFsZW50IHRvICJTSE9VTEQgYmUgc2V0IHRvIDAgb24gZW5jb2RpbmcsIGFu ZCBNVVNUIGJlIGlnbm9yZWQNCj4gZHVyaW5nIGRlY29kaW5nLiINCj4gPiAoZXhhbXBsZSBnaXZl biBiZWxvdykuDQo+ID4NCj4gPiBEb2Vzbid0IHRoaXMgbWFrZSBleHRlbmRpbmcgdGhpcyBpbiBm dXR1cmUgbW9yZSByaXNreSBiZWNhdXNlIGlmIG5ldw0KPiA+IG1lYW5pbmcgYXJlIGdpdmVuIHRv IHRoZXNlIGJpdHMgdGhlbiB0aGVyZSBjb3VsZCBiZSBzZW5kZXJzIGFscmVhZHkNCj4gPiB0cmFu c21pdHRpbmcgbm9uIDAgdmFsdWVzIHdoaWNoIGEgcmVjZWl2ZXIgbWlnaHQgdGhlbiBtaXNpbnRl cnByZXQ/DQo+ID4NCj4gPiBIZW5jZSwgSSB3YXMgc3VycHJpc2VkIHRoYXQgdGhlIGNvbnN0cmFp bnRzIGRpZCBub3QgYWxzbyBpbmNsdWRlIGENCj4gPiBNVVNUIG9uIHRoZSBlbmNvZGluZyBzaWRl IChpLmUuIGJlIHN0cmljdCBpbiB3aGF0IHlvdSBzZW5kIC4uLiksIGkuZS4NCj4gPiAiTVVTVCBi ZSBzZXQgdG8gMCBvbiBlbmNvZGluZywgYW5kIE1VU1QgYmUgaWdub3JlZCBkdXJpbmcgZGVjb2Rp bmcuIg0KPiA+DQo+ID4gRXhhbXBsZToNCj4gPiAgICBUaGUgZXh0ZW5kZWQgaXMgZW5jb2RlZCBh cyBmb2xsb3dzOg0KPiA+DQo+ID4gICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KPiA+ICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA+ICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gPiAgICAgIHwgICByZXNlcnZlZCAgICB8ICAgcmVzZXJ2ZWQgICAgfCAg IHJlc2VydmVkICAgIHwgICByZXNlcnZlZCAgICB8DQo+ID4gICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAg ICAgfCAgIHJlc2VydmVkICAgIHwgci58ICAgIERTQ1AgICB8DQo+ID4gICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPg0KPiA+ICAgICAgICAgICAgRmlndXJlIDY6IFRy YWZmaWMgTWFya2luZyBFeHRlbmRlZCBDb21tdW5pdHkgRW5jb2RpbmcNCj4gPg0KPiA+ICAgIG8g IERTQ1A6IG5ldyBEU0NQIHZhbHVlIGZvciB0aGUgdHJhbnNpdGluZyBJUCBwYWNrZXQuDQo+ID4N Cj4gPiAgICBvICByZXNlcnZlZCwgci46IFNIT1VMRCBiZSBzZXQgdG8gMCBvbiBlbmNvZGluZywg YW5kIE1VU1QgYmUgaWdub3JlZA0KPiA+ICAgICAgIGR1cmluZyBkZWNvZGluZy4NCj4gPg0KPiA+ DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENPTU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ DQo+ID4gSGksDQo+ID4NCj4gPiBJIGFsc28gaGFkIGEgZmV3IG1pbm9yIGNvbW1lbnRzIG9uIHRo aXMgZG9jdW1lbnQ6DQo+ID4NCj4gPiA0LjEuICBMZW5ndGggRW5jb2RpbmcNCj4gPg0KPiA+ICAg IG8gIElmIHRoZSBOTFJJIGxlbmd0aCBpcyBzbWFsbGVyIHRoYW4gMjQwICgweGYwIGhleCkgb2N0 ZXRzLCB0aGUNCj4gPiAgICAgICBsZW5ndGggZmllbGQgY2FuIGJlIGVuY29kZWQgYXMgYSBzaW5n bGUgb2N0ZXQuDQo+ID4NCj4gPiAgICBvICBPdGhlcndpc2UsIGl0IGlzIGVuY29kZWQgYXMgYW4g ZXh0ZW5kZWQtbGVuZ3RoIDItb2N0ZXQgdmFsdWUgaW4NCj4gPiAgICAgICB3aGljaCB0aGUgbW9z dCBzaWduaWZpY2FudCBuaWJibGUgb2YgdGhlIGZpcnN0IG9jdGV0IGlzIGFsbCBvbmVzLg0KPiA+ DQo+ID4gVGhpcyBkZXNjcmliZXMgdGhlIGZpcnN0IG5pYmJsZSBpbiBiaW5hcnksIGFuZCB0aGVu IGxhdGVyIGl0IGlzIHNob3duDQo+ID4gaW4gaGV4Lg0KPiA+IEl0IG1pZ2h0IGJlIG1vcmUgY2xl YXIgdG8gd3JpdGUgLi4uIGluIHdoaWNoIHRoZSBtb3N0IHNpZ25pZmljYW50DQo+ID4gbmliYmxl IGhhcyB0aGUgaGV4IHZhbHVlIDB4Zi4NCj4gPg0KPiA+ICAgIEluIEZpZ3VyZSAxIGFib3ZlLCB2 YWx1ZXMgbGVzcy10aGFuIDI0MCBhcmUgZW5jb2RlZCB1c2luZyB0d28gaGV4DQo+ID4gICAgZGln aXRzICgweG5uKS4gIFZhbHVlcyBhYm92ZSAyMzkgYXJlIGVuY29kZWQgdXNpbmcgMyBoZXggZGln aXRzDQo+ID4gICAgKDB4Zm5ubikuICBUaGUgaGlnaGVzdCB2YWx1ZSB0aGF0IGNhbiBiZSByZXBy ZXNlbnRlZCB3aXRoIHRoaXMNCj4gPiAgICBlbmNvZGluZyBpcyA0MDk1LiAgRm9yIGV4YW1wbGUg dGhlIGxlbmd0aCB2YWx1ZSBvZiAyMzkgaXMgZW5jb2RlZCBhcw0KPiA+ICAgIDB4ZWYgKHNpbmds ZSBvY3RldCkgd2hpbGUgMjQwIGlzIGVuY29kZWQgYXMgMHhmMGYwICgyLW9jdGV0KS4NCj4gPg0K PiA+IDQuMi4gIE5MUkkgVmFsdWUgRW5jb2RpbmcNCj4gPg0KPiA+ICAgIENvbXBvbmVudHMgTVVT VCBmb2xsb3cgc3RyaWN0IHR5cGUgb3JkZXJpbmcgYnkgaW5jcmVhc2luZyBudW1lcmljYWwNCj4g PiAgICBvcmRlci4gIEEgZ2l2ZW4gY29tcG9uZW50IHR5cGUgbWF5IChleGFjdGx5IG9uY2UpIG9y IG1heSBub3QgYmUNCj4gPiAgICBwcmVzZW50IGluIHRoZSBGbG93IFNwZWNpZmljYXRpb24uICBJ ZiBwcmVzZW50LCBpdCBNVVNUIHByZWNlZGUgYW55DQo+ID4gICAgY29tcG9uZW50IG9mIGhpZ2hl ciBudW1lcmljIHR5cGUgdmFsdWUuDQo+ID4NCj4gPiBJIHdhc24ndCBzdXJlLCBidXQgd29uZGVy aW5nIHdoZXRoZXIgIm1heSAoZXhhY3RseSBvbmNlKSBvciBtYXkgbm90IGJlIg0KPiA+IHNob3Vs ZCBiZSAiTUFZIChleGFjdGx5IG9uY2UpIGJlIj8NCj4gPg0KPiA+IFN1ZTogICh0cmVhdGluZyBh cyBhICJlZGl0b3JpYWwpDQo+ID4NCj4gPiBEb2VzIHRoaXMgd29yayBmb3IgeW91Pw0KPiA+IE9s ZC9BIGdpdmVuIGNvbXBvbmVudCB0eXBlIG1heSAoZXhhY3RseSBvbmNlKSBvciBtYXkgbm90IGJl IHByZXNlbnQgaW4NCj4gPiB0aGUgZmxvdyBTcGVjaWZpY2F0aW9uLw0KPiA+DQo+ID4gTmV3L0Vh Y2ggZ2l2ZW4gY29tcG9uZW50IHR5cGUgbWF5IG9yIG1heSBub3QgYmUgcHJlc2VudCBpbiB0aGUg Rmxvdw0KPiA+IFNwZWNpZmljYXRpb24uICBJZiBhIHR5cGUgaXMgcHJlc2VudCwgaXQgbWF5IGJl IHByZXNlbnQgb25seSBvbmNlLi8NCj4gPg0KPiA+DQo+ID4gNS4xLiAgT3JkZXJpbmcgb2YgRmxv dyBTcGVjaWZpY2F0aW9ucw0KPiA+DQo+ID4gICAgRm9yIGFsbCBvdGhlciBjb21wb25lbnQgdHlw ZXMsIHVubGVzcyBvdGhlcndpc2Ugc3BlY2lmaWVkLCB0aGUNCj4gPiAgICBjb21wYXJpc29uIGlz IHBlcmZvcm1lZCBieSBjb21wYXJpbmcgdGhlIGNvbXBvbmVudCBkYXRhIGFzIGEgYmluYXJ5DQo+ ID4gICAgc3RyaW5nIHVzaW5nIHRoZSBtZW1jbXAoKSBmdW5jdGlvbiBhcyBkZWZpbmVkIGJ5IFtJ U09fSUVDXzk4OTldLiAgRm9yDQo+ID4gICAgc3RyaW5ncyB3aXRoIGVxdWFsIGxlbmd0aHMgdGhl IGxvd2VzdCBzdHJpbmcgKG1lbWNtcCkgaGFzIGhpZ2hlcg0KPiA+ICAgIHByZWNlZGVuY2UuICBG b3Igc3RyaW5ncyBvZiBkaWZmZXJlbnQgbGVuZ3RocywgdGhlIGNvbW1vbiBwcmVmaXggaXMNCj4g PiAgICBjb21wYXJlZC4gIElmIHRoZSBjb21tb24gcHJlZml4IGlzIG5vdCBlcXVhbCB0aGUgc3Ry aW5nIHdpdGggdGhlDQo+ID4gICAgbG93ZXN0IHByZWZpeCBoYXMgaGlnaGVyIHByZWNlZGVuY2Uu ICBJZiB0aGUgY29tbW9uIHByZWZpeCBpcyBlcXVhbCwNCj4gPiAgICB0aGUgbG9uZ2VzdCBzdHJp bmcgaXMgY29uc2lkZXJlZCB0byBoYXZlIGhpZ2hlciBwcmVjZWRlbmNlIHRoYW4gdGhlDQo+ID4g ICAgc2hvcnRlciBvbmUuDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgdGhlIGludGVuZGVkIGNvbXBh cmlzb24gaGVyZSBpcyBjbGVhciwgYnV0IEkgd2FzDQo+ID4gd29uZGVyaW5nIHdoZXRoZXIgdGhp cyB0ZXh0IHNob3VsZCBmbGFnIGVuZGlhbiBjb25jZXJucyBhdCBhbGwuICBFLmcuDQo+ID4gaWYg dGhlIGNvbXBvbmVudCBkYXRhIGhhcyBiZWVuIHN0b3JlZCBpbiBtZW1vcnkgYW5kIGFueSBudW1l cmljIHZhbHVlcw0KPiA+IGhhdmUgaGFkIGVuZGlhbiBjb252ZXJzaW9uIHBlcmZvcm1lZCBvbiB0 aGVtIHRoZW4gYSBuYWl2ZSBtZW1jbXAoKQ0KPiA+IGNvdWxkIGdpdmUgYSBkaWZmZXJlbnQgYW5z d2VyLg0KPiA+DQo+ID4gW1N1ZV06ICAodHJlYXRpbmcgYXMgYSAiZWRpdG9yaWFsKQ0KPiA+IElm IHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBvbiBlbmRpYW4gc3RhdGVtZW50cywgcGxlYXNlIGxldCB1 cyBrbm93Lg0KPiA+IFdlICBwcm92aWRlIGxpbmtzIHRvIGZyb20gb3RoZXIgQkdQIHNwZWNpZmlj YXRpb25zICBmb3IgdGhlIHR5cGVzLg0KPiA+IEFwcGVuZGl4IEEgd2FzIGludGVuZGVkIHRvIHBy b3ZpZGUgYW4gZXhhbXBsZSBvZiB0aGUgZmxvdyBydWxlDQo+IGNvbXBhcmlzb24uDQo+ID4gRG8g eW91IHRoaW5rIHRoaXMgaGVscHM/DQo+ID4NCj4gPiBUaGUgZXhhbXBsZSBlbmNvZGluZ3MgaW4g c2VjdGlvbiA0IHdlcmUgaW50ZW5kZWQgdG8gcHJvdmlkZSBleGFtcGxlcw0KPiA+IGZvciBpbXBs ZW1lbnRlcnMuDQo+ID4NCj4gPg0KPiA+DQo+IA0KDQo= From nobody Fri Apr 24 09:54:59 2020 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 DD5DB3A0F8C; Fri, 24 Apr 2020 09:54:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Susan Hares , aretana.ietf@gmail.com, shares@ndzh.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <158774729288.14012.4297480673585471299@ietfa.amsl.com> Date: Fri, 24 Apr 2020 09:54:52 -0700 Archived-At: Subject: [Idr] Martin Duke's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 16:54:53 -0000 Martin Duke has entered the following ballot position for draft-ietf-idr-bgp-ls-segment-routing-msd-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is not a DISCUSS-level concern, but I found it odd that the Node MSD TLV must be the minimum of all configured interfaces without regard for the presence of any Link MSD TLVs. For example, if all node interfaces have an MSD of 20 except one with an MSD of 10, it would be much more compact to advertise a Node MSD of 20 and a single Link MSD of 10. Section 5 says the Link MSD would take precedence, so there would be no information loss. As I understand the spec, this would not be allowed, and each link would have to be advertised separately to gain that level of granularity. If this is not the intent, then in Section 3, extending a sentence to say "Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use, [excepting links advertised with their own Link MSD TLV]" would avoid the problem. From nobody Fri Apr 24 10:00:44 2020 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 5F6CE3A0EEF; Fri, 24 Apr 2020 10:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6TjSq0yId63b; Fri, 24 Apr 2020 10:00:30 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 097403A0EED; Fri, 24 Apr 2020 10:00:30 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id y24so11663544wma.4; Fri, 24 Apr 2020 10:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xmFQfZmw7gPEObq8eWzKBvPfg6wiDb1y8PmpbX/1Kus=; b=pwv4j22HzSOVFLRxSi+URetcxFi8Pj2XeDLFYR6thWrHFInR4cAdtzr+yzLgj2c4pH 7yJuOZaJreruuisKJ3O83AuT2jiMNatpNW43pV8Mif0HD8rSkYXNl0jevp5tKedeTSrK JIGUGqH0LevYsCd4gF5utis3BlS5vBKY/8JfjnThT0CO1boNcADd/buWA3255oJKW6lY 0FKYf7kbvmW/iTssC+Rgy7sJ1r6oaqMzOQvvr0XxpMfuEhYiVVVDdTvLCqEaPIyot1+D gKDJ13rOwgWTToQdRcSE9kcZ8WGzehcAWRFV+FHT+sOgzYuJj6KN7dPxJRer7w5ZA2lN 8a/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xmFQfZmw7gPEObq8eWzKBvPfg6wiDb1y8PmpbX/1Kus=; b=L5svOMPLQhkQeFu7NvHa5cqHKI+OJtHo8ZpXf4shckbaFMXlfkOijXWLg2Xuj/oe8o TmXP+1xKEk1wsWFTrgBZ2LQETch6ID29IuDxSA/hF34uHL5u9IzT+4kfz2bdaCEQLvLA fBxo0BNitpPnOJcU7OFFEg43fVLTK7RdXQhmRSs2VyvhTgCI+/0mYuw76jb2o0/Fn18/ tJdb5FENQH9ZA2/rCroxCgXGSrzfiy/cD78Zah2+reik3Nrb6YntAKriAIgSfjMet0pa YG1N+UArhuWEe71e226AyU1J247kITbnYESEDXbg+dI/o7SWBADtKAAGuhErfoGp7j1a vxSQ== X-Gm-Message-State: AGi0PuYEumrphpShUsgrt23ReCaohAtRztjHmIOlW2lE8CD7bYKY0tu1 UgqPM9mNRZBv9MpuduWmngVEbUJkKrl/dJcqjBk= X-Google-Smtp-Source: APiQypJWdSmFjTBmaT/hhRrXY+SI2o3VaRJGXQkjl80vHcdTKMsjN1BPJr5t6r2T1q+514IKqMkzXT+xeMxxD1wrU5M= X-Received: by 2002:a05:600c:28e:: with SMTP id 14mr11742162wmk.79.1587747628439; Fri, 24 Apr 2020 10:00:28 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 24 Apr 2020 10:00:27 -0700 From: Alvaro Retana In-Reply-To: References: <158772176873.17533.3566124086139075762@ietfa.amsl.com> <005f01d61a30$0cc55660$26500320$@ndzh.com> <018801d61a49$a19f1320$e4dd3960$@ndzh.com> MIME-Version: 1.0 Date: Fri, 24 Apr 2020 10:00:27 -0700 Message-ID: To: Susan Hares , "Rob Wilton (rwilton)" , Jie Dong Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-rfc5575bis@ietf.org" , "idr@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="00000000000062df8305a40c4d0e" Archived-At: Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 17:00:33 -0000 --00000000000062df8305a40c4d0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! As Rob mentioned, we talked about his DISCUSS during today=E2=80=99s IESG T= elechat. We=E2=80=99re all in agreement that the last thing we want to do is to brea= k any existing implementations, specially because this document is a bis. I looked at rfc5575, and I didn=E2=80=99t find the same text there =E2=80= =94 I found no specification of the setting of the bits, specially the reserved ones. [I also did a quick and unscientific search of other routing documents and found a mix of SHOULD/MUST and MUST/MUST constructs=E2=80=A6] Note that there are two distinct cases (in rfc5575bis): (1) A bit is defined as 0, but the definition is: "0 - SHOULD be set to 0=E2=80=A6=E2=80=9D (=C2=A74.2.1.1). If it=E2=80=99s 0, then I see no reas= on for that not to be a MUST. In fact, if always set to 0 we=E2=80=99re probably over specifying t= he field. There are 3 occurrences of this in the document. (2) Unused (=C2=A77.3) or reserved (=C2=A77.5) defined as "SHOULD be set to= 0...MUST be ignored=E2=80=9D. Again, if unused/reserved, I see no reason not to cha= nge to MUST. I think Rob makes a good point about extensibility. Before any changes, and in the spirit of not breaking anything, we should check whether anyone has an implementation what would be impacted. I assume/hope that the prototype implementations have already been fixed. Jie: As Shepherd, can you please do a quick poll of the people who reported implementations to confirm that these changes won=E2=80=99t have a= n impact? Thanks! Alvaro. On April 24, 2020 at 12:24:28 PM, Rob Wilton (rwilton) (rwilton@cisco.com) wrote: > Your question is a good one: > But I don't understand why that means the > sender is a "SHOULD be 0" not a "MUST be 0"? > > This text is inherited from RFC5575. > > Originally (which is not in any document) > this was set because prototype implementations of > RFC5575 had set it to a 1 during a rushed deployment. > > Whether these implementation still exist in the > smaller boxes boxes from major vendors - I do not know. > > One of the habits of IDR is not to break existing BGP. [RW] Yes, and I fully support that pragmatic aim. --00000000000062df8305a40c4d0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!

As Rob mentioned, we talked about his DISCUSS during today=E2= =80=99s IESG Telechat.

We=E2=80=99re all in agreement that the last thing we want to do is to = break any existing implementations, specially because this document is a bi= s.


I looked at rfc5575, an= d I didn=E2=80=99t find the same text there =E2=80=94 I found no specificat= ion of the setting of the bits, specially the reserved ones.

[I also did a quick and unscienti= fic search of other routing documents and found a mix of SHOULD/MUST and MU= ST/MUST constructs=E2=80=A6]


Note that there are two distinct cases (in rfc5575bis):

(1) A bit is defined as 0, but the= definition is: "0 - =C2=A0SHOULD be set to 0=E2=80=A6=E2=80=9D (=C2= =A74.2.1.1).=C2=A0 If it=E2=80=99s 0, then I see no reason for that not to = be a MUST.=C2=A0 In fact, if always set to 0 we=E2=80=99re probably over sp= ecifying the field. =C2=A0 There are 3 occurrences of this in the document.=

<= div style=3D"font-family:Helvetica,Arial;font-size:13px">(2) Unused (=C2=A7= 7.3) or reserved (=C2=A77.5) defined as "SHOULD be set to 0...MUST be = ignored=E2=80=9D.=C2=A0 Again, if unused/reserved, I see no reason not to c= hange to MUST.=C2=A0 I think Rob makes a good point about extensibility.


Before any changes, and in = the spirit of not breaking anything, we should check whether anyone has an = implementation what would be impacted.=C2=A0 I assume/hope that the prototy= pe implementations have already been fixed.

Jie: =C2=A0As Shepherd, can you please do a quick = poll of the people who reported implementations to confirm that these chang= es won=E2=80=99t have an impact? =C2=A0=C2=A0


Thanks!

Alvaro.




<= p class=3D"airmail_on">On April 24, 2020 at 12:24:28 PM, Rob Wilton (rwilto= n) (rwilton@cisco.com) wrote:

=
> Your question is a good one:=C2=A0
> But I don't understand why = that means the=C2=A0> sender is a "SHOULD be 0" not a "MUST be 0"?=C2=A0
>=C2=A0
> This text is inherited= from RFC5575.=C2=A0>=C2=A0
> Ori= ginally (which is not in any document)=C2=A0
> this was set because prototype implementati= ons of=C2=A0
> = RFC5575 had set it to a 1 during a rushed deployment.=C2=A0
>=C2=A0
> Whether these implementation still exis= t in the=C2=A0
> = smaller boxes boxes from major vendors - I do not know.=C2=A0
>=C2=A0
> One of the habits of IDR is not to br= eak existing BGP.=C2=A0=
[RW]=C2=A0
Yes, = and I fully support that pragmatic aim.=C2=A0
--00000000000062df8305a40c4d0e-- From nobody Fri Apr 24 10:34:04 2020 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 541A53A1030; Fri, 24 Apr 2020 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 hzW6qY3wr3No; Fri, 24 Apr 2020 10:33:55 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 DA7713A102F; Fri, 24 Apr 2020 10:33:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; SavedFromEmail: shares@ndzh.com Date: Fri, 24 Apr 2020 13:33:50 -0400 In-Reply-To: Importance: normal From: Susan Hares To: Alvaro Retana , "Rob Wilton (rwilton)" , Jie Dong Cc: "draft-ietf-idr-rfc5575bis@ietf.org" , "idr-chairs@ietf.org" , The IESG , "idr@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1038635470316780" Message-ID: <1587749630_176333@FUMC-WEB2> X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 17:33:58 -0000 ----_com.samsung.android.email_1038635470316780 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWx2YXJvVGhlIGF1dGhvciB0ZWFtIHdpbGwgY2hhbmdlIHRvIE1VU1QgcGVyIHlvdXIgY29tbWVu dHMuSSBrbm93IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIHRleHQgYW5kIEkga25vdyB0aGVyZSB3 ZXJlIHByb2JsZW1zLsKgIEdpdmVuIHRoZSBydXNoIG9uIHRoZSBmaXJzdCB2ZXJzaW9uLCBJIGtu b3cgdGhpbmdzIHdlcmUgZG93bi1wbGF5ZWQgc28gdGhlIHVyZ2VudCBwcm9ibGVtIGNvdWxkIGJl IGZpeGVkLsKgTXkgd2FybmluZyB0aGF0IHRoZSBiaXQgc2V0dGluZ3MgbWF5IGJlIGRlZXAgaW4g Y29kZSBhbmQgY3VycmVudCBwZW9wbGUgbWF5IGhhdmUgdHJvdWJsZSBmaW5kaW5nIGl0LlRoYXQg c2FpZCwgaXQgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLkRpZCB0aGUgaWVzZyB3YW50IGJ5IGlu IHNhbWUgZG9jdW1lbnQ/U3VlU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFM3IGVkZ2UsIGFu IEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LUZyb206IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+IERhdGU6IDQvMjQv MjAgIDE6MDAgUE0gIChHTVQtMDU6MDApIFRvOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29t PiwgIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+LCBKaWUgRG9uZyA8 amllLmRvbmdAaHVhd2VpLmNvbT4gQ2M6IGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXNAaWV0Zi5v cmcsIGlkci1jaGFpcnNAaWV0Zi5vcmcsIFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgaWRyQGll dGYub3JnIFN1YmplY3Q6IFJlOiBbSWRyXSBSb2JlcnQgV2lsdG9uJ3MgRGlzY3VzcyBvbiBkcmFm dC1pZXRmLWlkci1yZmM1NTc1YmlzLTIzOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKSBIaSFB cyBSb2IgbWVudGlvbmVkLCB3ZSB0YWxrZWQgYWJvdXQgaGlzIERJU0NVU1MgZHVyaW5nIHRvZGF5 4oCZcyBJRVNHIFRlbGVjaGF0Lldl4oCZcmUgYWxsIGluIGFncmVlbWVudCB0aGF0IHRoZSBsYXN0 IHRoaW5nIHdlIHdhbnQgdG8gZG8gaXMgdG8gYnJlYWsgYW55IGV4aXN0aW5nIGltcGxlbWVudGF0 aW9ucywgc3BlY2lhbGx5IGJlY2F1c2UgdGhpcyBkb2N1bWVudCBpcyBhIGJpcy5JIGxvb2tlZCBh dCByZmM1NTc1LCBhbmQgSSBkaWRu4oCZdCBmaW5kIHRoZSBzYW1lIHRleHQgdGhlcmUg4oCUIEkg Zm91bmQgbm8gc3BlY2lmaWNhdGlvbiBvZiB0aGUgc2V0dGluZyBvZiB0aGUgYml0cywgc3BlY2lh bGx5IHRoZSByZXNlcnZlZCBvbmVzLltJIGFsc28gZGlkIGEgcXVpY2sgYW5kIHVuc2NpZW50aWZp YyBzZWFyY2ggb2Ygb3RoZXIgcm91dGluZyBkb2N1bWVudHMgYW5kIGZvdW5kIGEgbWl4IG9mIFNI T1VMRC9NVVNUIGFuZCBNVVNUL01VU1QgY29uc3RydWN0c+KApl1Ob3RlIHRoYXQgdGhlcmUgYXJl IHR3byBkaXN0aW5jdCBjYXNlcyAoaW4gcmZjNTU3NWJpcyk6KDEpIEEgYml0IGlzIGRlZmluZWQg YXMgMCwgYnV0IHRoZSBkZWZpbml0aW9uIGlzOiAiMCAtIMKgU0hPVUxEIGJlIHNldCB0byAw4oCm 4oCdICjCpzQuMi4xLjEpLsKgIElmIGl04oCZcyAwLCB0aGVuIEkgc2VlIG5vIHJlYXNvbiBmb3Ig dGhhdCBub3QgdG8gYmUgYSBNVVNULsKgIEluIGZhY3QsIGlmIGFsd2F5cyBzZXQgdG8gMCB3ZeKA mXJlIHByb2JhYmx5IG92ZXIgc3BlY2lmeWluZyB0aGUgZmllbGQuIMKgIFRoZXJlIGFyZSAzIG9j Y3VycmVuY2VzIG9mIHRoaXMgaW4gdGhlIGRvY3VtZW50LigyKSBVbnVzZWQgKMKnNy4zKSBvciBy ZXNlcnZlZCAowqc3LjUpIGRlZmluZWQgYXMgIlNIT1VMRCBiZSBzZXQgdG8gMC4uLk1VU1QgYmUg aWdub3JlZOKAnS7CoCBBZ2FpbiwgaWYgdW51c2VkL3Jlc2VydmVkLCBJIHNlZSBubyByZWFzb24g bm90IHRvIGNoYW5nZSB0byBNVVNULsKgIEkgdGhpbmsgUm9iIG1ha2VzIGEgZ29vZCBwb2ludCBh Ym91dCBleHRlbnNpYmlsaXR5LkJlZm9yZSBhbnkgY2hhbmdlcywgYW5kIGluIHRoZSBzcGlyaXQg b2Ygbm90IGJyZWFraW5nIGFueXRoaW5nLCB3ZSBzaG91bGQgY2hlY2sgd2hldGhlciBhbnlvbmUg aGFzIGFuIGltcGxlbWVudGF0aW9uIHdoYXQgd291bGQgYmUgaW1wYWN0ZWQuwqAgSSBhc3N1bWUv aG9wZSB0aGF0IHRoZSBwcm90b3R5cGUgaW1wbGVtZW50YXRpb25zIGhhdmUgYWxyZWFkeSBiZWVu IGZpeGVkLkppZTogwqBBcyBTaGVwaGVyZCwgY2FuIHlvdSBwbGVhc2UgZG8gYSBxdWljayBwb2xs IG9mIHRoZSBwZW9wbGUgd2hvIHJlcG9ydGVkIGltcGxlbWVudGF0aW9ucyB0byBjb25maXJtIHRo YXQgdGhlc2UgY2hhbmdlcyB3b27igJl0IGhhdmUgYW4gaW1wYWN0PyDCoMKgVGhhbmtzIUFsdmFy by4gT24gQXByaWwgMjQsIDIwMjAgYXQgMTI6MjQ6MjggUE0sIFJvYiBXaWx0b24gKHJ3aWx0b24p IChyd2lsdG9uQGNpc2NvLmNvbSkgd3JvdGU6ID4gWW91ciBxdWVzdGlvbiBpcyBhIGdvb2Qgb25l OsKgPiBCdXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGF0IG1lYW5zIHRoZcKgPiBzZW5kZXIg aXMgYSAiU0hPVUxEIGJlIDAiIG5vdCBhICJNVVNUIGJlIDAiP8KgPsKgPiBUaGlzIHRleHQgaXMg aW5oZXJpdGVkIGZyb20gUkZDNTU3NS7CoD7CoD4gT3JpZ2luYWxseSAod2hpY2ggaXMgbm90IGlu IGFueSBkb2N1bWVudCnCoD4gdGhpcyB3YXMgc2V0IGJlY2F1c2UgcHJvdG90eXBlIGltcGxlbWVu dGF0aW9ucyBvZsKgPiBSRkM1NTc1IGhhZCBzZXQgaXQgdG8gYSAxIGR1cmluZyBhIHJ1c2hlZCBk ZXBsb3ltZW50LsKgPsKgPiBXaGV0aGVyIHRoZXNlIGltcGxlbWVudGF0aW9uIHN0aWxsIGV4aXN0 IGluIHRoZcKgPiBzbWFsbGVyIGJveGVzIGJveGVzIGZyb20gbWFqb3IgdmVuZG9ycyAtIEkgZG8g bm90IGtub3cuwqA+wqA+IE9uZSBvZiB0aGUgaGFiaXRzIG9mIElEUiBpcyBub3QgdG8gYnJlYWsg ZXhpc3RpbmcgQkdQLsKgW1JXXcKgWWVzLCBhbmQgSSBmdWxseSBzdXBwb3J0IHRoYXQgcHJhZ21h dGljIGFpbS7CoCA= ----_com.samsung.android.email_1038635470316780 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5BbHZhcm88L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRv Ij5UaGUgYXV0aG9yIHRlYW0gd2lsbCBjaGFuZ2UgdG8gTVVTVCBwZXIgeW91ciBjb21tZW50cy48 L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5JIGtub3cgdGhl cmUgaXMgbm90aGluZyBpbiB0aGUgdGV4dCBhbmQgSSBrbm93IHRoZXJlIHdlcmUgcHJvYmxlbXMu Jm5ic3A7IEdpdmVuIHRoZSBydXNoIG9uIHRoZSBmaXJzdCB2ZXJzaW9uLCBJIGtub3cgdGhpbmdz IHdlcmUgZG93bi1wbGF5ZWQgc28gdGhlIHVyZ2VudCBwcm9ibGVtIGNvdWxkIGJlIGZpeGVkLiZu YnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPk15IHdh cm5pbmcgdGhhdCB0aGUgYml0IHNldHRpbmdzIG1heSBiZSBkZWVwIGluIGNvZGUgYW5kIGN1cnJl bnQgcGVvcGxlIG1heSBoYXZlIHRyb3VibGUgZmluZGluZyBpdC48L2Rpdj48ZGl2IGRpcj0iYXV0 byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGF0IHNhaWQsIGl0IGlzIHRoZSByaWdodCB0 aGluZyB0byBkby48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRv Ij5EaWQgdGhlIGllc2cgd2FudCBieSBpbiBzYW1lIGRvY3VtZW50PzwvZGl2PjxkaXYgZGlyPSJh dXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlN1ZTwvZGl2PjxkaXYgZGlyPSJhdXRvIj48 YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwv ZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJl IiBkaXI9ImF1dG8iPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGly PSJhdXRvIj5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcgZWRnZSwgYW4gQVQmYW1wO1Qg NEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiIGRp cj0iYXV0byI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBBbHZhcm8gUmV0YW5hICZsdDthcmV0YW5h LmlldGZAZ21haWwuY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDQvMjQvMjAgIDE6MDAgUE0gIChH TVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IFN1c2FuIEhhcmVzICZsdDtzaGFyZXNAbmR6aC5jb20m Z3Q7LCAiUm9iIFdpbHRvbiAocndpbHRvbikiICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDssIEpp ZSBEb25nICZsdDtqaWUuZG9uZ0BodWF3ZWkuY29tJmd0OyA8L2Rpdj48ZGl2PkNjOiBkcmFmdC1p ZXRmLWlkci1yZmM1NTc1YmlzQGlldGYub3JnLCBpZHItY2hhaXJzQGlldGYub3JnLCBUaGUgSUVT RyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDssIGlkckBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6 IFJlOiBbSWRyXSBSb2JlcnQgV2lsdG9uJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWlkci1yZmM1 NTc1YmlzLTIzOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKSA8L2Rpdj48ZGl2Pjxicj48L2Rp dj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXpl OjEzcHgiPkhpITwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtm b250LXNpemU6MTNweCI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGlj YSxBcmlhbDtmb250LXNpemU6MTNweCI+QXMgUm9iIG1lbnRpb25lZCwgd2UgdGFsa2VkIGFib3V0 IGhpcyBESVNDVVNTIGR1cmluZyB0b2RheeKAmXMgSUVTRyBUZWxlY2hhdC48L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgiPjxicj48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgi Pldl4oCZcmUgYWxsIGluIGFncmVlbWVudCB0aGF0IHRoZSBsYXN0IHRoaW5nIHdlIHdhbnQgdG8g ZG8gaXMgdG8gYnJlYWsgYW55IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucywgc3BlY2lhbGx5IGJl Y2F1c2UgdGhpcyBkb2N1bWVudCBpcyBhIGJpcy48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJm b250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgiPjxicj48L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgiPkkgbG9v a2VkIGF0IHJmYzU1NzUsIGFuZCBJIGRpZG7igJl0IGZpbmQgdGhlIHNhbWUgdGV4dCB0aGVyZSDi gJQgSSBmb3VuZCBubyBzcGVjaWZpY2F0aW9uIG9mIHRoZSBzZXR0aW5nIG9mIHRoZSBiaXRzLCBz cGVjaWFsbHkgdGhlIHJlc2VydmVkIG9uZXMuPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij5bSSBhbHNvIGRpZCBhIHF1 aWNrIGFuZCB1bnNjaWVudGlmaWMgc2VhcmNoIG9mIG90aGVyIHJvdXRpbmcgZG9jdW1lbnRzIGFu ZCBmb3VuZCBhIG1peCBvZiBTSE9VTEQvTVVTVCBhbmQgTVVTVC9NVVNUIGNvbnN0cnVjdHPigKZd PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZTox M3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2Zv bnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh LEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij5Ob3RlIHRoYXQgdGhlcmUgYXJlIHR3byBkaXN0aW5jdCBj YXNlcyAoaW4gcmZjNTU3NWJpcyk6PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0 aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij4oMSkgQSBiaXQgaXMgZGVmaW5lZCBh cyAwLCBidXQgdGhlIGRlZmluaXRpb24gaXM6ICIwIC0gJm5ic3A7U0hPVUxEIGJlIHNldCB0byAw 4oCm4oCdICjCpzQuMi4xLjEpLiZuYnNwOyBJZiBpdOKAmXMgMCwgdGhlbiBJIHNlZSBubyByZWFz b24gZm9yIHRoYXQgbm90IHRvIGJlIGEgTVVTVC4mbmJzcDsgSW4gZmFjdCwgaWYgYWx3YXlzIHNl dCB0byAwIHdl4oCZcmUgcHJvYmFibHkgb3ZlciBzcGVjaWZ5aW5nIHRoZSBmaWVsZC4gJm5ic3A7 IFRoZXJlIGFyZSAzIG9jY3VycmVuY2VzIG9mIHRoaXMgaW4gdGhlIGRvY3VtZW50LjwvZGl2Pjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweCI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6 MTNweCI+KDIpIFVudXNlZCAowqc3LjMpIG9yIHJlc2VydmVkICjCpzcuNSkgZGVmaW5lZCBhcyAi U0hPVUxEIGJlIHNldCB0byAwLi4uTVVTVCBiZSBpZ25vcmVk4oCdLiZuYnNwOyBBZ2FpbiwgaWYg dW51c2VkL3Jlc2VydmVkLCBJIHNlZSBubyByZWFzb24gbm90IHRvIGNoYW5nZSB0byBNVVNULiZu YnNwOyBJIHRoaW5rIFJvYiBtYWtlcyBhIGdvb2QgcG9pbnQgYWJvdXQgZXh0ZW5zaWJpbGl0eS48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEz cHgiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9u dC1zaXplOjEzcHgiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2Es QXJpYWw7Zm9udC1zaXplOjEzcHgiPkJlZm9yZSBhbnkgY2hhbmdlcywgYW5kIGluIHRoZSBzcGly aXQgb2Ygbm90IGJyZWFraW5nIGFueXRoaW5nLCB3ZSBzaG91bGQgY2hlY2sgd2hldGhlciBhbnlv bmUgaGFzIGFuIGltcGxlbWVudGF0aW9uIHdoYXQgd291bGQgYmUgaW1wYWN0ZWQuJm5ic3A7IEkg YXNzdW1lL2hvcGUgdGhhdCB0aGUgcHJvdG90eXBlIGltcGxlbWVudGF0aW9ucyBoYXZlIGFscmVh ZHkgYmVlbiBmaXhlZC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJp YWw7Zm9udC1zaXplOjEzcHgiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2 ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgiPkppZTogJm5ic3A7QXMgU2hlcGhlcmQsIGNhbiB5 b3UgcGxlYXNlIGRvIGEgcXVpY2sgcG9sbCBvZiB0aGUgcGVvcGxlIHdobyByZXBvcnRlZCBpbXBs ZW1lbnRhdGlvbnMgdG8gY29uZmlybSB0aGF0IHRoZXNlIGNoYW5nZXMgd29u4oCZdCBoYXZlIGFu IGltcGFjdD8gJm5ic3A7Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0 aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij5UaGFua3MhPC9kaXY+ PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48 YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6 ZToxM3B4Ij5BbHZhcm8uPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFy aWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVs dmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+PC9kaXY+ IDxicj48cCBjbGFzcz0iYWlybWFpbF9vbiI+T24gQXByaWwgMjQsIDIwMjAgYXQgMTI6MjQ6Mjgg UE0sIFJvYiBXaWx0b24gKHJ3aWx0b24pICg8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5j b20iPnJ3aWx0b25AY2lzY28uY29tPC9hPikgd3JvdGU6PC9wPiA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iY2xlYW5fYnEiPjxzcGFuPjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigw LDAsMCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0 cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0 Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVu dDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5n OjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7ZGlzcGxheTppbmxpbmUhaW1w b3J0YW50O2Zsb2F0Om5vbmUiPiZndDsgWW91ciBxdWVzdGlvbiBpcyBhIGdvb2Qgb25lOjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyIHN0 eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0 aWNhO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9y bWFsO3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQt ZmFtaWx5OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNhO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5 bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0 dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQt dHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dy b3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpO2Rpc3BsYXk6aW5saW5lIWltcG9ydGFudDtmbG9h dDpub25lIj4mZ3Q7IEJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoYXQgbWVhbnMgdGhlPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIg c3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2 ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpu b3JtYWw7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9u dC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1z dHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts ZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNr Z3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7ZGlzcGxheTppbmxpbmUhaW1wb3J0YW50O2Zs b2F0Om5vbmUiPiZndDsgc2VuZGVyIGlzIGEgIlNIT1VMRCBiZSAwIiBub3QgYSAiTVVTVCBiZSAw Ij88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxiciBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTonaGVsdmV0aWNhIE5ldWUn LGhlbHZldGljYTtmb250LXNpemU6MTRweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNw YWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCww KTtmb250LWZhbWlseTonaGVsdmV0aWNhIE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9y bWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBw eDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTtkaXNwbGF5OmlubGluZSFpbXBvcnRh bnQ7ZmxvYXQ6bm9uZSI+Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PGJyIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5 OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNhO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9y bWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNw YWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNm b3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNh O2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFs O3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpO2Rpc3Bs YXk6aW5saW5lIWltcG9ydGFudDtmbG9hdDpub25lIj4mZ3Q7IFRoaXMgdGV4dCBpcyBpbmhlcml0 ZWQgZnJvbSBSRkM1NTc1LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PGJyIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5Oido ZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNhO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFs O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNp bmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3Jt Om5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJj b2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNhO2Zv bnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtm b250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dv cmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpO2Rpc3BsYXk6 aW5saW5lIWltcG9ydGFudDtmbG9hdDpub25lIj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9ImNvbG9yOnJnYigwLDAs MCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7 Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5v cm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDow cHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBw eCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBO ZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0 ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUs MjU1LDI1NSk7ZGlzcGxheTppbmxpbmUhaW1wb3J0YW50O2Zsb2F0Om5vbmUiPiZndDsgT3JpZ2lu YWxseSAod2hpY2ggaXMgbm90IGluIGFueSBkb2N1bWVudCk8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iY29sb3I6cmdiKDAs MCwwKTtmb250LWZhbWlseTonaGVsdmV0aWNhIE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRw eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6 MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTonaGVsdmV0aWNh IE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3do aXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1 NSwyNTUsMjU1KTtkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQ7ZmxvYXQ6bm9uZSI+Jmd0OyB0aGlz IHdhcyBzZXQgYmVjYXVzZSBwcm90b3R5cGUgaW1wbGVtZW50YXRpb25zIG9mPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9ImNv bG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9u dC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2Zv bnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0 ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6 J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3Bh Y2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zv cm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNv bG9yOnJnYigyNTUsMjU1LDI1NSk7ZGlzcGxheTppbmxpbmUhaW1wb3J0YW50O2Zsb2F0Om5vbmUi PiZndDsgUkZDNTU3NSBoYWQgc2V0IGl0IHRvIGEgMSBkdXJpbmcgYSBydXNoZWQgZGVwbG95bWVu dC48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxiciBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTonaGVsdmV0aWNhIE5ldWUn LGhlbHZldGljYTtmb250LXNpemU6MTRweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNw YWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCww KTtmb250LWZhbWlseTonaGVsdmV0aWNhIE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9y bWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBw eDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTtkaXNwbGF5OmlubGluZSFpbXBvcnRh bnQ7ZmxvYXQ6bm9uZSI+Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PGJyIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5 OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNhO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9y bWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNw YWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNm b3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNh O2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFs O3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpO2Rpc3Bs YXk6aW5saW5lIWltcG9ydGFudDtmbG9hdDpub25lIj4mZ3Q7IFdoZXRoZXIgdGhlc2UgaW1wbGVt ZW50YXRpb24gc3RpbGwgZXhpc3QgaW4gdGhlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9u dC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1z dHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts ZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+PHNw YW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxo ZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFj ZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1 NSk7ZGlzcGxheTppbmxpbmUhaW1wb3J0YW50O2Zsb2F0Om5vbmUiPiZndDsgc21hbGxlciBib3hl cyBib3hlcyBmcm9tIG1ham9yIHZlbmRvcnMgLSBJIGRvIG5vdCBrbm93LjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyIHN0eWxlPSJjb2xv cjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OidoZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNhO2ZvbnQt c2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5Oido ZWx2ZXRpY2EgTmV1ZScsaGVsdmV0aWNhO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFs O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNp bmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3Jt Om5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xv cjpyZ2IoMjU1LDI1NSwyNTUpO2Rpc3BsYXk6aW5saW5lIWltcG9ydGFudDtmbG9hdDpub25lIj4m Z3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48YnIgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVl JyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1z cGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAs MCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7 Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5v cm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDow cHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBw eDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7ZGlzcGxheTppbmxpbmUhaW1wb3J0 YW50O2Zsb2F0Om5vbmUiPiZndDsgT25lIG9mIHRoZSBoYWJpdHMgb2YgSURSIGlzIG5vdCB0byBi cmVhayBleGlzdGluZyBCR1AuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6 J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3Bh Y2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zv cm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9 ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6J2hlbHZldGljYSBOZXVlJyxoZWx2ZXRpY2E7 Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7 d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7ZGlzcGxh eTppbmxpbmUhaW1wb3J0YW50O2Zsb2F0Om5vbmUiPltSV108c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iY29sb3I6cmdiKDAs MCwwKTtmb250LWZhbWlseTonaGVsdmV0aWNhIE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRw eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6 MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTonaGVsdmV0aWNh IE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3do aXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1 NSwyNTUsMjU1KTtkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQ7ZmxvYXQ6bm9uZSI+WWVzLCBhbmQg SSBmdWxseSBzdXBwb3J0IHRoYXQgcHJhZ21hdGljIGFpbS48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iY29sb3I6cmdiKDAs MCwwKTtmb250LWZhbWlseTonaGVsdmV0aWNhIE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRw eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6 MHB4Ij48L2Rpdj48L3NwYW4+PC9ibG9ja3F1b3RlPiA8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1 cmUiPjwvZGl2PjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_1038635470316780-- From nobody Fri Apr 24 10:41:51 2020 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 04F693A1074; Fri, 24 Apr 2020 10:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vjhXBnQAEzXH; Fri, 24 Apr 2020 10:41:19 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 11DAE3A1064; Fri, 24 Apr 2020 10:41:19 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id x17so11161222wrt.5; Fri, 24 Apr 2020 10:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=vLcBUIMfgsnl7CAj+d/SxAFNvzAenMHgS79Tn1Vlo4o=; b=jTb9V6kjKGU+PT6YegsevMihFcy/A7g58gDD6/hMhmcDQNiYJCCWfAz85Rb3ivoA2H j3GDLcnDSfA/3DiaKp6SiWd4Plc+9TcRuDMGG6xFKrKZ8e9IohY0QFOlFvD34uxzdNX9 lPtQcibelTgBsyAaWwPi/xHgtp4cVgdR3bjxgFxSpujg0JIS0RvHPsuDqvflkflGnIxJ NykFS4HeckLpIUAOZX+TtHTn1jM6ER3chnvRWgjBKIMR++dAD6OVpem8GohmMhAX2R30 Vqq5h9p/WzUgu1fbjM1pLsReKrnFquJ5ntlzDp8RCV7075rQa8QhvIDBHli7vRcdbUAj L5+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=vLcBUIMfgsnl7CAj+d/SxAFNvzAenMHgS79Tn1Vlo4o=; b=EDkCnwgQFVeK2xEN8EWr7Qsgdmn/kHQZfIm/WcSk7pPIZlc87E2ds6+Lrg8ho7O5Qb wMgsz0YDI7YnmeQFSojMjqGCExzOUr7zWLbizbTBFvO4RMlFu2XRBSe3yk5lOgaE3dgd +aql3zWTxms+FjpzBmEm4BdoVgIzCqKTNjCpNAuzCikSjKvAxeBM/RXn4bAe9xdcAdqv 3H2LRc/7XnuSNo5x8DoWrNw/fJlVsmDgUggZ+j5+dzW3s2/dhNyrcfiWfjPV2pMRGKZA 3kNS6j3qNtiU9gcAhBcKPor+CFYBBy6CpAb5QHoLhTPkkofGWZtb29z30T7EgLu0tdJQ bBYQ== X-Gm-Message-State: AGi0PubFXHocF4FZmny40N+Jxmh3wW5lSZOXk0JyrGwlSysI29tICsW0 yA8ayLMXPgZ13Hb77YSLmG2kWzI2cotXvJnDKSYRLKWb X-Google-Smtp-Source: APiQypIaAsCeyyCFd/AloJ3230oyuJ4QOd7BEVZwb1UIDj4wGYlb70ISWhSg1SOESrXkkhXnGBShabvFZ9aCl1tJ5QE= X-Received: by 2002:adf:9168:: with SMTP id j95mr11780473wrj.145.1587750077206; Fri, 24 Apr 2020 10:41:17 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 24 Apr 2020 10:41:16 -0700 From: Alvaro Retana In-Reply-To: <158773622329.9749.4475217266475729122@ietfa.amsl.com> References: <158773622329.9749.4475217266475729122@ietfa.amsl.com> MIME-Version: 1.0 Date: Fri, 24 Apr 2020 10:41:16 -0700 Message-ID: To: =?UTF-8?Q?=C3=89ric_Vyncke_via_Datatracker?= , =?UTF-8?B?w4lyaWMgVnluY2tl?= , The IESG Cc: idr-chairs@ietf.org, draft-ietf-idr-rfc5575bis@ietf.org, Jie Dong , idr@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 17:41:26 -0000 Eric: Hi! I appreciate all your hard work on making sure that IPv6 is always consider= ed. However, I disagree with your request. (1) IPv6 has been considered. The WG has completed the work on FlowSpec for =C2=A0 =C2=A0 IPv6 =E2=80=94 it is just waiting for implementation reports.= [Sue already updated =C2=A0 =C2=A0 the tracking page. [1]] (2) By requiring joint publication, you are effectively overturning the WG =C2=A0 =C2=A0 consensus to clean rfc5575 up and leave new functionality to = new =C2=A0 =C2=A0 documents. As Sue already mentioned, the IPv6 functionality i= s not the =C2=A0 =C2=A0 only document that depends on this base =E2=80=94 so we would= be delaying =C2=A0 =C2=A0 that publication too (because of the Normative reference). (3) This document already contains a reference to the IPv6 document. That w= ill =C2=A0 =C2=A0 be more effective than requiring adjacent RFC numbers. It is = not always =C2=A0 =C2=A0 the case where documents in the same cluster receive adjacent= RFC numbers. (4) This request is not aligned with the DISCUSS Criteria [2]. Having said all that, I am willing to prioritize my review of the IPv6 document (when the WG requests publication), and would not oppose a request to the RFC Editor for expedited processing in order to get an RFC number assigned before rfc5575bis is published. =C2=A0I think this is reasonable considering the time it may take the document to reach AUTH48. Thanks! Alvaro. [1] https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-flow-spec-v6%20imple= mentations [2] https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria= / On April 24, 2020 at 9:50:24 AM, =C3=89ric Vyncke via Datatracker (noreply@ietf.org(mailto:noreply@ietf.org)) wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. The document is clear, eas= y to > read (I appreciated the given examples). > > Alas, due to overload of work, I had only a quick browse through the docu= ment > with specific focus points and found nothing EXCEPT why having two differ= ent > documents ? One for IPv4 (with the core elements of the protocol) and one= for > IPv6 (with only the IPv6 specifics)... I am more than surprized to say th= e > least... hence my DISCUSS... > > This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note t= o > make a cluster of this document and draft-ietf-idr-flow-spec-v6 so that t= hey > are published together with adjacent RFC numbers. Merging the two documen= ts > would be preferred but I understand that this is more work (albeit a miss= ed > opportunity). From nobody Fri Apr 24 10:43:35 2020 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 582943A10B8; Fri, 24 Apr 2020 10:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 fvcmig7ydbQK; Fri, 24 Apr 2020 10:43:26 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 6C6C43A1080; Fri, 24 Apr 2020 10:43:25 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id i10so11902488wrv.10; Fri, 24 Apr 2020 10:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=YPM6RIVZO+5U9KxahdoUSE5Gtb4w2X8mO7s+7Jlw+l0=; b=QZIN0FXSZ82pcqT6/A59hw/FD0Syd/+GQ1AnfFZCyhgatcz6ben7znD7e/g7s+GTmT xywVDy+zLEiQ+JD44osh42sTUk7TipjR2wb4D3OrbudB08efMLfVxO7Jhueojpjo4ZRZ lFESaH0H6vF30LvT8rRl7DjJjEKE0HPTABEmqi7jsRRcMDaXqZvRem4fyYRKRNf+xLIy DbNzGxp4kwwC6Z9aQIZpoQIXS+zKwDoEDivZLoKnB5aPoEkBKvhFHLqNoi/ifnWhv7IS 7h6CU/56/e2e8eVYa7doMmaEkAJmvyaxfIE6eFB9etmTGYGG1eONQf0k57BIIb7MREqH MIqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=YPM6RIVZO+5U9KxahdoUSE5Gtb4w2X8mO7s+7Jlw+l0=; b=EPc4LjiBErH5/xle5s5aoNvCGRm25HZY1S2aglNZXipS5ExiikeKhBZDIuOEX+HXeY Lynvr/CRIK2gWU8KRmLtVr5qr9aB62Z6q2qNxCQnOyyO2KGzJZkxvJXeD8FZhIylgYsS Jr+DPb09IOPpqLfIZjxeiZwOP6U662Odxh6ITTduOk7IhxDg5Z/TqbrHeLzME2AxMguV suBwwX5eMup7bWnuPrvlb/VpVqFKdx18xa03baSz29M5DVnGELMsZVdoywbbb1ofnatZ tg0Ihc0DviYqTdeidDUw0TxcUu+q7tcfKX7xxYBO/xS/ay+l8R6V/WtTn96tfygWS7q0 OWuw== X-Gm-Message-State: AGi0PublHjeBGcHC6n7nvGhltxKVN+TXjTOewsRmqtmJd7gp7X5DWoBu gYjOp1QCciIpRQI0yATtjZnQz4957f3cySCbNwU= X-Google-Smtp-Source: APiQypJDZ94+iRBdBhCVbM01nVYltt0/Rrh1sW3n6NwinbE3zh8BqV/1lvfebEfoGMnUudDKDEqsA1nqLYLbhUqzylM= X-Received: by 2002:adf:94a6:: with SMTP id 35mr12105785wrr.420.1587750203844; Fri, 24 Apr 2020 10:43:23 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 24 Apr 2020 10:43:23 -0700 From: Alvaro Retana In-Reply-To: <1587749630_176333@FUMC-WEB2> References: <1587749630_176333@FUMC-WEB2> MIME-Version: 1.0 Date: Fri, 24 Apr 2020 10:43:23 -0700 Message-ID: To: Susan Hares , Jie Dong , "Rob Wilton (rwilton)" Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-rfc5575bis@ietf.org" , The IESG , "idr@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 17:43:33 -0000 On April 24, 2020 at 1:34:02 PM, Susan Hares wrote: Sue: Hi! > The author team will change to MUST per your comments. > > I know there is nothing in the text and I know there were problems. Given= the > rush on the first version, I know things were down-played so the urgent > problem could be fixed. > > My warning that the bit settings may be deep in code and current people m= ay > have trouble finding it. > > That said, it is the right thing to do. Thanks! =C2=A0 I still want to give Jie a chance to poll the implementations just in case -- this should not take more than a few days. > Did the iesg want by in same document? Sorry...I couldn't parse that. Thanks! Alvaro. From nobody Fri Apr 24 11:34:18 2020 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 4B9033A0044 for ; Fri, 24 Apr 2020 11:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=bbijse5C; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U7OH5E02 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 BpG78jwihV3a for ; Fri, 24 Apr 2020 11:34:14 -0700 (PDT) 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 B2CDF3A0366 for ; Fri, 24 Apr 2020 11:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5153; q=dns/txt; s=iport; t=1587753254; x=1588962854; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=P4GWQwo0Y9m/07xT+116X6OqjXWmAbAsGYP4JRrrcjc=; b=bbijse5CE8z9fzk/2E7TV0HONn+bAcTpm773MQszQ/wihtpA8A6rRFEb bJfJud3Emj+HPOtH13gFJ5I2Z0/8cuRY0vVi3b05CT8KLyUQR/c4KVXHL TzTkS7SxW6bFZPI6LcAaThPWshmqV4raBTnYiIQMNQ/QY3THHWoXkNEs4 8=; IronPort-PHdr: =?us-ascii?q?9a23=3A5Luv8h9OAOhqev9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcKHEkj6MP7CZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPCgDwMKNe/4UNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBggOBJS9RBWxYIAQLKgqEFYNGA4pyToIRk0+EYYJSA1QLAQEBDAE?= =?us-ascii?q?BJQgCBAEBhEQCF4IPJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQMSER0?= =?us-ascii?q?BATgPAgEIBAoDAwECKwICAjAdCAEBBAESIoMEAYF+TQMuAQ6nLQKBOYhhdoE?= =?us-ascii?q?ygwABAQWCSIJWGIF0GgMGgTiCY4lWGoIAgTgcghg1PoJnAgKCAw2CZTKCLY4?= =?us-ascii?q?NgyqGFJpUCoJFiAyIb4cAHZxxhGiLEIlFkzkCBAIEBQIOAQEFgWkigVZwFTs?= =?us-ascii?q?qAYI+UBgNkTQMF4NPhRSFQnQ1AgYBBwEBAwl8jRwBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,313,1583193600"; d="scan'208,217";a="478272440" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 18:34:13 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 03OIYDgA032452 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2020 18:34:13 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 13:34:13 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 13:34:13 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Apr 2020 14:34:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hRr4Ltvo/TcK7FQVSVUka8XvOEe1qqAIyljaoODzKmDTIhv8zzYmUyoWnnBM8mN9xN9TGj8u+Zcd4HzEc+hOIkXvnlvbAKlZN3i5rqtU4dsDWUwzhn6gUf/8o/LUBMUQshuF1JP6GOr+JxQkn2uMRwSTdSkHI0jj5J3Bxw4JjDLdn0qkQRn+3BoH4vQOGP7uU4C1qxBtjr9oZ2/zVtAHU6Enz8QNYzllv0Glj1oxAOR8ESzEpVcwDxYTkyRoMth0Vo2WBdXlWUHhZ29MbltUVAelzmSrwmh2mxFwNl879k7jrlJHjaHBapSdC3Dll/X8TE8yeehKhY9M1uru7T7BhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P4GWQwo0Y9m/07xT+116X6OqjXWmAbAsGYP4JRrrcjc=; b=oCz6jEgPT+4ajK7dgbbiZmvBr4wz0xHx0HBLcxr5PVNZivinc7I7zUC6HcHc7ZBXv0cmiCETHswc+9El9nxEk1nA6wcGL+mUjhMNGyzOi8sgd6Sl2afa4DDK9Nxv1Je+r7j1YCBwITh4go5d+Awj36ZPP9+Q/BnxWU+W2nzmRjryKJS4qaUM8o5kG0+ZxVhF4F+6iFRMnDutQ2pMe9sT5i38bLjYq6Onqh5Bks2PURvlydi77UrqNeg/fkAguHYP7GvDQgNRCqbadGYeJpKBOgP4XMZEQYbo4SsT825F20VmZMctpMslBjCMBGzFjV2xIz1idUasLWioEVJIkVUqzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P4GWQwo0Y9m/07xT+116X6OqjXWmAbAsGYP4JRrrcjc=; b=U7OH5E02FREwZSm/kHNLVzwxTgRD9O/LIBoawtn+MdcSUdFvBDDSqxGM0At6lYvxeeirbU/6Pe7ars8HDVDeLT81OZcXztVi6foqYJYjPYvZTS4ZNtJ5B3GK/ILvH89lL/JatvIehgGXcu0YFOc3IoH039blyLSWoPUDNdLb4s4= Received: from BN8PR11MB3713.namprd11.prod.outlook.com (2603:10b6:408:8e::28) by BN8PR11MB3572.namprd11.prod.outlook.com (2603:10b6:408:82::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 24 Apr 2020 18:34:11 +0000 Received: from BN8PR11MB3713.namprd11.prod.outlook.com ([fe80::f423:47d7:b55f:88cb]) by BN8PR11MB3713.namprd11.prod.outlook.com ([fe80::f423:47d7:b55f:88cb%4]) with mapi id 15.20.2937.012; Fri, 24 Apr 2020 18:34:11 +0000 From: "David Smith (djsmith)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-flowspec-oid-11 - has past WG LC Thread-Index: AdYaRRy6bVI0MFGzRKipBAjY9uiYJgAAE4EA Date: Fri, 24 Apr 2020 18:34:11 +0000 Message-ID: <50CA6CC0-1B55-4C12-A91F-9440D125AA70@cisco.com> References: <016101d61a45$1d7e2440$587a6cc0$@ndzh.com> In-Reply-To: <016101d61a45$1d7e2440$587a6cc0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=djsmith@cisco.com; x-originating-ip: [100.1.244.217] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e4536286-bac6-4346-3d8e-08d7e87e151a x-ms-traffictypediagnostic: BN8PR11MB3572: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2657; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3713.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(39860400002)(396003)(376002)(346002)(136003)(26005)(6512007)(86362001)(316002)(2906002)(33656002)(2616005)(36756003)(4744005)(6486002)(66946007)(64756008)(66446008)(5660300002)(966005)(66556008)(71200400001)(8936002)(186003)(8676002)(110136005)(91956017)(66476007)(478600001)(6506007)(76116006)(53546011)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 74o0PigopynWwo9lGRju/zAyhpKBavvmDXtonmgcgycE+rBS8zgcoOxa7NXBeqVrPcLJzdz3PwvVh2uZ3vEd9/nK3VTdFv3isd+ZpH5QJLz3LzlH2pvRkfWsiFfgsRyzbyR8hiNtYQbggVtAParQsHgMzoOey6riwplOmvNazBwP37m/R4SedkrN1+d/o7XRG6YJ8HM+xlnuWtjUKzMHfaJBsDp2UR/zEPUJmpDEPOp9Izy3Pm7MWh2vZsxa0E1ZbJz7wfYoAR++lLj1q9LqlmgeW4f8dUT4CDz+EK1/Ga4gOe8mfbwOMQG3O7zqItmUqTI1W4/1kPUL8q4OiV6zeJQI76IhMQ3EGTsNFimjINrAkkxx8L2S+KKfZW/D6WyQGNlxoap3qgg5lxrN5jYK6GuLHmfzZc7F3A8BsWpeqEFiP6pdgi62osDWQLdx9lDEkoOxvgbjy5meWzENWzs7wJzMIk/5RAs3nz9OHtM73gh/B5K8Q9D9vD2U26CCI6OvSecIOFW0ObaxTTsRwB39YQ== x-ms-exchange-antispam-messagedata: 0HJ3cqRsyJCTpgeqjztO2XJUTl0dvRkNuaM+AkX9XxndMhp8VibsEWYPY3eAYrkYIDBF+K40XLP56L/VLQfkQPIZT2p5Mnh1lRXArgBt5uOUFsT6t7+26/PtRv5cuVECG9dTQeAd2zgW0lE0MdoDYg== Content-Type: multipart/alternative; boundary="_000_50CA6CC01B554C12A91F9440D125AA70ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e4536286-bac6-4346-3d8e-08d7e87e151a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 18:34:11.1170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3IHR4PZ9jOEGs5/UC3VdZsTk2ApPsh8U5xztjHBcvr2VpY0MjmbX/LZPlYsNEZzAjAR+0OsYPtZKdeFrHH41NQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3572 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-flowspec-oid-11 - has past WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 18:34:16 -0000 --_000_50CA6CC01B554C12A91F9440D125AA70ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2theSwgdGhhbmtzLiBXZeKAmWxsIHdvcmsgb24gdGhpcyBhc2FwLiAvZGF2ZQ0KDQpGcm9tOiBJ ZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgInNoYXJlc0BuZHpoLmNvbSIg PHNoYXJlc0BuZHpoLmNvbT4NCkRhdGU6IEZyaWRheSwgQXByaWwgMjQsIDIwMjAgYXQgMTA6MzMg QU0NClRvOiAiaWRyQGlldGYuIExpc3QiIDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWRyXSBk cmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkLTExIC0gaGFzIHBhc3QgV0cgTEMNCg0KR3Jl ZXRpbmdzOg0KDQpkcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkLTExLnR4dCBoYXMgcGFz dCBXRyBsYXN0IGNhbGwuDQoNClRoZSBzaGVwaGVyZCB3b3VsZCBhcHByZWNpYXRlIHRoZSBjby1h dXRob3JzIHByb3ZpZGluZyBpbXBsZW1lbnRhdGlvbiByZXBvcnRzIG9uIHRoZSBJRFIgd2lraSBh dDoNCg0KaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHIt YmdwLWZsb3dzcGVjLW9pZCUyMGltcGxlbWVudGF0aW9ucw0KDQpDaGVlcmlseSwgU3VzYW4gSGFy ZXMNCkNvLWNoYWlyIGFuZCBzaGVwaGVyZA0KDQoNCg0K --_000_50CA6CC01B554C12A91F9440D125AA70ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8139C0C373BB2D4D8A375F01F45ABC31@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T2theSwgdGhhbmtzLiBXZeKAmWxsIHdvcmsgb24gdGhpcyBhc2FwLiAv ZGF2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SWRyICZsdDtp ZHItYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O3NoYXJlc0BuZHpoLmNv bSZxdW90OyAmbHQ7c2hhcmVzQG5kemguY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXks IEFwcmlsIDI0LCAyMDIwIGF0IDEwOjMzIEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtpZHJAaWV0 Zi4gTGlzdCZxdW90OyAmbHQ7aWRyQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5b SWRyXSBkcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkLTExIC0gaGFzIHBhc3QgV0cgTEM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3Jl ZXRpbmdzOiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dz cGVjLW9pZC0xMS50eHQgaGFzIHBhc3QgV0cgbGFzdCBjYWxsLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBzaGVwaGVyZCB3b3VsZCBhcHByZWNpYXRlIHRoZSBjby1hdXRob3JzIHByb3Zp ZGluZyBpbXBsZW1lbnRhdGlvbiByZXBvcnRzIG9uIHRoZSBJRFIgd2lraSBhdDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dp a2kvZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dzcGVjLW9pZCUyMGltcGxlbWVudGF0aW9ucyI+aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dz cGVjLW9pZCUyMGltcGxlbWVudGF0aW9uczwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hl ZXJpbHksIFN1c2FuIEhhcmVzIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q28tY2hhaXIgYW5kIHNoZXBoZXJkIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_50CA6CC01B554C12A91F9440D125AA70ciscocom_-- From nobody Fri Apr 24 11:55:09 2020 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 2036A3A0796; Fri, 24 Apr 2020 11:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 0xroAkPuOOZs; Fri, 24 Apr 2020 11:55:04 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 CA6553A0795; Fri, 24 Apr 2020 11:55:03 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id x4so11767612wmj.1; Fri, 24 Apr 2020 11:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=EiiCkHYE8HhrWrU0leXhavrtkpAeXADE1w4nQMLyIw4=; b=YXlMYx3K0pWekyJqkEQUbnlH8i23OyQcPZPk0eYnpcnsMCzXdj5BWhvwf6kFRvvupN dV6RRD/9Ay66ZUl5smGGTooz+tu9ib7SiVySpE91bJFkJP9YZZWU/XRXO0vRLALEadZq DJIutbU6VhmiPZ8ohYZBbjZrqs/hxtSGFYx+5XLdve3B6ftPM7cNt0S8mlr7R0cqGwnv rpAw3FIct17EHq4wjC6key9n6JRtEFNcnmYCKAQP7SkdL9pB2EoYiRcSwy7qpH1ECJSb 0+K1voOKLWbaSFhOhsk+oCg5cvOho4aFgErTZxoBS6lgt4V6lAeNoo2CKxkAjdGCqHtQ NU2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=EiiCkHYE8HhrWrU0leXhavrtkpAeXADE1w4nQMLyIw4=; b=ek+Xvu7GLHDwM1ZP4VVe5GK7NYv8AbC/NA1rj0M0tibdeKgrG4c/EghRn5IIXN7875 7MEo7WFELAyXVgEsp40G0EtpcaZIih6sz0cBdP5beOdYLcGq00QDBGql3dBwbAT6dhl4 MypbVLfXNALGEHWYIiSiZt5aH1JZK6aOSTZXs063Xjj/t0YBp8S0QyTw1Kjv70ZToxTA PwVAGbVcc9gRD4W25H89n5YdC8/vmuWXaYCsQYxkM9ANNw+mEdxg4xpWyurtMu5M5+OV X56xJoN/y+Lw9ex1T66Kx1rQX1M21dy4S5m75vcJBA1klQxUk2PGPRPS8l+lB20YnqSS DpKQ== X-Gm-Message-State: AGi0PubA/0QKeSSxaYMSPgnHURcUMt1hpAqdaunLlAtOQs9W0m8/hnuF xdEobh3iegd5aUG/6pYczlE0/J6wVIbxi/iIuH5StP2b X-Google-Smtp-Source: APiQypK+ylEy5bbXfPdY6nx162KpusDA/xBMoFk2TOvzfsm/rYyn5HY0yCIQ471zdw6HkR0uMu6YBM7bXsLTmSxyR4k= X-Received: by 2002:a7b:c755:: with SMTP id w21mr11409875wmk.120.1587754501726; Fri, 24 Apr 2020 11:55:01 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 24 Apr 2020 11:55:01 -0700 From: Alvaro Retana In-Reply-To: <158774729288.14012.4297480673585471299@ietfa.amsl.com> References: <158774729288.14012.4297480673585471299@ietfa.amsl.com> MIME-Version: 1.0 Date: Fri, 24 Apr 2020 11:55:01 -0700 Message-ID: To: Martin Duke via Datatracker , The IESG , Martin Duke Cc: Susan Hares , idr-chairs@ietf.org, draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] Martin Duke's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 18:55:06 -0000 On April 24, 2020 at 12:54:53 PM, Martin Duke wrote: Martin: Hi! > This is not a DISCUSS-level concern, but I found it odd that the Node MSD= TLV > must be the minimum of all configured interfaces without regard for the > presence of any Link MSD TLVs. > > For example, if all node interfaces have an MSD of 20 except one with an = MSD > of 10, it would be much more compact to advertise a Node MSD of 20 and a > single Link MSD of 10. Section 5 says the Link MSD would take precedence,= so > there would be no information loss. As I understand the spec, this would = not > be allowed, and each link would have to be advertised separately to gain = that > level of granularity. > > If this is not the intent, then in Section 3, extending a sentence to say > "Node MSD is the smallest MSD supported by the node on the set of interfa= ces > configured for use, [excepting links advertised with their own Link MSD T= LV]" > would avoid the problem. This could have been a good optimization. However, this ship has sailed. =C2=A0BGP-LS is a mechanism to carry topology related information to a central controller. =C2=A0This information, as in this case, is obtained from the IGPs (OSPF or IS-IS). =C2=A0IOW, BGP-LS is simply carrying the same information that IS-IS/OSPF generated...with the same semantics, which is what the controller is expecting. =C2=A0The corresponding IGP specifications (rfc8491/rfc8476) contain the same language...if we change this document then we would have to change the IGP documents...and all the implementations. :-( Thanks! Alvaro. From nobody Fri Apr 24 12:16:47 2020 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 1A80D3A0860; Fri, 24 Apr 2020 12:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=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 oXu7Oeovu_tj; Fri, 24 Apr 2020 12:16:38 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 492B33A0864; Fri, 24 Apr 2020 12:16:38 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id i3so11524225ioo.13; Fri, 24 Apr 2020 12:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ug3eGR1MbpW6CUK2LJuoBnmXQGPvp23fyThbM856MrE=; b=QGksf3Y5Qcod1FP/BYIkerH8DsOC6jEbaqqZ0GyXaqzv2NPmTvtrVhuVk2wM2uesYN KN3I4WiSQTJIOEuy7xih02CyB0knEYW63UGy7mqtkTWsnrWA7d9BZjV3hYTKIcVl1Nnh FAKxA4tn/qBEsTaYps7+GidwWOxptfmkqJilRhBxthzkxMv59e0NMzHdNPtHVFbJLa0x EyRnM2J5crmbG8JMqrt9m67+bkK82Dh+LZR41O9zqPVpokt6aggCqUVfkZ6cLOLnFrvo Slv5/F2tuTJnjs3MFkqcTv4omHeZA9D/kKHUoJQO99Hbk011Nuy0fluPPLb0E+qJ+OSu AHeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ug3eGR1MbpW6CUK2LJuoBnmXQGPvp23fyThbM856MrE=; b=GwsMmFt9k0z7VUHyfzNY1LcxjkGBAAwMos25cA9bHUcJYHaBhbTyRrtBZ+1JG/GKG2 giiOe4zm3dIRFqG6e18mjCQqmBU1f6PcCmGhIhaDZn8IQM2labXUMQKxlXwY5MUihXxe V4Bvw+CWqG7Z0WR7aMVLakTU9G8xkmhvWFx5BaJaCFuz29vemBxMqQ6MU1QcZZLlfThz 4TwsB11YDi7It5RPoiQ3MnXdiAutVwW6SPPgqD5+e8Q+iCoVsAYrrvsUovhE/RIkuT8k aSbA4sLeSvtpyvTAdJgqoAqxQkYcsKXG5eC+TMlcOhGEIDb4+Aks/nsboG1zK9Li4Nso TscA== X-Gm-Message-State: AGi0PuYOEk/buOLgETaQrxgzpMbVGeKM0ryeW96rzdZA24bAZfcCYHrI uz62r3w11m6o3TXiGWM+JBSycTfeYGZ/EvgfrgLqxQ== X-Google-Smtp-Source: APiQypJMT3pCCMYGpj1hAfgDPOfIQVWf/u3dMWfhcWXiFZdxCKc8zs7rXpPDjQUh94HUTKl28rqz7ItQM2cUP0IEY2g= X-Received: by 2002:a02:cbac:: with SMTP id v12mr9367067jap.103.1587755797616; Fri, 24 Apr 2020 12:16:37 -0700 (PDT) MIME-Version: 1.0 References: <158774729288.14012.4297480673585471299@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Fri, 24 Apr 2020 12:16:26 -0700 Message-ID: To: Alvaro Retana Cc: Martin Duke via Datatracker , Susan Hares , The IESG , draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr@ietf.org, idr-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004e9c7e05a40e345b" Archived-At: Subject: Re: [Idr] Martin Duke's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 19:16:40 -0000 --0000000000004e9c7e05a40e345b Content-Type: text/plain; charset="UTF-8" Bummer! Thanks for the reply. On Fri, Apr 24, 2020 at 11:55 AM Alvaro Retana wrote: > On April 24, 2020 at 12:54:53 PM, Martin Duke wrote: > > > Martin: > > Hi! > > > > This is not a DISCUSS-level concern, but I found it odd that the Node > MSD TLV > > must be the minimum of all configured interfaces without regard for the > > presence of any Link MSD TLVs. > > > > For example, if all node interfaces have an MSD of 20 except one with an > MSD > > of 10, it would be much more compact to advertise a Node MSD of 20 and a > > single Link MSD of 10. Section 5 says the Link MSD would take > precedence, so > > there would be no information loss. As I understand the spec, this would > not > > be allowed, and each link would have to be advertised separately to gain > that > > level of granularity. > > > > If this is not the intent, then in Section 3, extending a sentence to say > > "Node MSD is the smallest MSD supported by the node on the set of > interfaces > > configured for use, [excepting links advertised with their own Link MSD > TLV]" > > would avoid the problem. > > This could have been a good optimization. > > However, this ship has sailed. BGP-LS is a mechanism to carry > topology related information to a central controller. This > information, as in this case, is obtained from the IGPs (OSPF or > IS-IS). IOW, BGP-LS is simply carrying the same information that > IS-IS/OSPF generated...with the same semantics, which is what the > controller is expecting. The corresponding IGP specifications > (rfc8491/rfc8476) contain the same language...if we change this > document then we would have to change the IGP documents...and all the > implementations. :-( > > Thanks! > > Alvaro. > --0000000000004e9c7e05a40e345b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bummer! Thanks for the reply.

On Fri, Apr = 24, 2020 at 11:55 AM Alvaro Retana <aretana.ietf@gmail.com> wrote:
On April 24, 2020 at 12:54:53 PM, Martin Duke wrote:


Martin:

Hi!


> This is not a DISCUSS-level concern, but I found it odd that the Node = MSD TLV
> must be the minimum of all configured interfaces without regard for th= e
> presence of any Link MSD TLVs.
>
> For example, if all node interfaces have an MSD of 20 except one with = an MSD
> of 10, it would be much more compact to advertise a Node MSD of 20 and= a
> single Link MSD of 10. Section 5 says the Link MSD would take preceden= ce, so
> there would be no information loss. As I understand the spec, this wou= ld not
> be allowed, and each link would have to be advertised separately to ga= in that
> level of granularity.
>
> If this is not the intent, then in Section 3, extending a sentence to = say
> "Node MSD is the smallest MSD supported by the node on the set of= interfaces
> configured for use, [excepting links advertised with their own Link MS= D TLV]"
> would avoid the problem.

This could have been a good optimization.

However, this ship has sailed.=C2=A0 BGP-LS is a mechanism to carry
topology related information to a central controller.=C2=A0 This
information, as in this case, is obtained from the IGPs (OSPF or
IS-IS).=C2=A0 IOW, BGP-LS is simply carrying the same information that
IS-IS/OSPF generated...with the same semantics, which is what the
controller is expecting.=C2=A0 The corresponding IGP specifications
(rfc8491/rfc8476) contain the same language...if we change this
document then we would have to change the IGP documents...and all the
implementations. :-(

Thanks!

Alvaro.
--0000000000004e9c7e05a40e345b-- From nobody Fri Apr 24 14:46:16 2020 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 2CBC13A0CAB; Fri, 24 Apr 2020 14:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 header.b=Fhg0HPtR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Tl0k1cNm 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 G8TCnrxk04N2; Fri, 24 Apr 2020 14:46:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480C43A0CA8; Fri, 24 Apr 2020 14:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8030; q=dns/txt; s=iport; t=1587764770; x=1588974370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CLAq2vOxeji/rEvhSa2m37wyCzchjD5DJDaQAYFyLqk=; b=Fhg0HPtR/68SmSffIHHGY03e3hkqbN1Y70HRRpH8fa0q03dr29fv6S0g Xtzp29lSEJVnFwoXt79BJk14Vc/f4y8vllt2uUv+YqCjPFTUfG2VbPPB7 jEYLHo91YFAbNl4shF7CB++ht1IJMt+4uqlDHMiONkc4GEZ2GdmWcGY9U c=; IronPort-PHdr: =?us-ascii?q?9a23=3Amr9mxxdhBT2cqSKe1d03p0VrlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YjIrGs9BWXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AACXXaNe/5RdJa1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQE8gTUEAQEBCwGBUykoBWxYIAQLKoQfg0YDinGCX4EBly+?= =?us-ascii?q?BLhSBEANUCwEBAQwBARgPBgIEAQGERAIXgg8kNgcOAgMBAQsBAQUBAQECAQU?= =?us-ascii?q?EbYUqByUMhXEBAQEBAQIBARALBhEMAQEsCwELBAIBCA4DAwEBAQMCIwMCAgI?= =?us-ascii?q?lCxQBBQMIAgQBDQUigwQBgksDLgEOpwYCgTmIYXaBMoMAAQEFgTIBAwIBDAE?= =?us-ascii?q?BOwQBgxIYgg4DBoEOKgGCYolWGoFBP4ERJxyCGDU+gmcBAQEBAQEYgRQBEgE?= =?us-ascii?q?4gnsygi2OIhKDA6BoCoJFiAyPbx2CWohWhHSMTYNnjBGJRZM5AgQCBAUCDgE?= =?us-ascii?q?BBYFZBS1mWBEHcBU7KgGCPlAYDZBQZAwXFW4BCIJDhRSFQnQCAQEBMAIGAQc?= =?us-ascii?q?BAQMJAXuOLAEB?= X-IronPort-AV: E=Sophos;i="5.73,313,1583193600"; d="scan'208";a="757496073" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 21:46:09 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 03OLk9aJ023048 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2020 21:46:09 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 16:46:08 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 17:46:07 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Apr 2020 16:46:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QoL7bBpRyVTREgrx4J2qyOLvGOuihe5H51740j87kgH7o3J3Jpc+XdsRMMMoD0ct5gX28gnbsFNtzhV4xbgX36kX2FnQZ/1DNu4GVqoT3QftOaHSInHxNwfRDKqjpxh2i04t4yXNda5P0KMiWXM3ggkmXESBWIpxKibcd8y5cXJfJ4dmmvrtn6HnSvYZy81zFvaZtIkMa0dFRC0YvyCEWDKtg8Br9S/2wGq+MWBE0aumFLJxGYMYl/Hn9YLGg/I19A+Eeatdo/VWOYb1Xk8eLdPMvv0wQtYFLcaH5CBItvKZ9diwWMDG/uarQnQetn+SCyrV5GKkYY95hiFzhEu9ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CLAq2vOxeji/rEvhSa2m37wyCzchjD5DJDaQAYFyLqk=; b=HWGGiNHYV/cSITNibQhHrxAONws7oNauYWcjn4u72+LgyqKMocD659JOaNJuokFX33saahFglscVDUFiItPr1coZwTXRs82/YSgaJbPJYLUxoX2/7CKdK+6GHb6AKMwKk9X0wbUSLS48scXl+MjeJm1DgOyjj2dXbMUB3u+iz3OCJOVY+/dowLwPIkhDyfXdsTRFCZABdLgf6HJCuSM8Gyekv3TIlOXuzuxR4zyM3+GPSzgq/ES5RFYAMUCEETWI1tOHhifaA9Wedg3hidnR9zNHoGXAnFBaKnoFkx53/7qoi58CrVzy1Ikfw3gy00rhhH2guM8HrcDfr4UWAyJ88g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CLAq2vOxeji/rEvhSa2m37wyCzchjD5DJDaQAYFyLqk=; b=Tl0k1cNmwM/mVMqfT2ByvBnz6b/PxBNhgMixpHzGv52fmYgzZvRpv0ZCtftHuhSbweyL0QPIzF8K+9LwuLSYdVt3WdwRAHPBKE/BlYUL79h45bvzy78Sd2bbfkZQqA/EQTg9kaeJxgpo2WKvaJqCI9F1KKOmqJpgKwibNZX942Y= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1993.namprd11.prod.outlook.com (2603:10b6:3:12::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 24 Apr 2020 21:46:06 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c%9]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 21:46:06 +0000 From: "Eric Vyncke (evyncke)" To: Susan Hares , "'The IESG'" CC: "draft-ietf-idr-rfc5575bis@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" Thread-Topic: =?utf-8?B?W0lkcl0gw4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWlk?= =?utf-8?Q?r-rfc5575bis-23:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWGj9qlYzMYaYBREuQQfjux/Gfb6iITE2AgAAIRACAAJv5gA== Date: Fri, 24 Apr 2020 21:46:06 +0000 Message-ID: References: <158773622329.9749.4475217266475729122@ietfa.amsl.com> <012201d61a40$66f798e0$34e6caa0$@ndzh.com> <015f01d61a44$8958e110$9c0aa330$@ndzh.com> In-Reply-To: <015f01d61a44$8958e110$9c0aa330$@ndzh.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:1db1:3b2f:a62c:9382] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8d8aeb8-fe1a-49ef-a434-08d7e898e480 x-ms-traffictypediagnostic: DM5PR11MB1993: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(39860400002)(346002)(376002)(66556008)(66574012)(66446008)(53546011)(64756008)(966005)(110136005)(316002)(71200400001)(36756003)(5660300002)(54906003)(2616005)(478600001)(81156014)(6486002)(2906002)(6512007)(6506007)(66476007)(91956017)(66946007)(33656002)(224303003)(76116006)(4326008)(86362001)(186003)(8936002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0z7NWWZBQKr9nrnXAkFn5MkNnCsoZnBx5H54/uFa/Aguia/WAByTeuE9Vxka7AAFNDwN7hj0RPF8O6CRofWfPqmr0wkWjh9UPjaUKhWGquPcL0RcXULZEnllNBHTINqG5+oip++1cqcKcnepA+PPm4YAiPBcRLVF/TnQw8/dipBup0itK81LiBJF4gBFR2ul5ldsIL7UtVJ2TrHJj38ZMhzD5ZBmK2/JCa+Z3K95VajjSz5rZ9VmMQz974diMgx8mEULzNkQ0WKXjfvGFVJPp7zU/ERrGCucwZNz6SXnD1Uex7eQoYiKq2zqsBuANWk6U6WyagohnVOaO/zx+jWEMkE9WywKO5rVTUsc75EBn4xgAWgUmIS5npriIGXVme4eSB1BQyvD14mot5Qy91npCxQaM9qOSbHchP7G0JzE5tgOC0rWEofFeNNX2wr3iWlkYILgsWi1+WEqsEE1LTO4P+pRrEGPZZzu3cUtRUqjfXsdUSVquy9h+eSZdEw6fXccXvnBDjp/Ggcv8V8zIwBGhA== x-ms-exchange-antispam-messagedata: UE3bRsfv9Bt5gcvfRguw9Xj7ByvOHCv1iMoTcna2cHM+14wC2emMI+1SQI7+msT8H1ftdYjXz1gK3vGPDSqDNtoaciJv+Wddo/dZeS2sSG5Wi7B9+tY45JcYTD+BGqlWxiDrN+qdjfgj6OWhl4gzD574K8K1jXLKA3vILgRJpkAy84Ah35gjhTa9CJbJkmyCrEGQkfA/YBeWmUFN8T7Ubz/EcwmC5h2es+bPFud86DvV0hevhTuVWWo8B64kBlrTcWIuTHUKWoppWPtDZcuu9gFMsF6NavVNqx8piXs/Q4mHv5z2okRMZP+anuQYOgC31ik7NbgcwqQb6Ytd9bjPbq2nH/3kiP0+GrlJ3NnXncqn7MBM2aXgZL97LpTCA/A3oXwbJ9udIUmf8Ryz/ObjXZWlRHlV6CwEocjPC+SarMbqAyiT6U+tlu1HnIGGsberkeZCx96t3E5SHHF+2vvPJU8EYfLpGfd1U+tDAk4668GUlSQwpnQb7yOIs0cfDrO2mARVNDbGJGevIUPFrjvs+0+k6P6on25evF6M6LAJMsvAXWJLDvAO4i+JDHGk3Mq0kezwKwDg5AHL3CdjSIgEXGG9bOy59A1BeshrBeAGxW2FawK9YPZTmO6oqgxEbgJQ5oksLOkGSo1sk63BsfqVbPZYV0GZdyyOXAtPNIeZDoml5VH3Di31cGWL0RIGZCMm11N0TXVOdimXP2qCLSI4ncieS4rNtVzJvko+5pXkXUvwrOUPkbwyr+f2CPwlkPVOVuC+cEfl35y/9h9UoCFrIpth8d2gtnuchccxQ2a21jkz2GiAyS8smbziOSQqrXfig8GSokv+aezcidYFaklA2hMYlEYA1aArN2bGM92Bve0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a8d8aeb8-fe1a-49ef-a434-08d7e898e480 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 21:46:06.0404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q6su0dLNzF3cPFgUBBnzm0p0XmCQzuaU4INRO9i93K2gKSLix1VGCJw64Gi90EMKLH6fhgpzKcmbUm7xym7+Bg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1993 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 21:46:14 -0000 U3VlLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBhZGRlZCBwaWVjZXMgb2YgaW5mb3JtYXRpb24uDQoN CkkgY2FuIG9ubHkgcmVzcGVjdCB0aGUgZGVjaXNpb24gb2YgdGhlIElEUiBXRyB0byBtYW5kYXRl IDIgaW1wbGVtZW50YXRpb25zIGJlZm9yZSByZXF1ZXN0aW5nIHB1YmxpY2F0aW9uLiBJbXByZXNz aXZlLg0KDQpOaWNlIHRvIHNlZSB0aGF0IHRoZXJlIGFyZSBtb3JlIHRoYW4gMSBJUHY2IGltcGxl bWVudGF0aW9uIG9mIEZsb3dTcGVjIChJIG9idmlvdXNseSBrbmV3IGFib3V0IG9uZSkuIFRoYW5r cyB0byB5b3VyIGNvLWF1dGhvcnMgdG8gaGF2ZSBpZGVudGlmaWVkIHRob3NlIGltcGxlbWVudGF0 aW9ucy4NCg0KVGhpcyBzaG91bGQgYWR2YW5jZSB0aGUgdjYgZG9jdW1lbnQgd2l0aGluIHRoZSBX RyBhbmQgdG93YXJkcyBwdWJsaWNhdGlvbi4NCg0KTGV0IG1lIGNoZWNrIHdpdGggdGhlIHJvdXRp bmcgQUQgaG93IHdlIGNhbiBwcm9jZWVkIChwZXIgQWx2YXJvJ3MgZW1haWwpIG9uIG9wcG9ydHVu aXR5IHRvIGNsZWFyIG15IERJU0NVU1MgYW5kIHdoeSBub3QgaGF2aW5nIGNvbnNlY3V0aXZlIFJG QyBudW1iZXJzLg0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCkRhdGU6IEZyaWRh eSwgMjQgQXByaWwgMjAyMCBhdCAxNjoyOA0KVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2Nv LmNvbT4sICdUaGUgSUVTRycgPGllc2dAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtaWRyLXJm YzU1NzViaXNAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzQGlldGYub3JnPiwg Imlkci1jaGFpcnNAaWV0Zi5vcmciIDxpZHItY2hhaXJzQGlldGYub3JnPiwgImlkckBpZXRmLm9y ZyIgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbSWRyXSDDiXJpYyBWeW5ja2UncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXMtMjM6ICh3aXRoIERJU0NVU1MgYW5kIENP TU1FTlQpDQoNCiAgICBFcmljOg0KDQogICAgW2F1dGhvciBoYXQgb25dIA0KICAgIE15IGNvLWF1 dGhvcnMgcmVtaW5kIG1lIHRoYXQgd2UgaGF2ZSB0aHJlZSBtYW51YWxzIHdoaWNoIGluZGljYXRl IDQgaW1wbGVtZW50YXRpb25zICgyIENpc2NvLCAxIEh1YXdlaSwgIDEgQXJib3IgTmV0d29ya3Mp LCBhbmQgaXQgaXMgcG9zc2libGUgd2UgaGF2ZSBtaXNzZWQgb3RoZXIgZmxvdyBzcGVjaWZpY2F0 aW9ucy4gIA0KICAgIENpc2NvOg0KICAgIGh0dHBzOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3Rk L2RvY3MvaW9zLXhtbC9pb3MvaXByb3V0ZV9iZ3AvY29uZmlndXJhdGlvbi94ZS0xNi9pcmcteGUt MTYtYm9vay9DM1BMLUJHUC1GbG93c3BlYy1DbGllbnQuaHRtbA0KDQogICAgQXJib3IgTmV0d29y a3MgTmV0c2NvdXQgDQogICAgaHR0cHM6Ly9hcmNoaXZlLm5hbm9nLm9yZy9zaXRlcy9kZWZhdWx0 L2ZpbGVzL3dlZC5nZW5lcmFsLnRyYWZmaWNkaXZlcnNpb24uc2Vyb2Rpby4xMC5wZGYNCg0KICAg IEh1YXdlaTogDQogICAgaHR0cHM6Ly9zdXBwb3J0Lmh1YXdlaS5jb20vZW50ZXJwcmlzZS9lbi9k b2MvRURPQzExMDAwMjg1MzQ/c2VjdGlvbj1qMDM0JnRvcGljTmFtZT1jb25maWd1cmluZy1keW5h bWljLWJncC1pcHY2LWZsb3ctc3BlY2lmaWNhdGlvbg0KICAgIFtBdXRob3IgaGF0IG9mZl0gDQoN CiAgICBbV0cgY28tY2hhaXIgaGF0IG9uXSANCiAgICBPdXIgdXN1YWwgY2hlY2tpbmcgaW52b2x2 ZXMgZ2V0dGluZyB0aGUgaW50ZXJvcGVyYWJpbGl0eSBkZXRhaWxzIHdoaWNoIHRoZSBJRFIgY2hh aXJzIChpbiBteSBXRyBjby1jaGFpciBoYXQpIGhhcyBub3QgcmVjZWl2ZWQuICBTbywgdGhlIGJv dHRvbSBsaW5lIGlzIHRoYXQgdGhpcyBpbiBwcm9jZXNzIC0gYnV0IGl0IGlzIGJlaGluZCB0aGUg djQuICAgDQoNCiAgICBUaGUgV0cgYWxzbyBoYXMgZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dzcGVj LW9pZC0xMS50eHQgKGZvciBpbnRyYS1BUyB3b3JrKSB0aGF0IHVwZGF0ZXMgdGhlIFJGQzU1NzVi aXMgaGFzIHBhc3QgV0cgTEMuIExhcmdlIG5ldHdvcmtzIGhhdmUgZGVwbG95ZWQgdGhpcyBhcyB3 ZWxsLCBhbmQgd2lzaGVkIGl0IHJvbGxlZCBpbnRvIFJGQzU1NzViaXMuICAgDQoNCiAgICBUaGUg V0cgZGVzaXJlZCB0byBnZXQgc29tZXRoaW5nIG91dCB0aGUgZG9vciB0byBjb3JyZWN0IHRoZSBp bmFjY3VyYWNpZXMgaW4gUkZDNTU3NWJpcy4gICAgDQogICAgW1dHIGNvLWNoYWlyIGhhdCBvbl0g DQoNCiAgICBXZSBhcmUgZ2xhZCB0byB0YWtlIGluc3RydWN0aW9uIGZyb20gdGhlIElFU0cgcmVn YXJkaW5nIHRoZXNlIGRyYWZ0cy4gIA0KDQogICAgU3VlIEhhcmVzIA0KDQoNCiAgICAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IFN1c2FuIEhhcmVzIFttYWlsdG86c2hhcmVz QG5kemguY29tXSANCiAgICBTZW50OiBGcmlkYXksIEFwcmlsIDI0LCAyMDIwIDk6NTggQU0NCiAg ICBUbzogJ8OJcmljIFZ5bmNrZSc7ICdUaGUgSUVTRycNCiAgICBDYzogZHJhZnQtaWV0Zi1pZHIt cmZjNTU3NWJpc0BpZXRmLm9yZzsgaWRyLWNoYWlyc0BpZXRmLm9yZzsgaWRyQGlldGYub3JnDQog ICAgU3ViamVjdDogUkU6IFtJZHJdIMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi1pZHItcmZjNTU3NWJpcy0yMzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KICAgIEVy aWM6DQoNCiAgICBXZSBoYXZlIGEgcnVsZSBpbiBJRFIgdG8gbm90IHN1Ym1pdCB0aGlzIGZvciBw dWJsaWNhdGlvbiB1bnRpbCB3ZSBoYXZlIDIgaW1wbGVtZW50YXRpb25zLiAgIA0KICAgIFdlIGRv IG5vdCBoYXZlIDIgdmVuZG9ycyB3aG8gd2lsbCBpbmRpY2F0ZSB0aGUgdjYgc3VwcG9ydCBpcyBk ZXBsb3llZC4gIA0KDQogICAgVGhlIG9yaWdpbmFsIGRvY3VtZW50IChSRkM1NTc1KSBkaWQgbm90 IGhhdmUgdjYsIGFuZCB0aGUgSUVTRyBhc2tlZCB0aGUgSURSIGdyb3VwIHRvIHdvcmsgb24gdGhl IHY2IGRyYWZ0LiANCiAgICBUaGUgc2FtZSBhdXRob3JzIGhhdmUgYSB2NiB2ZXJzaW9uIG9mIHRl eHQgaW4gV0cgTEMuICAgV2UndmUgY2FsbCBmb3IgaW1wbGVtZW50YXRpb24gcmVwb3J0cyBhbmQg cmVjZWl2ZSBub25lIG9uIHRoZSB2Ni4gDQoNCiAgICBJZiB5b3Ugd291bGQgbGlrZSB0byBoZWxw IHVzIGZpbmQgdjYgd2l0aCBGbG93LXNwZWNpZmljYXRpb24gZGVwbG95bWVudHMsIHdlIHdvdWxk IGJlIGhhcHB5IHRvIGZvcndhcmQgdGhlIHY2IHZlcnNpb24gdG8gdGhlIElFU0cuIA0KICAgIE91 ciBsb25nIHRlcm0gZ2FtZS1wbGFuIHdhcyBvbmUgZG9jdW1lbnQgd2l0aCB2NCBhbmQgdjYgc3Vw cG9ydC4gDQoNCiAgICBTdWUgSGFyZXMgDQogICAgKGF1dGhvciBhbmQgSURSIGNvLWNoYWlyKQ0K DQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBJZHIgW21haWx0bzpp ZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRy YWNrZXINCiAgICBTZW50OiBGcmlkYXksIEFwcmlsIDI0LCAyMDIwIDk6NTAgQU0NCiAgICBUbzog VGhlIElFU0cNCiAgICBDYzogZHJhZnQtaWV0Zi1pZHItcmZjNTU3NWJpc0BpZXRmLm9yZzsgaWRy LWNoYWlyc0BpZXRmLm9yZzsgaWRyQGlldGYub3JnDQogICAgU3ViamVjdDogW0lkcl0gw4lyaWMg VnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLTIzOiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKQ0KDQogICAgw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgIGRyYWZ0LWlldGYtaWRyLXJmYzU1NzVi aXMtMjM6IERpc2N1c3MNCg0KICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1 Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQogICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAg IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3Np dGlvbnMuDQoNCg0KICAgIFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLw0KDQoNCg0KICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICBESVNDVVNTOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIFRoYW5rIHlvdSBmb3Ig dGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1bWVudC4gVGhlIGRvY3VtZW50IGlzIGNsZWFyLCBl YXN5IHRvIHJlYWQgKEkgYXBwcmVjaWF0ZWQgdGhlIGdpdmVuIGV4YW1wbGVzKS4NCg0KICAgIEFs YXMsIGR1ZSB0byBvdmVybG9hZCBvZiB3b3JrLCBJIGhhZCBvbmx5IGEgcXVpY2sgYnJvd3NlIHRo cm91Z2ggdGhlIGRvY3VtZW50IHdpdGggc3BlY2lmaWMgZm9jdXMgcG9pbnRzIGFuZCBmb3VuZCBu b3RoaW5nIEVYQ0VQVCB3aHkgaGF2aW5nIHR3byBkaWZmZXJlbnQgZG9jdW1lbnRzID8gT25lIGZv ciBJUHY0ICh3aXRoIHRoZSBjb3JlIGVsZW1lbnRzIG9mIHRoZSBwcm90b2NvbCkgYW5kIG9uZSBm b3INCiAgICBJUHY2ICh3aXRoIG9ubHkgdGhlIElQdjYgc3BlY2lmaWNzKS4uLiBJIGFtIG1vcmUg dGhhbiBzdXJwcml6ZWQgdG8gc2F5IHRoZSBsZWFzdC4uLiBoZW5jZSBteSBESVNDVVNTLi4uDQoN CiAgICBUaGlzIGJsb2NraW5nIERJU0NVU1MgY2FuIGVhc2lseSBiZSBmaXhlZDogZS5nLiwgd2l0 aCBhIFJGQyBFZGl0b3Igbm90ZSB0byBtYWtlIGEgY2x1c3RlciBvZiB0aGlzIGRvY3VtZW50IGFu ZCBkcmFmdC1pZXRmLWlkci1mbG93LXNwZWMtdjYgc28gdGhhdCB0aGV5IGFyZSBwdWJsaXNoZWQg dG9nZXRoZXIgd2l0aCBhZGphY2VudCBSRkMgbnVtYmVycy4gTWVyZ2luZyB0aGUgdHdvIGRvY3Vt ZW50cyB3b3VsZCBiZSBwcmVmZXJyZWQgYnV0IEkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgbW9y ZSB3b3JrIChhbGJlaXQgYSBtaXNzZWQgb3Bwb3J0dW5pdHkpLg0KDQogICAgUGxlYXNlIGZpbmQg YmVsb3cgYSBjb3VwbGUgb24gbm9uLWJsb2NraW5nIENPTU1FTlRzLg0KDQogICAgSSBob3BlIHRo YXQgdGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwNCg0KICAgIFJlZ2FyZHMsDQoN CiAgICAtw6lyaWMNCg0KDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQogICAgSSBhbHNvIHNlY29uZCBFcmlrIEsuJ3MgY29tbWVudCBvbiBub24t VENQL1VEUCBwb3J0cy4NCg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgIElkciBtYWlsaW5nIGxpc3QNCiAgICBJZHJAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQoNCg0K From nobody Fri Apr 24 15:32:34 2020 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 3DE763A0E4D; Fri, 24 Apr 2020 15:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 LI3590tQCsmE; Fri, 24 Apr 2020 15:32:05 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 876093A0E4C; Fri, 24 Apr 2020 15:32:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Eric Vyncke \(evyncke\)'" , "'The IESG'" Cc: , , References: <158773622329.9749.4475217266475729122@ietfa.amsl.com> <012201d61a40$66f798e0$34e6caa0$@ndzh.com> <015f01d61a44$8958e110$9c0aa330$@ndzh.com> In-Reply-To: Date: Fri, 24 Apr 2020 18:32:02 -0400 Message-ID: <001201d61a88$2d43c9a0$87cb5ce0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDH3wr1V03HAdKDI16OurUS47Z8OgHGzLzpAXJnGacDEIfMNKpzBCdw Content-Language: en-us X-Antivirus: AVG (VPS 200424-2, 04/24/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 22:32:08 -0000 Eric:=20 I will leave you to discuss the flow-specification v6 work with Alvaro.=20 For my co-authors and the IDR-WG, we will move this process as fast as = possible.=20 Sue=20 -----Original Message----- From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]=20 Sent: Friday, April 24, 2020 5:46 PM To: Susan Hares; 'The IESG' Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org Subject: Re: [Idr] =C3=89ric Vyncke's Discuss on = draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Sue, Thank you for the added pieces of information. I can only respect the decision of the IDR WG to mandate 2 = implementations before requesting publication. Impressive. Nice to see that there are more than 1 IPv6 implementation of FlowSpec = (I obviously knew about one). Thanks to your co-authors to have = identified those implementations. This should advance the v6 document within the WG and towards = publication. Let me check with the routing AD how we can proceed (per Alvaro's email) = on opportunity to clear my DISCUSS and why not having consecutive RFC = numbers. Regards -=C3=A9ric =EF=BB=BF-----Original Message----- From: Susan Hares Date: Friday, 24 April 2020 at 16:28 To: Eric Vyncke , 'The IESG' Cc: "draft-ietf-idr-rfc5575bis@ietf.org" = , "idr-chairs@ietf.org" = , "idr@ietf.org" Subject: RE: [Idr] =C3=89ric Vyncke's Discuss on = draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Eric: [author hat on]=20 My co-authors remind me that we have three manuals which indicate 4 = implementations (2 Cisco, 1 Huawei, 1 Arbor Networks), and it is = possible we have missed other flow specifications. =20 Cisco: = https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configurati= on/xe-16/irg-xe-16-book/C3PL-BGP-Flowspec-Client.html Arbor Networks Netscout=20 = https://archive.nanog.org/sites/default/files/wed.general.trafficdiversio= n.serodio.10.pdf Huawei:=20 = https://support.huawei.com/enterprise/en/doc/EDOC1100028534?section=3Dj03= 4&topicName=3Dconfiguring-dynamic-bgp-ipv6-flow-specification [Author hat off]=20 [WG co-chair hat on]=20 Our usual checking involves getting the interoperability details = which the IDR chairs (in my WG co-chair hat) has not received. So, the = bottom line is that this in process - but it is behind the v4. =20 The WG also has draft-ietf-idr-bgp-flowspec-oid-11.txt (for intra-AS = work) that updates the RFC5575bis has past WG LC. Large networks have = deployed this as well, and wished it rolled into RFC5575bis. =20 The WG desired to get something out the door to correct the = inaccuracies in RFC5575bis. =20 [WG co-chair hat on]=20 We are glad to take instruction from the IESG regarding these = drafts. =20 Sue Hares=20 -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Friday, April 24, 2020 9:58 AM To: '=C3=89ric Vyncke'; 'The IESG' Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org Subject: RE: [Idr] =C3=89ric Vyncke's Discuss on = draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Eric: We have a rule in IDR to not submit this for publication until we = have 2 implementations. =20 We do not have 2 vendors who will indicate the v6 support is = deployed. =20 The original document (RFC5575) did not have v6, and the IESG asked = the IDR group to work on the v6 draft.=20 The same authors have a v6 version of text in WG LC. We've call = for implementation reports and receive none on the v6.=20 If you would like to help us find v6 with Flow-specification = deployments, we would be happy to forward the v6 version to the IESG.=20 Our long term game-plan was one document with v4 and v6 support.=20 Sue Hares=20 (author and IDR co-chair) -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of =C3=89ric = Vyncke via Datatracker Sent: Friday, April 24, 2020 9:50 AM To: The IESG Cc: draft-ietf-idr-rfc5575bis@ietf.org; idr-chairs@ietf.org; = idr@ietf.org Subject: [Idr] =C3=89ric Vyncke's Discuss on = draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) =C3=89ric Vyncke has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: Discuss When responding, please keep the subject line intact and reply to = all email addresses included in the To and CC lines. (Feel free to cut = this introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ = ---------------------------------------------------------------------- DISCUSS: = ---------------------------------------------------------------------- Thank you for the work put into this document. The document is = clear, easy to read (I appreciated the given examples). Alas, due to overload of work, I had only a quick browse through the = document with specific focus points and found nothing EXCEPT why having = two different documents ? One for IPv4 (with the core elements of the = protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than surprized to = say the least... hence my DISCUSS... This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor = note to make a cluster of this document and draft-ietf-idr-flow-spec-v6 = so that they are published together with adjacent RFC numbers. Merging = the two documents would be preferred but I understand that this is more = work (albeit a missed opportunity). Please find below a couple on non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -=C3=A9ric = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- I also second Erik K.'s comment on non-TCP/UDP ports. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Sat Apr 25 05:45:18 2020 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 510AB3A0D4C; Sat, 25 Apr 2020 05:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QWs0DJ6bm_Cj; Sat, 25 Apr 2020 05:45:16 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 ECC033A0D4B; Sat, 25 Apr 2020 05:45:15 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id x4so14160067wmj.1; Sat, 25 Apr 2020 05:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uruHO0BS3MfI2mdwBOeqWfaX+uaabkzsNCJpWjo+cT0=; b=GbUNzBOKXdi8KBc+bfVeSqltFtrKSwSEH03+NOLcVxEX6VFd6ARmciaios4P5pPZjV Xce9Fv4ChiJdSCJqNSuSveoHaNPpfGnURbi+okE+8Bu6mMAoGR/4Qv66VTD6vlo2ZCma gQ4R9OrEC33DdCd5D0ZJaHwGtgQNY18pm+Qy+6vThwY6cfSkhV4tkidjxR0LX5aiZHmP QX5/0irz1jokL+cb/t2iTrnM/r69Z2VzFWMG7myAk6pxRvhwqgzlCK8L0+LIqnq+97sq JFPadyyPNCGpY1tINq4JLwRrWiMZR9JrAKb3dxdYy4PV5Bd4ZcgFjZbhNl9W0s6DyGyH SOUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uruHO0BS3MfI2mdwBOeqWfaX+uaabkzsNCJpWjo+cT0=; b=W+XHVDyBQCZ6uVojjSMnfiaS374/ixKKZHbZedoo8nD0p0bl8spsx+fiFdCUzpwPlg LDJqQEPPx77cqxQh2+S2O4OQn8XiUkcMYshqyr62C0OiWE2SgSizvJSfZxBvRLi2NwfO 4CB8crugCitB5t9bsKM+pOISAO1PmubQwNWO3rhUEnBwktWOPedISP+rG1pBRMVXjSZZ K3Y5qo6THNFXmjp1jdlUuZr6yKm46HiCJXyjCgUmQyd1MAtU35x2Esb1ncmMsFoiH1ks 5HQoxvFKCSqmaCABmkc4IwaPQjSulJcnPArZnxG4ZgcXye+zt7qRRozS8pZszUZywR0s AU6Q== X-Gm-Message-State: AGi0PuavCiptSvhdZGyZcqLWz6hZ7LYwQiYfxt2JkoGSc2VHTHnogO/v VB9sqaxl2p6s+D6E1vr+IOrC1F9GMrgelpPjAMa0oTo1 X-Google-Smtp-Source: APiQypJpn1nhi1HVH3fNB4D0uPt3admvvqh45GrSPrJvirt7yTV8ejKm9N0RpoOIcZlGYxy1k++ksTz2s90a4/H7wFo= X-Received: by 2002:a05:600c:28e:: with SMTP id 14mr16687767wmk.79.1587818714565; Sat, 25 Apr 2020 05:45:14 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 25 Apr 2020 12:45:13 +0000 From: Alvaro Retana In-Reply-To: <8BBF5B52-4CBE-4101-8FAD-CDB50D1149E3@arrcus.com> References: <8BBF5B52-4CBE-4101-8FAD-CDB50D1149E3@arrcus.com> MIME-Version: 1.0 Date: Sat, 25 Apr 2020 12:45:13 +0000 Message-ID: To: Keyur Patel , "draft-ietf-idr-tunnel-encaps@ietf.org" Cc: John Scudder , "idr-chairs@ietf.org" , "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000730dfd05a41cda1d" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 12:45:17 -0000 --000000000000730dfd05a41cda1d Content-Type: text/plain; charset="UTF-8" Ping! On February 25, 2020 at 12:09:11 PM, Keyur Patel (keyur@arrcus.com) wrote: Thanks for the detail review and comments. We will get back to you soon with our response. --000000000000730dfd05a41cda1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ping!

On Febru= ary 25, 2020 at 12:09:11 PM, Keyur Patel (keyur@arrcus.com) wrote:

Thanks for the detai= l review and comments. We will get back to you soon with our response.=C2=A0
--000000000000730dfd05a41cda1d-- From nobody Sat Apr 25 07:02:18 2020 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 40CA13A0FAE; Sat, 25 Apr 2020 07:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 6kHAswYgaS32; Sat, 25 Apr 2020 07:02:15 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2050.outbound.protection.outlook.com [40.107.237.50]) (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 8C99C3A0FAD; Sat, 25 Apr 2020 07:02:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WTKDlWavExAw/0iCtyXI9JcuNZX5RMc8BW6T+xfJ76GvINe6dn8H8NxGTHBwpKMvDlAWZBsE6KXK0UgLFSWLzG3k74qrW89t35leAslEJGnx2hUJl9/61KliPpZv3v52c7q1V3/L8vLgPsPNlKPpQrFfWKKAPzYXgnvjj71xJJOlRcbFVJIICamgITqilF/2CsHCv8miOUei8IqWdYcizcUz2PYESGRZADmpW5Md1eZu2BrQF26E15J61LuTJDuaNZeponiQK0SmMqvHaqZV6HiNw/fAn701ZIIIUW56KlmozQmrFKco1aNA1sJcUvANwT6I4uUyazsM27cyMHw88A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9McSg+1UFjfQkc45SWf1NnHW+UXfDLcVrz+MEEACePY=; b=nCDY1TYbVGWGezQqtHFk+vPZTDRxydVRDqAcw4+K1OX17DQFbMrR218gDjoh3sXFbjL/7EbVZsvAYz26M/zAf1GSkkWOkA/mk0ISTxfhZi8GCETYBtrSZ3H2NFY0RNrDKkENrpOnL8GhEdflOxrEwxYqA3I+6xmpx/q2zRPAt868aLk4txUiFk8jYG2de5MspawrSDi+zgi/su7lCk5vqoShxMP2CTtmABREbuvTTv9vcd5s0YbwGPmd5RPXIl6BhM73fzwc5RPJfk7Agw9WcmVhuugL8yTWTMvvGOQOgHqg7bkByiDs3fso9kj/Dv6pU5G5WjnBzLN6h7MzR5jQUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9McSg+1UFjfQkc45SWf1NnHW+UXfDLcVrz+MEEACePY=; b=AADmEhXupRqXT1nt2bGeiA7wsErugaGLyBFNPOB28eEjkFaaPMUe6GTanyQPNJOeE9daEBFrMEHR+3RYlBYt4fSg0pyMtcTmBD5LAzVovUheWNwsj6xlf8bA5HjsL6Ty34AYekcy2hHK3aUv7tvY7IJ0P1XJKdmfcmrfADzpnOk= Received: from BYAPR18MB2534.namprd18.prod.outlook.com (2603:10b6:a03:12e::29) by BYAPR18MB2360.namprd18.prod.outlook.com (2603:10b6:a03:12c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Sat, 25 Apr 2020 14:02:13 +0000 Received: from BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::280e:b668:2003:aa8]) by BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::280e:b668:2003:aa8%7]) with mapi id 15.20.2937.012; Sat, 25 Apr 2020 14:02:12 +0000 From: Keyur Patel To: Alvaro Retana CC: "draft-ietf-idr-tunnel-encaps@ietf.org" , John Scudder , "idr-chairs@ietf.org" , "idr@ietf. org" Thread-Topic: AD Review of draft-ietf-idr-tunnel-encaps-15 Thread-Index: AQHV6LUXjzaZiEFG+kyS9ZPP8NcJvKgrpQ4AgF6IQYCAABWDDw== Date: Sat, 25 Apr 2020 14:02:12 +0000 Message-ID: References: <8BBF5B52-4CBE-4101-8FAD-CDB50D1149E3@arrcus.com>, In-Reply-To: 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=keyur@arrcus.com; x-originating-ip: [2601:646:8700:a6f0:d83b:8272:bfe6:2a5c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42ae1a7f-8acc-43a3-02b2-08d7e92140f8 x-ms-traffictypediagnostic: BYAPR18MB2360: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 0384275935 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2534.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(346002)(39830400003)(366004)(396003)(376002)(76116006)(66946007)(66556008)(2616005)(8676002)(33656002)(6506007)(6512007)(86362001)(5660300002)(53546011)(36756003)(4744005)(6916009)(8936002)(66476007)(6486002)(508600001)(81156014)(64756008)(71200400001)(186003)(316002)(2906002)(4326008)(54906003)(66446008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rAf0zLj7MVFY/2++8w419y91WYQQ/aR4N88a9LftAxAw5ZIJbZohdFlP11hKd1EJP1wL+WAsvX8er94a79RMfwg9nUuAPY2E02PTtLHWNGCc2D851ZTVJxSi9gIDzEf+VbDDPWjV80ZJInGONA15rgxCLAXlJ3O4qQvWA4sVvGhGkbWnBhQ+C5R2CqQXd0EM10GiMPKa+iMtqPycS6UbA5IO0Uo/lJTg0W/fhnbTjCUBOumKX9NTAk9YxuOFQas1vNNXtFWDHAEEndoQ/sQBrTpOkGEilHRJaz8OfhbSehtYtPv6T9ybOEC5Uc0f9+3R/PFwIG4tqeKGguhWiB0LBnesnPCv0gOYFlwyCsAqXjT1hXJ+AMXU/2Q3FF1zW1o7lgSY+ww45YvSmD7u1xXwSJO/REf6lnXMC3z2+a5BpSHO8myZaE39aCLqIqaMWcT2 x-ms-exchange-antispam-messagedata: jRKpfmh88h59Pki4UaowczU9HywN8+sQt37Js14f0QgKUoh7YFPIP7mNZFuk+023sFqus6af/LVUnL20RGlEJu+2p0ZyPCbRPP/tAyxXnGm/W+zlJUcAIxDjthtzBZ0+Y6vT5spQor8542NUNaK632hZ82Nz35AzcbZpngvjE7jsVFSS1mlpCnCIyorgt3ZslG82JFIrw7pLe17GitZcYFRSg1uv7/QCOsg78ekE3BSbEgKugE/M8P8LkIKi1hA1Pmi79U6cuBeOyjGCeEWLkkFA+J30p3C9HVNBgqVeky1rhVA6GkVl6Z2Kr2VMHTdqUaPZwlfRLiMqwKYKzX6JExCCVFb7MKfUsa0SQRHoV+GxwDWBDc+VzB9OjTNkBZYJ+d1iOcjpMu5w6c7b6XTQcTDiCvWJKWgP5k+tW8OQoKMA2V/+cGr/Vw9kuhNAwjOFswG5YyVt9oYeA7YN9O6x7k/l3SucVXo/z0WRQ7fxsKwtWHs3qwd51Y5kNiJtXaA+U4Lm7wFcxYCykF4DLfW6CAGlRH4czQnhgXLKwTBV+VoUyLaYi7vSNSHHp7exF9WxT8QdJnO3xyvgjBb6kVruKc3+KlTgr4I468oWDvZ3p3DTvdnGHDW6AzysCQnoiX7NEUW0IVLOPdqvbEQA17IuXW0EXDzHIeDXrIj6UOrxerZbcHrnF0Irs00ealNIg4LmtZsXGwmW1Ao26jyq0+LgL3UsVFWeAyAkQIR9hGbwPIlz2lMmpqkcEy8nKKRyv0fDEvj/Lk5f8vfp8guRkI6l4MKUdfQ8iO8MbghnCiIMy96kdfet1bBeO3wFBcJy8+d4XGMo3unQLk9suRT6gXFyOMgaxyuG9yVr2BiuL67hiPk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BB2008F1D8DB490DBD961C7BCE20F0ACarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42ae1a7f-8acc-43a3-02b2-08d7e92140f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2020 14:02:12.7723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iCAubS5S+lJgjQz84UrlIbpR+EyUnciXLJIz3fTxPmcqKTprf/27/EagEJ8G1osq/r1ocjudSZtHw81vISVxWQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2360 Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 14:02:18 -0000 --_000_BB2008F1D8DB490DBD961C7BCE20F0ACarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpXZSBhcmUgd29ya2luZyBvbiB5b3VyIHJldmlldyBjb21tZW50cy4gV2Ug d2lsbCBzZW5kIHRoZSByZXBseSBzb29uLg0KDQpBcG9sb2dpZXMgZm9yIHRha2luZyBpdCBhIGJp dCBsb25nLg0KDQpSZWdhcmRzLA0KS2V5dXINCg0KT24gQXByIDI1LCAyMDIwLCBhdCA1OjQ1IEFN LCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0K77u/DQpQ aW5nIQ0KDQoNCk9uIEZlYnJ1YXJ5IDI1LCAyMDIwIGF0IDEyOjA5OjExIFBNLCBLZXl1ciBQYXRl bCAoa2V5dXJAYXJyY3VzLmNvbTxtYWlsdG86a2V5dXJAYXJyY3VzLmNvbT4pIHdyb3RlOg0KDQpU aGFua3MgZm9yIHRoZSBkZXRhaWwgcmV2aWV3IGFuZCBjb21tZW50cy4gV2Ugd2lsbCBnZXQgYmFj ayB0byB5b3Ugc29vbiB3aXRoIG91ciByZXNwb25zZS4NCg== --_000_BB2008F1D8DB490DBD961C7BCE20F0ACarrcuscom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IGRpcj0ibHRyIj5IaSBBbHZhcm8sPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rp dj4NCjxkaXYgZGlyPSJsdHIiPldlIGFyZSB3b3JraW5nIG9uIHlvdXIgcmV2aWV3IGNvbW1lbnRz LiBXZSB3aWxsIHNlbmQgdGhlIHJlcGx5IHNvb24uJm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0ibHRy Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPkFwb2xvZ2llcyBmb3IgdGFraW5nIGl0IGEg Yml0IGxvbmcuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJs dHIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5LZXl1cjwvZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gQXByIDI1LCAyMDIwLCBhdCA1 OjQ1IEFNLCBBbHZhcm8gUmV0YW5hICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/IDxzdHlsZT5ib2R5e2ZvbnQtZmFtaWx5OkhlbHZldGlj YSxBcmlhbDtmb250LXNpemU6MTNweH08L3N0eWxlPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij5QaW5nITwvZGl2Pg0KPGJyPg0KPHAgY2xh c3M9ImFpcm1haWxfb24iPk9uIEZlYnJ1YXJ5IDI1LCAyMDIwIGF0IDEyOjA5OjExIFBNLCBLZXl1 ciBQYXRlbCAoPGEgaHJlZj0ibWFpbHRvOmtleXVyQGFycmN1cy5jb20iPmtleXVyQGFycmN1cy5j b208L2E+KSB3cm90ZTo8L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iY2xlYW5f YnEiPjxzcGFuPg0KPGRpdj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWls eTonaGVsdmV0aWNhIE5ldWUnLGhlbHZldGljYTtmb250LXNpemU6MTRweDtmb250LXN0eWxlOm5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1z cGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5z Zm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91bmQt Y29sb3I6cmdiKDI1NSwyNTUsMjU1KTtkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQ7ZmxvYXQ6bm9u ZSI+VGhhbmtzDQogZm9yIHRoZSBkZXRhaWwgcmV2aWV3IGFuZCBjb21tZW50cy4gV2Ugd2lsbCBn ZXQgYmFjayB0byB5b3Ugc29vbiB3aXRoIG91ciByZXNwb25zZS48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9zcGFuPjwvYmxv Y2txdW90ZT4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+PC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BB2008F1D8DB490DBD961C7BCE20F0ACarrcuscom_-- From nobody Sat Apr 25 15:37:05 2020 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 A20CE3A0BF2; Sat, 25 Apr 2020 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 5smjR5_A3XVl; Sat, 25 Apr 2020 15:37:00 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 7CF743A0BF0; Sat, 25 Apr 2020 15:37:00 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id o15so6592758pgi.1; Sat, 25 Apr 2020 15:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=jfMSg7TwPbdbHLyPKGfiAU8C4ItUOQoJRIxInN+6RWM=; b=nLXW8eI0UCAP4GaaGHXUIiO+kDa7SKE+X7AokMqa+AwEb+9VS6c0KPNZ1IMXYm6Ocb b1E5E9W0VzlTY242ufcL5ZYm9CjMuTUvFSIqqrswltLPnV14taAndQIyHCp+ZID94nDV FqeWSaAfpD8Cl4Z0muoHf6BK2FN2GZ5POOWYFjf8x+dfG2XdAVpDqWTdwzUePhQ/9e+N 3r90oRRmjTGuq8eYG8LeoUK/EG1D71Xj8M2JUgPm2w2VVkrAdb8MrAbpCYzxjNcVD+Eh FSyafbSQZ0mQ6Z6Et5n/4H6qXr8zUKYb0dGM0F29Y978Sdg89DawoFCeNpEtybruabWV EV/A== 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:message-id:in-reply-to :references:subject:mime-version; bh=jfMSg7TwPbdbHLyPKGfiAU8C4ItUOQoJRIxInN+6RWM=; b=fCojFkVR4p/NiUjbaeqTw+4eLtCCbTWHDtlL6rmFDxGq17Osm9HGbAwD+neHWK6T5v I6ctfSGpfZZvGU9udqS1zVb4WwY9PLqhkcy1yxpxU95bj8hWBz07OeQG+cTBOPm7L0Hn QDajulN3KZz/hJF3VkQTKNIw6r5H8N9ZirlGggNwRG9SU+S8CDHUK5vAwAs9AVETRtXW ++KD9EI0NyAN8859hh9TIhFZVDMqoPsLjr+rYbcgXhwYidwOM2f+nSfbTPMK7WpjPjYM djNUfQO0EPweLzKi5yKcj4XdkYicaqhSf06Q5Zw8HY7GG85wYETITWmzZVpv06v0gZok gC5w== X-Gm-Message-State: AGi0PubmcAdkRjNbTCepSVIrl+NlsAl1uVqwBNsp5kjKUNDOVu4pEa1k HdUR67MRVvEM1Pq+1AlESPY= X-Google-Smtp-Source: APiQypJwJpVz9pgGWa1U77WMf4RHu7jBN37cCbuHTt6X/AMowFgNDB7NID7PmchR2ks84HRDMQEFXg== X-Received: by 2002:a62:cf06:: with SMTP id b6mr17484200pfg.9.1587854219924; Sat, 25 Apr 2020 15:36:59 -0700 (PDT) Received: from [192.168.1.5] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id y186sm8706514pfy.66.2020.04.25.15.36.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2020 15:36:59 -0700 (PDT) Date: Sat, 25 Apr 2020 15:36:52 -0700 From: Jeff Tantsura To: Alvaro Retana , Martin Duke Cc: Martin Duke via Datatracker , Susan Hares , The IESG , draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr@ietf.org, idr-chairs@ietf.org Message-ID: In-Reply-To: References: <158774729288.14012.4297480673585471299@ietfa.amsl.com> X-Readdle-Message-ID: fa1723a1-87e7-4153-803f-a42b82f43abf@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5ea4bb89_501f9786_181f7" Archived-At: Subject: Re: [Idr] Martin Duke's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 22:37:03 -0000 --5ea4bb89_501f9786_181f7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Martin, Thanks for your comments. Please note - =C2=A0MSD value as such is opaque to the network carrying i= t and in no way influences routing decisions. The end-goal is to provide this information to a controller that could us= e it to compute a path that could be instantiated on a node with particul= ar HW contains. In other words - the processing logic is really outside of IGP/BGP. While R=46C8491 has the following statement in the Node MSD section -=C2=A0= =22This value MUST=C2=A0represent the lowest value supported by any link = configured for use=C2=A0by the advertising IS-IS instance=E2=80=9D it meant for the case where there is Node MSD only. Later in the document, in the section =22Procedures for Defining and Usin= g Node and Link MSD Advertisements=E2=80=9D it is stated: =22When Link MSD is present for a given MSD-Type, the value of the Link=C2= =A0MSD MUST take precedence over the Node MSD=E2=80=9D and that addresses exactly your use case. To summarize: it is allowed to advertise both, Node MSD and Link MSDs from the same nod= e it is upto the path computational logic to decide how to use these values= Hope this clarifies. Many thanks and have a great weekend=21 Cheers, Jeff On Apr 24, 2020, 12:16 PM -0700, Martin Duke ,= wrote: > Bummer=21 Thanks for the reply. > > > On =46ri, Apr 24, 2020 at 11:55 AM Alvaro Retana wrote: > > > On April 24, 2020 at 12:54:53 PM, Martin Duke wrote: > > > > > > > > > Martin: > > > > > > Hi=21 > > > > > > > > > > This is not a DISCUSS-level concern, but I found it odd that the = Node MSD TLV > > > > must be the minimum of all configured interfaces without regard f= or the > > > > presence of any Link MSD TLVs. > > > > > > > > =46or example, if all node interfaces have an MSD of 20 except on= e with an MSD > > > > of 10, it would be much more compact to advertise a Node MSD of 2= 0 and a > > > > single Link MSD of 10. Section 5 says the Link MSD would take pre= cedence, so > > > > there would be no information loss. As I understand the spec, thi= s would not > > > > be allowed, and each link would have to be advertised separately = to gain that > > > > level of granularity. > > > > > > > > If this is not the intent, then in Section 3, extending a sentenc= e to say > > > > =22Node MSD is the smallest MSD supported by the node on the set = of interfaces > > > > configured for use, =5Bexcepting links advertised with their own = Link MSD TLV=5D=22 > > > > would avoid the problem. > > > > > > This could have been a good optimization. > > > > > > However, this ship has sailed.=C2=A0 BGP-LS is a mechanism to carry= > > > topology related information to a central controller.=C2=A0 This > > > information, as in this case, is obtained from the IGPs (OSP=46 or > > > IS-IS).=C2=A0 IOW, BGP-LS is simply carrying the same information t= hat > > > IS-IS/OSP=46 generated...with the same semantics, which is what the= > > > controller is expecting.=C2=A0 The corresponding IGP specifications= > > > (rfc8491/rfc8476) contain the same language...if we change this > > > document then we would have to change the IGP documents...and all t= he > > > implementations. :-( > > > > > > Thanks=21 > > > > > > Alvaro. --5ea4bb89_501f9786_181f7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Martin,

Thanks for your comments.

Please note - &=23160;MSD value as such is opaque t= o the network carrying it and in no way influences routing decisions.&=23= 160;
The end-goal is to provide this information to a co= ntroller that could use it to compute a path that could be instantiated o= n a node with particular HW contains.
In other words - the processing logic= is really outside of IGP/BGP.&=23160;

While R=46C8491 has the following statement in the = Node MSD section -&=23160;=22This value MUST&=23160;= represent the lowest value supported by any link configured= for use&=23160;by the advertising IS-IS instance=E2= =80=9D
it meant for the case where there is = Node MSD only.

Later in the document, in the section= =22= Procedures for Defining and Using Node and Link MSD Advertisements=E2=80=9D= it is stated:
=22When Link MSD is present for a given MSD-Type, the value of= the Link&=23160;MSD MUST take precedence over the Node MSD= =E2=80=9D
and that addresses exactly your use c= ase.

To summarize:&=23160;
it is allowed to advertise both, Node= MSD and Link MSDs from the same node
it is upto the path computational log= ic to decide how to use these values

Hope this clarifies.

Many thanks and have a great weekend=21

Cheers,
Jeff
On Apr 24, 2020, 12:16 PM -0700, Ma= rtin Duke <martin.h.duke=40gmail.com>, wrote:
Bummer=21 Thanks for the reply.

On =46ri, Apr 24, 2020 at= 11:55 AM Alvaro Retana <aretana.ietf=40gmail.com> wrote:
On Apr= il 24, 2020 at 12:54:53 PM, Martin Duke wrote:


Martin:

Hi=21


> This is not a DISCUSS-level concern, but I found it odd that the Nod= e MSD TLV
> must be the minimum of all configured interfaces without regard for = the
> presence of any Link MSD TLVs.
>
> =46or example, if all node interfaces have an MSD of 20 except one w= ith an MSD
> of 10, it would be much more compact to advertise a Node MSD of 20 a= nd a
> single Link MSD of 10. Section 5 says the Link MSD would take preced= ence, so
> there would be no information loss. As I understand the spec, this w= ould not
> be allowed, and each link would have to be advertised separately to = gain that
> level of granularity.
>
> If this is not the intent, then in Section 3, extending a sentence t= o say
> =22Node MSD is the smallest MSD supported by the node on the set of = interfaces
> configured for use, =5Bexcepting links advertised with their own Lin= k MSD TLV=5D=22
> would avoid the problem.

This could have been a good optimization.

However, this ship has sailed.&=23160; BGP-LS is a mechanism to carry
topology related information to a central controller.&=23160; This
information, as in this case, is obtained from the IGPs (OSP=46 or
IS-IS).&=23160; IOW, BGP-LS is simply carrying the same information that<= br /> IS-IS/OSP=46 generated...with the same semantics, which is what the
= controller is expecting.&=23160; The corresponding IGP specifications
(rfc8491/rfc8476) contain the same language...if we change this
document then we would have to change the IGP documents...and all the
implementations. :-(

Thanks=21

Alvaro.
--5ea4bb89_501f9786_181f7-- From nobody Sat Apr 25 19:36:18 2020 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 C953C3A0884; Sat, 25 Apr 2020 19:35:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Susan Hares , aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <158786855637.10016.12333619618398787606@ietfa.amsl.com> Date: Sat, 25 Apr 2020 19:35:56 -0700 Archived-At: Subject: [Idr] Murray Kucherawy's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 02:35:58 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-idr-bgp-ls-segment-routing-msd-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just some nits: Section 1: * "... and controller does not participate ..." -- should be "the controller" Section 1.1.1: * Though the term "PCC" is in this glossary, it is not used anywhere in this document. Section 7: * "The extensions specified in this document, do not specify ..." -- remove the comma From nobody Sun Apr 26 13:13:42 2020 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 D53443A10AB; Sun, 26 Apr 2020 13:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq5w2bibpd9J; Sun, 26 Apr 2020 13:13:17 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 DA5353A10AA; Sun, 26 Apr 2020 13:13:17 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id n24so6083551plp.13; Sun, 26 Apr 2020 13:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=ogUP6DXMWtVyLNgcufgw8Ub0IWmmFPJdjGMg7LaLzw0=; b=Wf/6rjj7JOZZrdGCFLhE4JxWq/wEab4VizE19ReCA1WDzamzhCzLI0OWBzQwxu8Yi3 C3ydzIf1Tan7acRR8yINzsHn95A3V8NIbQDZsw7BE0pISvxqzd+8k+lbClA2eMCQaAd7 3PdJckajuVjYdUStwJe+DKxcJH02JdsoKROUUawJHgkf2HzijpzZsqIqEaJDXt6PxS1P moydsTk15lI7UbuOOEz5PX1lZFFSW6uBENJeLQq438j0xGpLB2cN5mVo3P9bbtuXocmg YfjWfUp94rruu4KzORX090M/wnMri8bp7yZ6PBrXoG6nKobAbCs13MXa8DXSQBgigNAS ofbw== 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:message-id:in-reply-to :references:subject:mime-version; bh=ogUP6DXMWtVyLNgcufgw8Ub0IWmmFPJdjGMg7LaLzw0=; b=KTC8XEhgnf//NoATHGgNpczBEsA0ir3nPq9d9v/uHnEvbGml596v0VHHv6ooR7w97P Nf9YhXcGZ1CEWYBfq3s3FOK/L9Gftjobg/dZA9+6bM6lxZ+CYmuswN/hgcdlFyqv4zV1 rNuE9BcqUUVKh6wx8Vs38LiYYwELYTAYz9OVE3F4ZbT/iankxbXCLF1ZNw2WXSophcCJ Hshsk4dIl23NRUdDMZFGej7BNDJhtgzlxPBsVInEpBPgVz+vRaE4R1IjIFpxQQZ43eRG wpztkFguPLQdAsPpBatheu1mqcO1+dRJ/ktNDK5DLhwsvQ+XEMrOkYmx0yxqbC1v3fJU b9PQ== X-Gm-Message-State: AGi0PuZUEuTHBPbuFPoEKB3+6cijIGYB4kDK4sZGVmKHUbJrUtCLDaTE flB51taS4mOdcw/yoyIDckv1vMmZ X-Google-Smtp-Source: APiQypKB9Rclsy9gRV37q0tTL+dZy8lQTSXCuSNxXI5D5IktbWWh6qUwODKrWZzADwno9+QmfFhrhw== X-Received: by 2002:a17:902:59cc:: with SMTP id d12mr12942538plj.237.1587931996929; Sun, 26 Apr 2020 13:13:16 -0700 (PDT) Received: from [192.168.1.5] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id f21sm10655758pfn.71.2020.04.26.13.13.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 13:13:15 -0700 (PDT) Date: Sun, 26 Apr 2020 13:13:09 -0700 From: Jeff Tantsura To: The IESG , Murray Kucherawy Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Susan Hares , aretana.ietf@gmail.com Message-ID: In-Reply-To: <158786855637.10016.12333619618398787606@ietfa.amsl.com> References: <158786855637.10016.12333619618398787606@ietfa.amsl.com> X-Readdle-Message-ID: da5de4b8-275d-46b6-aee4-c7c47f35fdb8@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5ea5eb5a_471745e4_181f7" Archived-At: Subject: Re: [Idr] Murray Kucherawy's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 20:13:20 -0000 --5ea5eb5a_471745e4_181f7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi=C2=A0Murray, Many thanks for your review=21 Please see inline Cheers, Jeff On Apr 25, 2020, 7:35 PM -0700, Murray Kucherawy via Datatracker , wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-idr-bgp-ls-segment-routing-msd-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (=46eel free to cut th= is > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-= msd/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Just some nits: > > Section 1: > * =22... and controller does not participate ...=22 -- should be =22the= controller=E2=80=9D =5Bjeff=5Dack, changed > > Section 1.1.1: > * Though the term =22PCC=22 is in this glossary, it is not used anywher= e in this document. =5Bjeff=5D ack, removed > > Section 7: > * =22The extensions specified in this document, do not specify ...=22 -= - remove the comma =5Bjeff=5D ack, removed > > > --5ea5eb5a_471745e4_181f7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi&=23160;Murray,

Many thanks for your review=21
Please see inline

Cheers,
Jeff
On Apr 25, 2020, 7:35 PM -0700, Mur= ray Kucherawy via Datatracker <noreply=40ietf.org>, wrote:
Mu= rray Kucherawy has entered the following ballot position for
draft-ietf-idr-bgp-ls-segment-routing-msd-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (=46eel free to cut this=
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
= https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ms= d/



---------------------------------------------------------------------- COMMENT:
----------------------------------------------------------------------
Just some nits:

Section 1:
* =22... and controller does not participate ...=22 -- should be =22the c= ontroller=E2=80=9D&=23160;
=5Bjeff=5Dack, changed
Section 1.1.1:
* Though the term =22PCC=22 is in this glossary, it is not used anywhere = in this document.&=23160;
=5Bjeff=5D ack, removed
Section 7:
* =22The extensions specified in this document, do not specify ...=22 -- = remove the comma&=23160;
=5Bjeff=5D ack, removed


--5ea5eb5a_471745e4_181f7-- From nobody Sun Apr 26 13:15:14 2020 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 BC9243A10B1; Sun, 26 Apr 2020 13:15:11 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158793211170.25379.14246182785266355541@ietfa.amsl.com> Date: Sun, 26 Apr 2020 13:15:11 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-msd-17.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 20:15:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State Authors : Jeff Tantsura Uma Chunduri Ketan Talaulikar Greg Mirsky Nikos Triantafillis Filename : draft-ietf-idr-bgp-ls-segment-routing-msd-17.txt Pages : 10 Date : 2020-04-26 Abstract: This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-17 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-msd-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-msd-17 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 Sun Apr 26 13:28:18 2020 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 412463A1118; Sun, 26 Apr 2020 13:28:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Theresa Enghardt via Datatracker To: Cc: last-call@ietf.org, idr@ietf.org, draft-ietf-idr-capabilities-registry-change.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158793289621.976.611584354541089569@ietfa.amsl.com> Reply-To: Theresa Enghardt Date: Sun, 26 Apr 2020 13:28:16 -0700 Archived-At: Subject: [Idr] Genart last call review of draft-ietf-idr-capabilities-registry-change-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 20:28:17 -0000 Reviewer: Theresa Enghardt Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-idr-capabilities-registry-change-?? Reviewer: Theresa Enghardt Review Date: 2020-04-26 IETF LC End Date: 2020-04-30 IESG Telechat date: Not scheduled for a telechat Summary: The documents is short and to the point. While its purpose is already very clear, I noticed two minor points that could further add to document clarity. Major issues: None. Minor issues: To make this document more self-contained, it would be nice to include one or two sentences to the introduction that briefly explain what BGP Capabilities are. Regarding the code points that are now assigned as "First Come First Serve" in Section 3, the document points to drafts for some of them, but not for all. Is there any documentation for the code points that are currently without any reference? If so, please provide a reference. If not, maybe it's worth briefly stating that for some of them there is no reference and that they are all deprecated, e.g., because they were used in past experiments. For code point 129, a reference to a draft is provided in the "Description" column, while for code point 185, a reference to a draft is provided in the "Reference / Change Controller" column. Is this intentional? If not, please consider unifying the presentation here. Otherwise, please consider making clear why the references are in different columns. Nits/editorial comments: None. From nobody Mon Apr 27 01:59:39 2020 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 3755C3A133E; Mon, 27 Apr 2020 01:59:28 -0700 (PDT) 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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158797796818.20048.4808180522981335650@ietfa.amsl.com> Date: Mon, 27 Apr 2020 01:59:28 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 08:59:28 -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 Ketan Talaulikar Jie Dong Mach(Guoyi) Chen Hannes Gredler Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-13.txt Pages : 49 Date : 2020-04-27 Abstract: This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a node and advertise it into BGP Link State (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-13 https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-13 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 Mon Apr 27 07:11:32 2020 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 2669D3A0B43; Mon, 27 Apr 2020 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 header.b=jUnRRRPU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E0EBW99v 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 LS6dxiWA7CIi; Mon, 27 Apr 2020 07:11:21 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C183A0B44; Mon, 27 Apr 2020 07:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5630; q=dns/txt; s=iport; t=1587996681; x=1589206281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lIumjN5FR1jJVHmd4mk/7pElJLdUi34G/BX5VQY6MLg=; b=jUnRRRPUOut81i8QqnRHbbj8qQqocq1TWdATOqNdbG9O4qcrfoa92xcx Lk/ur9f7Id3nuMfFxtX6Jif1REGsVfQ9I+XJ7uQiDKQ3ocmv1eaThC22P ZJT+TUAENBU3A3RFSMHsKmGTNCoSCv2Er2AlIduIIeH4cWjJ4B1wsFllq 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AWg1G8RDT6J2MjE/TUSQqUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeD7aSc5EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwCACI56Ze/5hdJa1mHQEBAQkBEQU?= =?us-ascii?q?FATyBR4FUKSgFbFggBAsqhB+DRgOKcoI6JYEBiHWOOYJSA1QLAQEBDAEBJQg?= =?us-ascii?q?CBAEBhEQCF4IRJDgTAgMBAQsBAQUBAQECAQUEbYUqByUMhXEBAQEBAxIREQw?= =?us-ascii?q?BATcBCwQCAQgOAwMBAgMCIwMCAgIfERQBBQMIAgQBDQUigwQBgksDLgEOpyY?= =?us-ascii?q?CgTmIYXaBMoMAAQEFhTENC4IOAwaBDiqCY4laGoFBP4ERJwwQghg1PoIeSQE?= =?us-ascii?q?BAoFjgxIygi2ON4MEkHCPMUoKgkWID4V0hTYEhEMdgluNToxSg2iMEolIgkW?= =?us-ascii?q?QeQIEAgQFAg4BAQWBaSKBVnAVZQGCCgEBATFQGA2QUGQMFxVuAQQEgkOFFIV?= =?us-ascii?q?CdDUCBgEHAQEDCQF7jiABAQ?= X-IronPort-AV: E=Sophos;i="5.73,324,1583193600"; d="scan'208";a="483136254" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Apr 2020 14:11:20 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03REBKSu018009 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2020 14:11:20 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 09:11:19 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 09:11:19 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Apr 2020 10:11:19 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HECqR2o3wt6voZz4afcm4E/P4jc/Mrgl+iMReAo1q+NACTriwPkF0fJbj2ruL5EfgEtsoWNLXXnRyvY7qxP2Ao2VLs+gzRUiNnNgXsyRugEBj+wluyT+33HlJIgVaZS+aYiz1Ak8tiY0xl4AD0ikRK/xQPxKfrOzklvTeXrVgBOZH4l5MOrHziyd5vl6/3uXf35bA4cOpKupwCRPzMvze+TWlSmC0cxo3numJ1hlN9D2LdRztwFL19oxXXm8LNxDYi73CXWPzv7LjzYvnCjift1jmRE4J+STQO0DyuXqCDbVc5kjqOZzsiux5gYc74zKH5bNrx/78RzuU2xQLslzHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lIumjN5FR1jJVHmd4mk/7pElJLdUi34G/BX5VQY6MLg=; b=FFmMYfJKlX4dhHrc0iNOTvkhbtqP2RydNY+frU2ZDm7CAy6TEmTrCSqF5KfbSN1p8ONYaaKp6wOt+Fi3oBu3A4ey2P2aJrkYP4PRfAZlhUm02NYyq/13Gb5qP6zCrTBt8fyOFc9xTGr4OC/8kwK9AmIJL7cmljtrUasCySJ46U/h9H+rSfRE+tXnaHM77oZQQZdg/MU3gnZdMqoYVsOIed0W/Av+Vk8KQycxVs3OfYISRbssXXvN0wUZK/RxJZyoEtKWeLQYkry6UDu1+YlR1FAVA/yYiI6nWLLoWdgEuFJKlm/uDSmApqK0vC9FGxzwEFOzQqQ18j6+ac+KsegbuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lIumjN5FR1jJVHmd4mk/7pElJLdUi34G/BX5VQY6MLg=; b=E0EBW99v23bCMtO4havF6ggwAMW/CefrzwBledoFRY0H4UrQRN9zSZv1p99CrSlPa6XosbU9ZKAypbdWLklkQKmHBYLwqRD4OczupZNZuSkyAl7scx/SH7SVmUiuRTDOHUN0y1SLvsv5a4kJwRj8IMPNuxPFr7521rlsOEBlscA= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1740.namprd11.prod.outlook.com (2603:10b6:3:112::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 14:11:18 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c%9]) with mapi id 15.20.2937.020; Mon, 27 Apr 2020 14:11:18 +0000 From: "Eric Vyncke (evyncke)" To: Alvaro Retana , =?utf-8?B?w4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcg==?= , "The IESG" CC: "idr-chairs@ietf.org" , "draft-ietf-idr-rfc5575bis@ietf.org" , Jie Dong , "idr@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWlkci1yZmM1?= =?utf-8?Q?575bis-23:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWGj9qlYzMYaYBREuQQfjux/Gfb6iIip0AgASd2oA= Date: Mon, 27 Apr 2020 14:11:18 +0000 Message-ID: References: <158773622329.9749.4475217266475729122@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:241a:6b8c:3763:7c9d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 741c7def-5de4-47a3-45ca-08d7eab4dae0 x-ms-traffictypediagnostic: DM5PR11MB1740: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(396003)(376002)(346002)(966005)(71200400001)(6512007)(478600001)(2906002)(54906003)(81156014)(8936002)(6506007)(53546011)(316002)(110136005)(6486002)(4326008)(33656002)(186003)(224303003)(2616005)(66556008)(86362001)(66476007)(66946007)(66446008)(64756008)(76116006)(91956017)(36756003)(5660300002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r5azDMYiceaSEyoWusom6NmGaxn7OdsL3WJiPsYAgfDlWUEPqUuDrwAI3ahfBjucq6twHKGsRNFg6GreveQ41kHoUS0Q2bXv+VG9mHf3CktnxxhV3p/I37sB6+MQJusKuRyWW9u/svBRA9KBpvrO3Gjql7TnGLGkP6+LRpeCQu0+OyA5xvPq7yimTJt3elDUGi+nduTAD2+rjKwpL45yw6EK6VLbs9+Ck8n5ph924fwT4J+uneSa4NxUT1iRJqDZwYZlEGehZ/MIPbQfOKi7VUru5MLS7I2Z/ddzsS+cekpqdoDJeW6K2a5WICYdz9QPelktDhasjBo8zYGTfVAGV4cs7O+n/m62r+9k/O7+Z9i3Azl9UvWVXE34xFn/cROJDQ17tUbFBRXJ8gtOIgW/gvHDA836YG9uSQi9B06NIx8zXQivWlwNMDAjyidrEKYozCk6dfOyCS5tswLlf6yGWlSMg2M25FQVuvqkL48+Kb4nCww2c08x7gEVJ6aPc4+3Rf5Hhly2rT9f19OCvZRgrQ== x-ms-exchange-antispam-messagedata: Qb2XkfSyMCAoVfxdEP2AUq75FIwfWVGGefJQhDNOfsnjcgtUiLJVLofUaYKPlXXPoasb+jOmlgyuDRHqTwHVOeyK+Xqd0s65fJ6pDCoVmwodXFvNAjAghBzMmXIak5OVmrczSFna6mi4Sm3Cz5IYVPSurM4dOXQ8K7RacVgq/4Fk8QWTDnN7iucoqtj0Z2tmvT0+4PVt+7npjCwk2uftykqDMQXQBsII2Y1o5avT1ckynkDXvdNHWxic6+8Uf7A9+6CbPVXB3aF+pUnZ3T3wYMo5WgDuFb8yyqFRFRQQjUQE0IDSkPo/MEXerFdEOGguHyi+eyvkhvAxAS/61eqoKeAJMIShZ8j1onijYGjDbLftJvJJD57uL/99CBzEvcrENWEGRnPHWlHnRVuYB2s2g55rHqrsZoJIZzhZ1hNPQd8fdPjINXzAKELW/ta+/nFVPdtOer0/k0QRKFK3yQ/dmUFMeutffGftz51nFB+T8VgF1IkG5ubT3gvY1AR/YoQMAvQLYYfJi9k3zjeCbE//BZ+T3w0ZZtJIthxpdlVesEQYO/Y0oXdrB250JeyxMwogRRInvx7aWXv7v21go1xh/ZEAv444d4Dz6afAhtR9ib4hrSxXCRoWL2FDNjuBHSrcYQUpZNoIG+ly9ntabGiEe83eaoIKN7BGzNHypzKY7mV88/eLJsim5n4qvlcJYuWdUULHwIpmORVan3+1jyaDWEN7MWAMwyS7qLSSnjq3mwPP1ZRQAz1KAzM8URE4XqqPJfMiJhtKENiOF54WZxRecngfCwbHP9W/bPte1tNofXvTy4R+MHKnMnVooh+p0rA6pVnugN/bvaZmnQPZVuKdKwNhOSzRsHHthAFXi+JDb/s= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7E23C2AD711683448CB9A5EDD480D24D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 741c7def-5de4-47a3-45ca-08d7eab4dae0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 14:11:18.1389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eEyqr77JeCjqWJeaxPrObFAdVt+8W3zbRN2Bj2UfK6FaEEanlyfkIdr3dQmYoU/JhXs7S57dSUgPfV0DzgGKUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1740 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 14:11:26 -0000 QWx2YXJvLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZGV0YWlsZWQgcmVwbHkuIEFib3V0IHlvdXIg cG9pbnQgMSksIFN1ZSBoYXMgaW5kZWVkIHVwZGF0ZWQgdGhlIGltcGxlbWVudGF0aW9uIHdpa2kg cGFnZSBhbmQsIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhlIElEUiBwcm9jZXNzZXMsIHRo aXMgc2hvdWxkIGFsbG93IHRoZSBXR0xDICYgcHVibGljYXRpb24gb2YgdGhlIElQdjYgZG9jdW1l bnQuIA0KDQpXaXRoIHRoaXMgbmV3IGVsZW1lbnQsIGRvIHlvdSAoYW5kIHRoZSBXRyBjaGFpcnMp IGJlbGlldmUgdGhhdCBtYWtpbmcgYSBjbHVzdGVyIGlzIGRvYWJsZSA/IEVsc2UsIEkgYW0gdHJ1 c3RpbmcgeW91IGFzIHJlc3BvbnNpYmxlIEFEIGFuZCB0aGUgY2hhaXJzIHRvIGV4cGVkaXRlIHRo ZSBJUHY2IGRvY3VtZW50IHByb2Nlc3NpbmcgKGluY2x1ZGluZyAnanVtcGluZyB0aGUgUkZDRSBx dWV1ZScpIHRvIGhhdmUgdGhlbSBwdWJsaXNoZWQgcm91Z2hseSBhdCB0aGUgc2FtZSB0aW1lLiBU aGlzIGlzIGluZGVlZCB2ZXJ5IHNpbWlsYXIgdG8gYSBmb3JtYWwgY2x1c3Rlci4NCg0KSWYgd2Ug YWdyZWUgb24gdGhlIGFib3ZlIChleHBlZGl0ZSBwcm9jZXNzaW5nIGZvciBJUHY2IGRvY3VtZW50 IGFuZC9vciBjbHVzdGVyKSB0aGVuIEkgYW0gY2xlYXJpbmcgbXkgRElTQ1VTUy4NCg0KUmVnYXJk cw0KDQotw6lyaWMNCg0KUFM6IHN0aWxsIHdvbmRlcmluZyB3aHkgdGhpcyBzaXR1YXRpb24gYXJp c2UgaW4gMjAyMCA6LU8NCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IEZyaWRheSwgMjQg QXByaWwgMjAyMCBhdCAxOTo0MQ0KVG86IMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgPG5v cmVwbHlAaWV0Zi5vcmc+LCBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+LCBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiAiaWRyLWNoYWlyc0BpZXRmLm9yZyIgPGlkci1jaGFpcnNA aWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1pZHItcmZjNTU3NWJpc0BpZXRmLm9yZyIgPGRyYWZ0LWll dGYtaWRyLXJmYzU1NzViaXNAaWV0Zi5vcmc+LCBKaWUgRG9uZyA8amllLmRvbmdAaHVhd2VpLmNv bT4sICJpZHJAaWV0Zi5vcmciIDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogw4lyaWMgVnlu Y2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLTIzOiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKQ0KDQogICAgRXJpYzoNCg0KICAgIEhpIQ0KDQogICAgSSBhcHByZWNp YXRlIGFsbCB5b3VyIGhhcmQgd29yayBvbiBtYWtpbmcgc3VyZSB0aGF0IElQdjYgaXMgYWx3YXlz IGNvbnNpZGVyZWQuDQoNCiAgICBIb3dldmVyLCBJIGRpc2FncmVlIHdpdGggeW91ciByZXF1ZXN0 Lg0KDQogICAgKDEpIElQdjYgaGFzIGJlZW4gY29uc2lkZXJlZC4gVGhlIFdHIGhhcyBjb21wbGV0 ZWQgdGhlIHdvcmsgb24gRmxvd1NwZWMgZm9yDQogICAgICAgIElQdjYg4oCUIGl0IGlzIGp1c3Qg d2FpdGluZyBmb3IgaW1wbGVtZW50YXRpb24gcmVwb3J0cy4gW1N1ZSBhbHJlYWR5IHVwZGF0ZWQN CiAgICAgICAgdGhlIHRyYWNraW5nIHBhZ2UuIFsxXV0NCg0KICAgICgyKSBCeSByZXF1aXJpbmcg am9pbnQgcHVibGljYXRpb24sIHlvdSBhcmUgZWZmZWN0aXZlbHkgb3ZlcnR1cm5pbmcgdGhlIFdH DQogICAgICAgIGNvbnNlbnN1cyB0byBjbGVhbiByZmM1NTc1IHVwIGFuZCBsZWF2ZSBuZXcgZnVu Y3Rpb25hbGl0eSB0byBuZXcNCiAgICAgICAgZG9jdW1lbnRzLiBBcyBTdWUgYWxyZWFkeSBtZW50 aW9uZWQsIHRoZSBJUHY2IGZ1bmN0aW9uYWxpdHkgaXMgbm90IHRoZQ0KICAgICAgICBvbmx5IGRv Y3VtZW50IHRoYXQgZGVwZW5kcyBvbiB0aGlzIGJhc2Ug4oCUIHNvIHdlIHdvdWxkIGJlIGRlbGF5 aW5nDQogICAgICAgIHRoYXQgcHVibGljYXRpb24gdG9vIChiZWNhdXNlIG9mIHRoZSBOb3JtYXRp dmUgcmVmZXJlbmNlKS4NCg0KICAgICgzKSBUaGlzIGRvY3VtZW50IGFscmVhZHkgY29udGFpbnMg YSByZWZlcmVuY2UgdG8gdGhlIElQdjYgZG9jdW1lbnQuIFRoYXQgd2lsbA0KICAgICAgICBiZSBt b3JlIGVmZmVjdGl2ZSB0aGFuIHJlcXVpcmluZyBhZGphY2VudCBSRkMgbnVtYmVycy4gSXQgaXMg bm90IGFsd2F5cw0KICAgICAgICB0aGUgY2FzZSB3aGVyZSBkb2N1bWVudHMgaW4gdGhlIHNhbWUg Y2x1c3RlciByZWNlaXZlIGFkamFjZW50IFJGQyBudW1iZXJzLg0KDQogICAgKDQpIFRoaXMgcmVx dWVzdCBpcyBub3QgYWxpZ25lZCB3aXRoIHRoZSBESVNDVVNTIENyaXRlcmlhIFsyXS4NCg0KDQog ICAgSGF2aW5nIHNhaWQgYWxsIHRoYXQsIEkgYW0gd2lsbGluZyB0byBwcmlvcml0aXplIG15IHJl dmlldyBvZiB0aGUgSVB2Ng0KICAgIGRvY3VtZW50ICh3aGVuIHRoZSBXRyByZXF1ZXN0cyBwdWJs aWNhdGlvbiksIGFuZCB3b3VsZCBub3Qgb3Bwb3NlIGENCiAgICByZXF1ZXN0IHRvIHRoZSBSRkMg RWRpdG9yIGZvciBleHBlZGl0ZWQgcHJvY2Vzc2luZyBpbiBvcmRlciB0byBnZXQgYW4NCiAgICBS RkMgbnVtYmVyIGFzc2lnbmVkIGJlZm9yZSByZmM1NTc1YmlzIGlzIHB1Ymxpc2hlZC4gIEkgdGhp bmsgdGhpcyBpcw0KICAgIHJlYXNvbmFibGUgY29uc2lkZXJpbmcgdGhlIHRpbWUgaXQgbWF5IHRh a2UgdGhlIGRvY3VtZW50IHRvIHJlYWNoDQogICAgQVVUSDQ4Lg0KDQoNCiAgICBUaGFua3MhDQoN CiAgICBBbHZhcm8uDQoNCg0KICAgIFsxXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9pZHIv d2lraS9kcmFmdC1pZXRmLWlkci1mbG93LXNwZWMtdjYlMjBpbXBsZW1lbnRhdGlvbnMNCg0KICAg IFsyXSBodHRwczovL3d3dy5pZXRmLm9yZy9hYm91dC9ncm91cHMvaWVzZy9zdGF0ZW1lbnRzL2ll c2ctZGlzY3Vzcy1jcml0ZXJpYS8NCg0KDQogICAgT24gQXByaWwgMjQsIDIwMjAgYXQgOTo1MDoy NCBBTSwgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcg0KICAgIChub3JlcGx5QGlldGYub3Jn KG1haWx0bzpub3JlcGx5QGlldGYub3JnKSkgd3JvdGU6DQoNCiAgICA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgICA+IERJU0NVU1M6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPg0KICAgID4gVGhhbmsg eW91IGZvciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50LiBUaGUgZG9jdW1lbnQgaXMg Y2xlYXIsIGVhc3kgdG8NCiAgICA+IHJlYWQgKEkgYXBwcmVjaWF0ZWQgdGhlIGdpdmVuIGV4YW1w bGVzKS4NCiAgICA+DQogICAgPiBBbGFzLCBkdWUgdG8gb3ZlcmxvYWQgb2Ygd29yaywgSSBoYWQg b25seSBhIHF1aWNrIGJyb3dzZSB0aHJvdWdoIHRoZSBkb2N1bWVudA0KICAgID4gd2l0aCBzcGVj aWZpYyBmb2N1cyBwb2ludHMgYW5kIGZvdW5kIG5vdGhpbmcgRVhDRVBUIHdoeSBoYXZpbmcgdHdv IGRpZmZlcmVudA0KICAgID4gZG9jdW1lbnRzID8gT25lIGZvciBJUHY0ICh3aXRoIHRoZSBjb3Jl IGVsZW1lbnRzIG9mIHRoZSBwcm90b2NvbCkgYW5kIG9uZSBmb3INCiAgICA+IElQdjYgKHdpdGgg b25seSB0aGUgSVB2NiBzcGVjaWZpY3MpLi4uIEkgYW0gbW9yZSB0aGFuIHN1cnByaXplZCB0byBz YXkgdGhlDQogICAgPiBsZWFzdC4uLiBoZW5jZSBteSBESVNDVVNTLi4uDQogICAgPg0KICAgID4g VGhpcyBibG9ja2luZyBESVNDVVNTIGNhbiBlYXNpbHkgYmUgZml4ZWQ6IGUuZy4sIHdpdGggYSBS RkMgRWRpdG9yIG5vdGUgdG8NCiAgICA+IG1ha2UgYSBjbHVzdGVyIG9mIHRoaXMgZG9jdW1lbnQg YW5kIGRyYWZ0LWlldGYtaWRyLWZsb3ctc3BlYy12NiBzbyB0aGF0IHRoZXkNCiAgICA+IGFyZSBw dWJsaXNoZWQgdG9nZXRoZXIgd2l0aCBhZGphY2VudCBSRkMgbnVtYmVycy4gTWVyZ2luZyB0aGUg dHdvIGRvY3VtZW50cw0KICAgID4gd291bGQgYmUgcHJlZmVycmVkIGJ1dCBJIHVuZGVyc3RhbmQg dGhhdCB0aGlzIGlzIG1vcmUgd29yayAoYWxiZWl0IGEgbWlzc2VkDQogICAgPiBvcHBvcnR1bml0 eSkuDQoNCg== From nobody Mon Apr 27 08:12:36 2020 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 BABE33A0C58; Mon, 27 Apr 2020 08:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 awdcXGfAhHTs; Mon, 27 Apr 2020 08:12:28 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 262503A053E; Mon, 27 Apr 2020 08:12:28 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id s10so21016443wrr.0; Mon, 27 Apr 2020 08:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=I+Wi4GFRRh7mdumes0pnJzJ1Jl53GidBNxm/0qCnTtA=; b=MH2PWtaJPKBzx0E5t5/neClNKmjzVNrVLtIG3UXGBZb+jBcJyw/IO1EPvTs6RpsUE9 3l976nAmb3vujTj2HF20SiS7+Rq6452aFSc6atJbl2W/OSwGCoQKEr8AvTKqiB+06Mfs oAy8GAfPMOTsAkifDRwot3ysgc9pWEVQT+JDIHfQgZN+eKXhyR0sEvErY5HjREIyY8l5 0PHH2K42FD+6KY3WMfigRkhVvvi/cOjwKZDXq0G2rBE9fgJ0PdKdXC1agwefY72Vlc/s FZRmRYvBj8ipqf1M9mJzrTeJgoP0G9NU2LjdiWNAcv8IFJ00ny1/W0p2hiAyV572vCsA kOBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=I+Wi4GFRRh7mdumes0pnJzJ1Jl53GidBNxm/0qCnTtA=; b=pW4cx6Zu+e40hWZHcZede1iOTdj8Pi/fw8ojyRs2BgrCdxCUjpGXnsHKKiLmQHnXLW ibcIHtu4XmdFPKJXUzQpIdcNYD1mrwKZKFPGUz+fu699NZLmop3dxCOdsCSXRpkF0P9+ +HM9DOmYMtAHMd2l9dynNfZHCNAvbQSguneZuYJO9C4Im7b3r7Uo/PXO1fzoEV/zbK4Y +vfaDpDMmRZzrggwVzdFu36fWyyC6BBVdk6ZpqLxWsROV5L1b5IF5dkmf4v1e/RBGQVI +xM3wKXivPziMNKGbzmhY3UdAOnWmva0GBe2DmA8Rj18ZEp2bMrjOmvnpl6JknZ6j+Cn GOfQ== X-Gm-Message-State: AGi0PuZMDnbD2kUHWnEKLB2cdz63Kz871UkfuiBVnSA/q0T597ozmh9B Tcm2hAChVqlDdtW1Y7pbW97ovEgX8ivTNVj6k72Ib4jF X-Google-Smtp-Source: APiQypLppsBReC/WTBh78b0oHSlws9dVD189SEi8mLjQBlCLMai2jKmC8CHJ3Js+9h2Y5cQVE8ortQ2CwwoWF9w4U18= X-Received: by 2002:a5d:610e:: with SMTP id v14mr27291758wrt.159.1588000346424; Mon, 27 Apr 2020 08:12:26 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 27 Apr 2020 15:12:25 +0000 From: Alvaro Retana In-Reply-To: References: <158773622329.9749.4475217266475729122@ietfa.amsl.com> MIME-Version: 1.0 Date: Mon, 27 Apr 2020 15:12:25 +0000 Message-ID: To: =?UTF-8?Q?=C3=89ric_Vyncke_via_Datatracker?= , "Eric Vyncke (evyncke)" , The IESG Cc: "idr-chairs@ietf.org" , Jie Dong , "draft-ietf-idr-rfc5575bis@ietf.org" , "idr@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-idr-r?= =?utf-8?q?fc5575bis-23=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 15:12:30 -0000 On April 27, 2020 at 10:11:21 AM, Eric Vyncke wrote: Eric: > Thank you for your detailed reply. About your point 1), Sue has indeed > updated the implementation wiki page and, if I understand correctly the I= DR > processes, this should allow the WGLC & publication of the IPv6 document. WGLC is already done, it concluded last week. =C2=A0In general, idr runs the WGLC and then waits for implementations. Right now the Shepherd is working on the write up, which should include finalizing the implementation report. > With this new element, do you (and the WG chairs) believe that making a > cluster is doable ? Else, I am trusting you as responsible AD and the cha= irs > to expedite the IPv6 document processing (including 'jumping the RFCE que= ue') > to have them published roughly at the same time. This is indeed very simi= lar > to a formal cluster. Because there's other work depending on rfc5575bis, I rather not hold up its publication beyond the normal process. =C2=A0I don't expect significant issues with draft-ietf-idr-flow-spec-v6, but I also prefer for them not to share their fate. As I mentioned, once the WG asks for publication, I'll prioritize its review. =C2=A0I can also ask the IESG to approve expedited processing once the IPv6 document is approved. Take care! Alvaro. From nobody Mon Apr 27 08:35:19 2020 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 1BFC43A0CBE for ; Mon, 27 Apr 2020 08:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=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 DJUYdfq_E3rQ for ; Mon, 27 Apr 2020 08:35:16 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 BFFB43A0CB8 for ; Mon, 27 Apr 2020 08:35:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Mon, 27 Apr 2020 11:35:11 -0400 Message-ID: <005201d61ca9$71152430$533f6c90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01D61C87.EA046E90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYcqS9OUz9dKgHYTcabF1VCt18RHQ== Content-Language: en-us X-Antivirus: AVG (VPS 200426-0, 04/26/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 15:35:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0053_01D61C87.EA046E90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The comment period on the adoption of draft-li-idr-sr-policy-path-mtu-03.txt has completed. The IDR WG has reached consensus to adopt this draft. The authors should submit this draft as draft-ietf-idr-sr-policy-path-mtu-00.txt. Cheerily, Susan Hares ------=_NextPart_000_0053_01D61C87.EA046E90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = comment period on the adoption of draft-li-idr-sr-policy-path-mtu-03.txt = has completed.

The IDR WG has reached = consensus to adopt this draft.

 

The authors = should submit this draft as draft-ietf-idr-sr-policy-path-mtu-00.txt. =

 

Cheerily, Susan Hares

 

 

------=_NextPart_000_0053_01D61C87.EA046E90-- From nobody Mon Apr 27 08:57:32 2020 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 164E53A0EF6; Mon, 27 Apr 2020 08:57:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong , aretana.ietf@gmail.com, jie.dong@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158800304005.9495.14847654857731736183@ietfa.amsl.com> Date: Mon, 27 Apr 2020 08:57:20 -0700 Archived-At: Subject: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?idr-rfc5575bis-23=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 15:57:27 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is clear, easy to read (I appreciated the given examples). After discussion with the responsible AD, Alvaro Retana, and the IDR WG chairs, I am clearing my DISCUSS (kept below for archival purpose) based on the promise that the IPv6 companion document will be 'expedite processed' by the WG chairs, document shepherd, and responsible AD + request for prompt processing by the RFC Editor. The final goal is to have this document and its IPv6 companion published roughly at the same time. (I still wonder why making two documents though ;-) ). Thanks to all for quickly updating the list of IPv6 implementations, that opened the gate for publication. -éric -- below is no more current as the DISCUSS is cleared -- Why having two different documents ? One for IPv4 (with the core elements of the protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than surprized to say the least... hence my DISCUSS... This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note to make a cluster of this document and draft-ietf-idr-flow-spec-v6 so that they are published together with adjacent RFC numbers. Merging the two documents would be preferred but I understand that this is more work (albeit a missed opportunity). Please find below a couple on non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éricI also second Erik K.'s comment on non-TCP/UDP ports. From nobody Mon Apr 27 11:43:36 2020 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 4A9F23A169F; Mon, 27 Apr 2020 11:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOzkZkV6yGAD; Mon, 27 Apr 2020 11:42:46 -0700 (PDT) Received: from mailhosting.spakka.net (mailhosting.spakka.net [IPv6:2a02:af8:cafe:f00d::25]) (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 125343A16A7; Mon, 27 Apr 2020 11:42:45 -0700 (PDT) Received: from [2a02:a210:2204:e270:6df5:8804:7c6f:dc6c] by mailhosting.spakka.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jT8iF-000368-KG; Mon, 27 Apr 2020 19:42:39 +0100 To: Nick Hilliard , "Sriram, Kotikalapudi (Fed)" Cc: "idr@ietf.org" , GROW WG , "Hannachi, Lilia (IntlAssoc)" , "draft-heitz-idr-wklc@ietf.org" References: From: Colin Petrie Message-ID: <60e115b3-607d-f3c6-8ced-8db5fafea39e@spakka.net> Date: Mon, 27 Apr 2020 20:42:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SMTP-Authenticated-User: colin@spakka.net Archived-At: Subject: Re: [Idr] [GROW] Measurements on Regular, Extended, and Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 18:42:57 -0000 If you are analysing Route-Views table dumps (and not updates) then you won't see ECs because Quagga/FRR only dumps selected attributes into the MRT files [0]. ECs are not on the list of dumped attributes. LCs were added to the list as part of the LC implementation patch. RIPE's RIS implementation records all the received attributes opaquely so you will see ECs in there. They are also present within the route-views updates files (as these are dumped raw by Quagga). Cheers, Colin [0]: bgp_dump_routes_attr(): https://github.com/FRRouting/frr/blob/master/bgpd/bgp_attr.c#L4146 On 24-04-2020 15:50, Nick Hilliard wrote: > Sriram, Kotikalapudi (Fed) wrote on 24/04/2020 14:14: >> ** Question: Any insights why we don't see any ECs at all? ** > > possibilities: > > - there are many types of EC and router config grammar is implemented > inconsistently across different platforms, and there's no guarantee that > the grammar is capable of expressing anything other than the commoner types > > - they can't handle asn32:asn32, so there's no compelling reason to > prefer them over rfc1997 communities. > > - the more common EC types already have specific meanings, e.g. RT/SOO/etc > > I've never seen them in the wild used for generic purposes.  It's always > rfc1997, or more recently LC. > > Nick > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From nobody Mon Apr 27 13:45:54 2020 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 50E873A099E; Mon, 27 Apr 2020 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=l+KO7geN; dkim=pass (1024-bit key) header.d=juniper.net header.b=bmCcnM0y 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 IyKsTA0XngBG; Mon, 27 Apr 2020 13:45:32 -0700 (PDT) Received: from mx0b-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 1AE053A08FE; Mon, 27 Apr 2020 13:45:21 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03RKgT9e024591; Mon, 27 Apr 2020 13:45:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=nh+zuIQz8ydtivS5MpGADYBzRK5MHfNM/lx0bVQf0jk=; b=l+KO7geNlxkYZo98M76LuvUVauynm3t7dZFAah9AjQlwfDQmEXGhoTiOTyVGj4gdgfG/ PXxdYAdNyhv1UVdm4AvL/iSzST49dta9E4ec51tPz5v4E32sCep/CM+1jyyMvOnwwpqU CsyquERHL8uGSFwnrEm1bUwanqrl6R2aNCm042lSKEiv9YvxinOesGZ7c8aPNQJ67mtH yRSl3ViCFdkOCXBPUgv0c+fKkA95x7BuszGEek6xfOwp6zsMlMvoYz6/YopAspa2ZB9/ 3QsOQRPwOCzav/1iB/hgmSGIU0sn60aII5EYek/Ptg6E/BOf0lLx1HWHe5rhW27zbJvw Qg== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2053.outbound.protection.outlook.com [104.47.36.53]) by mx0a-00273201.pphosted.com with ESMTP id 30mnnybmck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 13:45:20 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kq4GSgkz2wgGVWSOECMLE1RhyIH0/R0GuxedpIxhGcDxBIwssqLJTWzh1xOVtlh1VPEH3fPncByiq57p9MWAErLmlY0MsDJylqpZzip2yH3EjwOO5KZxp3RbMxSbii8jM9prv+eWCti8J60uAtplJy/cs3yeeZcOgylO2RjNdLq0DBnzqBw0dxctKXDQSjAOqTOfIldntU2TzwpjiiTq/1x5DeMWR6vQPYRaziOV1xdUhaWw/jK/ZbP13ETK7w7aUGam9D80I3pDMZo9z8Rrx94KVUx0RvibutN9L4O2wj6zvZPPg6RuvsnJ/wuf8/k3s8sk+Bg5fUrJ5sm1tByovw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nh+zuIQz8ydtivS5MpGADYBzRK5MHfNM/lx0bVQf0jk=; b=a5Bt1VsAM7A4GhyEkHdAbaidOLdzty6Vy7hDC3UyDB5ZkcZjXvD9H3FbKy5oMuI5RyOnncrJofTo52vN1JU2ka9ro157u4ZkNJU6a6D652l01X2XmdLr3RO6kcX1wXb8zadvVS9WiU5nMGuq6Uj6E//73dHioh+hV2fzoPquMZtFTbJNRn3gbMpx2WLs7XDA4CZvYrstyoG7uc+wjJR0HwvCvnkIyGwVYHxTOOajXNzT4Azd+6zoCRLBLjbUulL9RdRY4yf4xVJ9/NoQznv3zZ90pLkyYzqhuhvw9UxCPp0QbSnr028ZHJ+eE1R83CFaRuTXKW67WzKChFubc88mFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nh+zuIQz8ydtivS5MpGADYBzRK5MHfNM/lx0bVQf0jk=; b=bmCcnM0yHkn4MvS3nX2Hp5X1O3+VA/7WrsiqUR1CN/t+ea67AG421o0QQkYCqAJIRIhROhuiG1SnGNBfDXa8184mseZvy9dXsnK5ksWNYF7FMouf0kItz7KBD+TXNl8w+XdHBXHL2ohr0hYeyE2JKVGpeQxwJibBZqIors6W5p4= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB5252.namprd05.prod.outlook.com (2603:10b6:208:81::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.7; Mon, 27 Apr 2020 20:45:17 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 20:45:17 +0000 From: John Scudder To: Alvaro Retana CC: "draft-ietf-idr-tunnel-encaps@ietf.org" , idr-chairs , "idr@ietf. org" Thread-Topic: AD Review of draft-ietf-idr-tunnel-encaps-15 Thread-Index: AQHV6LURgETtNTA88kySyYPq0YikO6iN2BgA Date: Mon, 27 Apr 2020 20:45:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fc1487c7-bfcd-4a0e-1a63-08d7eaebe4d6 x-ms-traffictypediagnostic: BL0PR05MB5252: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(366004)(396003)(376002)(186003)(26005)(36756003)(86362001)(8936002)(71200400001)(6486002)(4744005)(2906002)(5660300002)(76116006)(54906003)(316002)(6512007)(6916009)(2616005)(66946007)(66446008)(33656002)(53546011)(6506007)(478600001)(8676002)(81156014)(4326008)(64756008)(66476007)(66556008); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7O4kjEkBSE/SP9dFCaOJqPjPYH96ubGyAWWcmAvwriCbgfktzIsyxCPGL3v65Ke3qMdQ16QNwWJTCchhC/slYKwRvLR3+DyRF9wAOpnqOs2MoIQ/J15M3uSr1ZPKVXKnE0Hc5yMF7p1cAP+DRDRcLLIAYnuI2pldCPblCuwf/iA8XkdHNZN+Yv0aV9Qnnti4seSo7p7KODn5ayfHditCpfnD9K2ZzeoKD9PJPGVnVP4zg5obF0uMUwnrHB6xkO/O2iQAXTY5PY5EKuXp6+qMIVsv82tx4FZQlQkrpgzInsUxHRbdknZOXzA9d/w/7iXHmnCgZV1Tgtj9lARRL9OS/Oglbfs2hya2tj1yN+Y0KanmDYuD+8hqSoKPYRbSvVi7AdXqYLOW28kRHyr72As+2eu8anWNLEP2fEfIBpzeFFIpr+46npPCPYnB/l7Qjf+H x-ms-exchange-antispam-messagedata: U0k9k1N7UBxuirqVCNUOPgCEjpdjdw3cnAtAmYwpGJW7U5oI9xQIOD915Zem0NZ6ILxfnHiWRpK5/XXAz/mQiWBdstukvf47jyppccL/c59PCiv21ElJnhxXTd5EPJUJgwAuWXZsQ0MwgKBDAY4eUTYaJSHTcCSZmbEJwanMcgw/cDOBmXGpR0gUAa9jsUSD55SX5BCbKZCOz3T0CFRg9e5tH75sfm2OLJBqhs3WFSvV9xSs0d1lf4nbI1Y+pPwVcU5IHG46Oii/1XtVMIeWYkMoJGyzU2hUXXCi/mcna6OIgyxgWpzde70MkKqv4H+S0zL9s9nPyPVTDrIpFy/trRGVgtDeLTIXcb2eeqrK6vAgViNNKDq9X9ZHp12Z9bBpXGEUCVYGGDRRFoIHyFsSSv0X3TKjayvse1/oKMoCLUVjR/tgg8/k5x2yp1SPZ66iS1gTTubCMuY0V74g2IiQs8DxK4RMoK+B8oYPFxkmbaRuQEUJBkRr+eNpG2Q1VnAuDQTKUxoHjM/U6fJAlJWvOYxg6bWEtNBmV4GaDzSMY0xiriXPiKLBGKmlJLk6YYkhuuigCU7kzG0ve1ApL2XUqp4d2N+VblCQMYsCb+rcxu+4djI/0LUT2bvxFLuU2tsrPErxEFv2w+Ey6toLm4kjKTIHGN17KelrJdqboQtVGSnSHMTSW7eW4z5F/BjLv2z2ol8nfix7nXP/WqDt3sK4wNe9qF2ZLSYeot33HHqPKI3Jhp//vtLRWWi7z/lPl60AkrRJbBgcpD8dmzsrdDXNZ0mYwOuMdb//G+QuLJU7qZg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D1B05CCF37004216A02F66483D7B6679junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: fc1487c7-bfcd-4a0e-1a63-08d7eaebe4d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 20:45:17.1546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jUOaopVESnruvqnjj7qxCM44pM1ZL9/Cld5uSOAxCm2AJlS+Vr9lKPcjs0eaTOWt X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5252 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_16:2020-04-27, 2020-04-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 mlxlogscore=772 lowpriorityscore=0 bulkscore=0 suspectscore=0 spamscore=0 malwarescore=0 impostorscore=0 phishscore=0 adultscore=0 clxscore=1011 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004270168 Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 20:45:52 -0000 --_000_D1B05CCF37004216A02F66483D7B6679junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBqdXN0IG5vdGljZWQgdGhpcywgdmVyeSBsYXRlOg0KDQpPbiBGZWIgMjEsIDIwMjAsIGF0IDc6 NDcgQU0sIEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmFyZXRh bmEuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KMjExICAgIEluIHRoaXMgZG9jdW1lbnQgd2Ug YWRkcmVzcyB0aGVzZSBkZWZpY2llbmNpZXMgYnk6DQoNCltzdHlsZSBuaXRdIFBsZWFzZSBkb24n dCB3cml0ZSBpbiBmaXJzdCBwZXJzb24uICBJbnN0ZWFkOiAiVGhpcw0KZG9jdW1lbnQgYWRkcmVz c2VzIHRoZXNlIGRlZmljaWVuY2llcyBieToiLiAgVGhlcmUgaXMgc2ltaWxhciB0ZXh0IGluDQpv dGhlciBwbGFjZXMuDQoNCkZXSVcgSSBkaXNhZ3JlZSB3aXRoIHRoaXMgY29tcGxldGVseSBhbmQg d2lsbCBnbGFkbHkgZmlnaHQgeW91IGFib3V0IGl0LCBuYW1lIHRoZSBwbGFjZSBhbmQgdGhlIHdl YXBvbi4NCg0KSSBqb2tlIGFib3V0IGZpZ2h0aW5nIG9mIGNvdXJzZSwgYnV0IG5vdCBhYm91dCBk aXNhZ3JlZWluZy4gTXkgdGhlc2lzIGFkdmlzb3IgdHJpZWQgdG8ga25vY2sgaXQgaW50byBteSBo ZWFkIHRoYXQgaXTigJlzIG5vdCBhY3R1YWxseSBhIHJlcXVpcmVtZW50IHRoYXQgYWNhZGVtaWMg d3JpdGluZyBiZSBib3JpbmcuIEkgdXN1YWxseSBmYWlsIGF0IHRoaXMgYnV0IEkgYXBwcmVjaWF0 ZSBpdCB3aGVuIHBlb3BsZSB0cnkhDQoNClRoYXQgc2FpZCwgaWYgdGhlIGF1dGhvcnMgd2FudCB0 byBtYWtlIHRoZSBjaGFuZ2UsIGl04oCZcyBmaW5lIG9mIGNvdXJzZS4g4oCcTm9ib2R5IGV2ZXIg Z290IGZpcmVkIGZvciBhdm9pZGluZyB0aGUgZmlyc3QgcGVyc29uLuKAnSAoT3Igd3JpdGluZyBp biB0aGUgcGFzc2l2ZSB2b2ljZSBmb3IgdGhhdCBtYXR0ZXIuKQ0KDQrigJRKb2huDQo= --_000_D1B05CCF37004216A02F66483D7B6679junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <0A075BF8FB629741806AD9A8C4AADEEA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkganVzdCBub3RpY2VkIHRoaXMsIHZlcnkgbGF0 ZTo8YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIgMjEsIDIwMjAsIGF0IDc6NDcgQU0s IEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29t IiBjbGFzcz0iIj5hcmV0YW5hLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4yMTE8 c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+DQo8 L3NwYW4+Jm5ic3A7Jm5ic3A7IEluIHRoaXMgZG9jdW1lbnQgd2UgYWRkcmVzcyB0aGVzZSBkZWZp Y2llbmNpZXMgYnk6PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPltzdHlsZQ0KIG5pdF0gUGxlYXNlIGRvbid0IHdyaXRlIGluIGZpcnN0IHBlcnNvbi4gJm5i c3A7SW5zdGVhZDogJnF1b3Q7VGhpczwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9 IiI+ZG9jdW1lbnQNCiBhZGRyZXNzZXMgdGhlc2UgZGVmaWNpZW5jaWVzIGJ5OiZxdW90Oy4gJm5i c3A7VGhlcmUgaXMgc2ltaWxhciB0ZXh0IGluPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5vdGhlcg0KIHBsYWNlcy48L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkZXSVcgSSBkaXNhZ3JlZSB3aXRoIHRoaXMgY29t cGxldGVseSBhbmQgd2lsbCBnbGFkbHkgZmlnaHQgeW91IGFib3V0IGl0LCBuYW1lIHRoZSBwbGFj ZSBhbmQgdGhlIHdlYXBvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkkgam9rZSBhYm91dCBmaWdodGluZyBvZiBjb3Vyc2UsIGJ1dCBu b3QgYWJvdXQgZGlzYWdyZWVpbmcuIE15IHRoZXNpcyBhZHZpc29yIHRyaWVkIHRvIGtub2NrIGl0 IGludG8gbXkgaGVhZCB0aGF0IGl04oCZcyBub3QgYWN0dWFsbHkgYSByZXF1aXJlbWVudCB0aGF0 IGFjYWRlbWljIHdyaXRpbmcgYmUgYm9yaW5nLiBJIHVzdWFsbHkgZmFpbCBhdCB0aGlzIGJ1dCBJ IGFwcHJlY2lhdGUgaXQgd2hlbiBwZW9wbGUgdHJ5ITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhdCBzYWlkLCBpZiB0aGUgYXV0aG9y cyB3YW50IHRvIG1ha2UgdGhlIGNoYW5nZSwgaXTigJlzIGZpbmUgb2YgY291cnNlLiDigJxOb2Jv ZHkgZXZlciBnb3QgZmlyZWQgZm9yIGF2b2lkaW5nIHRoZSBmaXJzdCBwZXJzb24u4oCdIChPciB3 cml0aW5nIGluIHRoZSBwYXNzaXZlIHZvaWNlIGZvciB0aGF0IG1hdHRlci4pPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJRKb2huPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D1B05CCF37004216A02F66483D7B6679junipernet_-- From nobody Mon Apr 27 14:09:28 2020 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 1CBDC3A0A0C; Mon, 27 Apr 2020 14:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 HcHoyFSt5y4p; Mon, 27 Apr 2020 14:09:23 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 E36923A0A11; Mon, 27 Apr 2020 14:09:22 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id j2so22236564wrs.9; Mon, 27 Apr 2020 14:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SHPLlnw2MFGuPvvCjSAhHT5bMWxIbUu6J/YEzv2iIu4=; b=bkB6F583ItVVwTV/E4/XG9NfD5xNJpU3utXwuSTuQyQOHrHtoQbxTxLkT+TDTxDsPV DV9l8Pea9LQIGXGH++zhP6NwSKsF+XotltojupcdUwFqALVv88f9PEYwBUcI2cpIAF3y 6xG6J3ohjF34CihOibgrn9wY83PWd4kavqx0q3VoEtz3ReZd9r/gXTkTCNNcekvfEFMp oWosGa0VHnpUiUP0HyTjG2aXLrksac79P5uC3vPzt483nSlROsJe57ROvYn6lT7JhbZh HKk79A5py+B8IAUeHgAS69Hi1QO7i1daKdwLBPLwVtzH+vmuNQK4qREaDN842gs9DgL2 yEcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SHPLlnw2MFGuPvvCjSAhHT5bMWxIbUu6J/YEzv2iIu4=; b=GaLMaLPVoBtVk7r9DlG4rQdStGv4/ciVfaFhkzzDr2NdLKUbF498nsdlUPTlcSVB2P ei0YP9jnee8Uykx31KMTkcFuetMb9LDHgVj1QIkpxJupJISWee4xpjwngkkYdqXvY/Th 7mt45XTVoKW5y5VRR1m/waw//O8Jr1ZNU/BW2GR97OW5zIhnLE0A6j9nA9exZRwua5W/ s2chbNnCKdS928WDYOGhq7ZAOQfhaDyZpFNJWO4NMLEsQz+XD1mdAp00qyrklTFev7LJ fNTeDVBHrxeiOQE5XN4V0Yk7JhxqKsp8j3EvRAOEYuHsnNYbe9wjGrmqF963dpR7B5n+ XbCw== X-Gm-Message-State: AGi0PuZgcS/x0PWTThmr+8xdLwJcuNpLqaRqRQcsU/QfpydXzn7SJ+UA F+ZopT0xHJaGZw8Jf0fINvL0IKIVVg7bfR2Tbek= X-Google-Smtp-Source: APiQypLhFvm05Va5yGN4EVMzFVTa8FmxOe1x/o8SQsgDHSRoVzTlKWcJXbBeDDa8nJYdNBrl1csvQVZXddoWWn4crW8= X-Received: by 2002:adf:94a6:: with SMTP id 35mr28726406wrr.420.1588021761271; Mon, 27 Apr 2020 14:09:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 27 Apr 2020 21:09:20 +0000 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 27 Apr 2020 21:09:20 +0000 Message-ID: To: John Scudder Cc: idr-chairs , "idr@ietf. org" , "draft-ietf-idr-tunnel-encaps@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f9ed1c05a44c2021" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 21:09:25 -0000 --000000000000f9ed1c05a44c2021 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! It=E2=80=99s just a style nit, so nothing I=E2=80=99m going to dig out my s= word for =E2=80=94 I=E2=80=99m assuming an old fashion duel, of course. ;-) Seriously, it=E2=80=99s just a nit. Personally, I don=E2=80=99t like first= person because it is usually associated with the point of view of the authors, and IETF documents should reflect the point of view of the WG=E2=80=A6 Alvaro. On April 27, 2020 at 4:45:20 PM, John Scudder (jgs@juniper.net) wrote: On Feb 21, 2020, at 7:47 AM , Alvaro Retana wrote: 211 In this document we address these deficiencies by: [style nit] Please don't write in first person. Instead: "This document addresses these deficiencies by:". There is similar text in other places. FWIW I disagree with this completely and will gladly fight you about it, name the place and the weapon. I joke about fighting of course, but not about disagreeing. My thesis advisor tried to knock it into my head that it=E2=80=99s not actually a req= uirement that academic writing be boring. I usually fail at this but I appreciate it when people try! That said, if the authors want to make the change, it=E2=80=99s fine of cou= rse. =E2=80=9CNobody ever got fired for avoiding the first person.=E2=80=9D (Or = writing in the passive voice for that matter.) --000000000000f9ed1c05a44c2021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!

It=E2=80=99s just a style nit, so nothing I=E2=80=99m going to = dig out my sword for =E2=80=94 I=E2=80=99m assuming an old fashion duel, of= course. ;-)


Seriously, it= =E2=80=99s just a nit.=C2=A0 Personally, I don=E2=80=99t like first person = because it is usually associated with the point of view of the authors, and= IETF documents should reflect the point of view of the WG=E2=80=A6

Alvaro.

On April 27, 2020 at 4:45:20 PM, John Scudder (jgs@juniper.net) wrote:

On Feb 21, 2020, at 7:47 AM, Alvar= o Retana <aretana.ietf@gmail.com> wrote:

211=C2=A0=C2=A0 In this docu= ment we address these deficiencies by:

[style nit] Please don't w= rite in first person.=C2=A0 Instead: "This
document addresses= these deficiencies by:".=C2=A0 There is similar text in
other= places.

<= div class=3D"" style=3D"color:rgb(0,0,0);font-family:'helvetica Neue= 9;,helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font= -weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-= transform:none;white-space:normal;word-spacing:0px">FWIW I disagree with th= is completely and will gladly fight you about it, name the place and the we= apon.

I joke abo= ut fighting of course, but not about disagreeing. My thesis advisor tried t= o knock it into my head that it=E2=80=99s not actually a requirement that a= cademic writing be boring. I usually fail at this but I appreciate it when = people try!

That s= aid, if the authors want to make the change, it=E2=80=99s fine of course. = =E2=80=9CNobody ever got fired for avoiding the first person.=E2=80=9D (Or = writing in the passive voice for that matter.)

=
--000000000000f9ed1c05a44c2021-- From nobody Mon Apr 27 14:21:11 2020 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 61D133A0B0F; Mon, 27 Apr 2020 14:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=eAcJJL/k; dkim=pass (1024-bit key) header.d=juniper.net header.b=Qd8ekZsZ 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 BncHRxStLQTl; Mon, 27 Apr 2020 14:21:06 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A5C3A0B0D; Mon, 27 Apr 2020 14:21:05 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03RLHE9X020589; Mon, 27 Apr 2020 14:21:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=OURbkGuojKClvbarNfOupZW5GeEs5Z9ARwTuXMsNJGI=; b=eAcJJL/k5UjADI37jFSFnruP3PlPNkGZN5qpe/1jDCAQ7+jfHL3lwGSfJ5JQo+c2jwsD YC/s+doUlct7ICkfIVT8GdEK8SmFfVu+zbI5nkrwoCcKlOZ625MCRblQ900s3SXZPHCY 33nE0x0yZrkDkd6xBVKsICmwJk9/fRH4GjeJKuCqmtHHq/uCnnbaGQYFkggPy5i0glDR b/bPhY5J4ffr9AKauT1hugF43G3Psnc2xYJr6ypYshjJCQlU/1hn8DHZq4xiBBEMZCv3 p/fC3AD9ueAjMOTy6YBRZOpMUfk9cUBWHPAno7HwEH4C8vuPISWeBaOA2Giu5jZjDc03 vw== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169]) by mx0b-00273201.pphosted.com with ESMTP id 30mhtuuw9u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 14:21:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z4jbJdXIfbNHaR8nZfZ3ULuDX/KhDoku6uu5uV6InfGY3c+PQKhIJQFETFj1njHjf3ifO+Nbq6/J1+hQZaKCCXCnWr5Sd/O4aFvPPxPo6kZ6qYOJmiHJ7ClXjGmR4LP6HWj8jg0DjS1rfz2n++2YyfnCAsFD5WrDo8kikgWAajxETnC9luKsK8Dm1QlI1/FR+kzV4bMfQf4ugNA98lGmwXkwUGGXlVSsZ0L/bBNNzXmMIJcp/kAaLGXW0j8Ky3Ugo/Wwo8F9rM3H3BFYzkn7TgkaRBtK8DuEzG/0RlFuT1kZ8Tdv6JEzuOsl50Y93kJ++HgeaJtIfFlMghj2GCX22g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OURbkGuojKClvbarNfOupZW5GeEs5Z9ARwTuXMsNJGI=; b=cQs7SV7Eh/k2qbK06OgbcVMEB8fFRsUWsPd/UPnpeSNk/yxpcLBiTpbaI8GpHSuqKQjYWScOPnmAr9QHmgP/h+iSjkCvI2RcdoKL+LWHiRC+XxOi1nUJclwXeoI5HovAMFr5HpWgGLpzusQZxbZZ8nLiSxySbxNWid3VTF94U/QqWa+34yA19d2cS/LdctOZ81Kg8FobaRRBpubUF+Y+lokLNE2vra4j562magCZ9F6qlWFvEa+2JTuAqGE+oqi8KcH7mJHnXS/ookRTlRxdKatteCdvVj7YOpY3Q8XjsfNY6KbJBItgMp8ycScTxR5jwWSQz8JK0PkOFP/6fTMSmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OURbkGuojKClvbarNfOupZW5GeEs5Z9ARwTuXMsNJGI=; b=Qd8ekZsZb0wgFNYtT9QI5bYUCVpNlE8QalW58nxwcjNfkVgFcA/QFcLCXtvjpkMBr1QD4H84g7yoA6pF85VZF2wzFUGW5pnDbRwOx2179LLZMzTg7BJUjJPtXLxgkcUtEvcAHZ1TfPP+IPXB7+WNSTcG7hGub3u0qiQQ/Qz4R/E= Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB4737.namprd05.prod.outlook.com (2603:10b6:208:56::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Mon, 27 Apr 2020 21:21:03 +0000 Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 21:21:02 +0000 From: John Scudder To: Alvaro Retana CC: "draft-ietf-idr-tunnel-encaps@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf. org" Thread-Topic: AD Review of draft-ietf-idr-tunnel-encaps-15 Thread-Index: AQHV6LURgETtNTA88kySyYPq0YikO6iN4haA Date: Mon, 27 Apr 2020 21:21:02 +0000 Message-ID: <10C39490-C9C0-4B67-8942-EAFDB0BFC35F@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e1fe219e-923c-4c05-5e06-08d7eaf0e3b5 x-ms-traffictypediagnostic: BL0PR05MB4737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(346002)(39860400002)(366004)(396003)(64756008)(6916009)(2616005)(66946007)(4326008)(8676002)(66556008)(66476007)(81156014)(33656002)(91956017)(6506007)(186003)(76116006)(26005)(5660300002)(6512007)(66446008)(53546011)(478600001)(2906002)(36756003)(71200400001)(6486002)(316002)(8936002)(86362001)(54906003); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mQ0VyNhlFdnn1JFYX5xXNETmy6MMRhthrWTmMBW1TofE/kXRhCRipY6Qm4nCiYPiqxEqv5ofZTQJOJ11jP8eiluYXTCVw57uiSvr8GBnpLcX/s/66pmEa3cl4aOPvS4Y1fQXLXRm4Alr6iJKTpVtfM+SkHL1zBqHp0HNJZ8RJeCNgHdzPk3C/dFFAgj7KIPhrPF6N6UZBvbvi/RJ1p+bpM/L3HtJKsPHoqW5dA0Hs3kDrtkdTjrVfdXkxynFCMX2iwqD95dxQ8pf25o6JB0BPdmBKeiWU0tdFQEXuCQsnWg6TRbuNOM+rjAG4Cg59fAhloox9TU1vUkSpB8fhx/sGidyffg6QdcETj8pkLkCpJmqW+W4Nv8R4K39rtzDPpHE4BA2/C0SqM3FW59VeMnKr8NzwxcoTOt6Qw14qe5yHs1J9S2Muz7ZxEs+lc+oZ/il x-ms-exchange-antispam-messagedata: mhHIFs2Ed5JE8eb7KIxGC7QiiRnGGq5deK7tCJVXX2yPDDVKvCwTI6Qukng95E06UYpt3Snja6TmuMRev5XpMiH7NPI8hc4yB9o9zNRlhHFBv/FxJIY5ZPUmppuEORWTBMrOkBIc0OzXkczyKtP0BFoNEJrN4UPyCd2o1541HejLzuRZKmWwJZyR91IX/VL/X9sH27ak9p7TQpz8DiGFyZZapzTTEUt28mTaasgzzd3r8DUGfxcH8rtzHlh8NGn9izSUQIhiyOqMe7M27egPpz6D1VOjLVOu046o7aN07J4/KoaM1VpLG0MzF632cv0Tkx1zvQUkfwOqNjlYxh9mEOiixmYn7gjlqJkePPo3le6oA0YV9UTwp3Y2OJyjSIrhdEmu0hdMZjH//b8q51Gqkgu7Lwp8gILkWZhU8LwDFnv/qPLBXpT1Zqmwks5y7h1bFkUvzd8B9qQkQnq7fOBlQXgO9mIlVKK3xt2GPN47BBjksa4Kn6mJBc/oQ0i6u5rAfTzoT4zZKlneljGnXhlIo3B0zs03QtyLOB28ojlBB4/xMMWVkVjW4u+hP5AA94+fKNkQrCkclUGknzt4vO9+vwutBMfqqQmLXjWbrwAXvV7LToOjxs3Ckcxh+qGshZH8XrOuRUtuv/LKCaKjAydYnb2Qz32/WFpVgpsLB4z4+ZCPn3R6s1ks+HVNTVlTmOkjxU2HlZHVPOnAMkYTCZH/mNYsVbUP0OSnKqEXrzTW3ixVzcPoHHKRgxAe0iWEvUZ96TiarqRDZqvb8Xub23Fv1cah7U5u6clwWbYWegmpzEU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_10C39490C9C04B678942EAFDB0BFC35Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: e1fe219e-923c-4c05-5e06-08d7eaf0e3b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 21:21:02.7740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a2uRn0wZrGgv/jTRHjIL6qJZOGK6lWo3/jBfXkuDhGnDR3ZC1SIEE73RPg2Mx43g X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4737 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_16:2020-04-27, 2020-04-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 lowpriorityscore=0 suspectscore=0 adultscore=0 spamscore=0 impostorscore=0 clxscore=1015 mlxscore=0 malwarescore=0 priorityscore=1501 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004270174 Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 21:21:10 -0000 --_000_10C39490C9C04B678942EAFDB0BFC35Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpSZWdhcmRpbmcgb2Jzb2xldGluZyBvdGhlciB3b3JrLCBpdCBtYWtlcyBz ZW5zZSB0byBtZSB0aGF0IHdvcmsgdGhhdCBiZWNvbWVzIGRlLWZhY3RvIG9ic29sZXRlIGFzIGEg cmVzdWx0IG9mIDU1MTIgYmVpbmcgb2Jzb2xldGVkLCBzaG91bGQgYWxzbyBiZSBvYnNvbGV0ZWQu IEp1c3Qgc2VlbXMgbGlrZSBnb29kIGRvY3VtZW50IGh5Z2llbmUuDQoNCkkgYXNzdW1lIHRoYXQg ZG9lcyBOT1QgaW1wbHkgdGhhdCB0aGlzIGRvY3VtZW50IHdvdWxkIG5lZWQgdG8gcHJvdmlkZSBy ZXBsYWNlbWVudHMgZm9yIHRoZSBvYnNvbGV0ZWQgc3BlY2lmaWNhdGlvbnMuIEFzIHlvdSBzYXkg YmVsb3csIHRoYXTigJlzIGEgZGlmZmVyZW50IHRyYWNrIG9mIHdvcmsgYW5kIGNhbiBiZSBwdXJz dWVkIGluZGVwZW5kZW50bHkuIFdl4oCZcmUganVzdCB0YWxraW5nIGFib3V0IGFkZGluZyB0d28g bW9yZSBkb2N1bWVudCBudW1iZXJzIHRvIHRoZSBPYnNvbGV0ZXMgaGVhZGVyLCByaWdodD8NCg0K VGhhbmtzLA0KDQrigJRKb2huDQoNCk9uIEZlYiAyMSwgMjAyMCwgYXQgNzo0NyBBTSwgQWx2YXJv IFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86YXJldGFuYS5pZXRmQGdtYWls LmNvbT4+IHdyb3RlOg0KDQooMSkgT2Jzb2xldGluZyBvdGhlciB3b3JrDQoNClRoaXMgZG9jdW1l bnQgZGVwcmVjYXRlcyB0aGUgRW5jYXBzdWxhdGlvbiBTQUZJIGJlY2F1c2UgaXQgImhhcyBuZXZl cg0KYmVlbiB1c2VkIGluIHByb2R1Y3Rpb24iLiAgV2hhdCBhYm91dCBvdGhlciB3b3JrIHRoYXQg c3BlY2lmaWVzIHRoZQ0KdXNlIG9mIHRoZSBFbmNhcHN1bGF0aW9uIFNBRkk/ICBTaG91bGQgdGhl eSBhbHNvIGJlIE9ic29sZXRlZCBieSB0aGlzDQpkb2N1bWVudD8gIFtZZXMsIEkga25vdyB0aGVy ZSB3YXMgYSBsb25nIGRpc2N1c3Npb24gb24gdGhlIGxpc3QsIHdoaWNoDQpyZXN1bHRlZCBpbiB0 aGUgdGV4dCBpbiDCpzEuNC5dDQoNCkJvdGggcmZjNTU2NiAobWVudGlvbmVkIGluIMKnMS40KSBh bmQgcmZjNTY0MCBzcGVjaWZ5IHRoZSB1c2Ugb2YgdGhlDQpFbmNhcHN1bGF0aW9uIFNBRkkuICBJ cyB0aGVyZSBpbnRlcmVzdCBpbiBVcGRhdGluZyB0aG9zZSBSRkNzPyAgSWYNCm5vdCwgdGhlbiBp dCBzZWVtcyBsaWtlIHRoZSBlYXN5IHRoaW5nIHRvIGRvIGlzIHRvIE9ic29sZXRlIHRoYXQgd29y aw0Kd2l0aCB0aGlzIGRvY3VtZW50LiAgSWYgdGhlcmUgaXMsIHRoZW4gSSBhZ3JlZSB3aXRoIHRo ZSB0ZXh0IGluIMKnMS40DQppbiB0aGF0IHRoZSBlZmZvcnQgd291bGQgYmUgb3V0IG9mIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuICBJbiBlaXRoZXINCmNhc2UsIEkgdGhpbmsgdGhhdCDCpzEuNCBy YWlzZXMgbW9yZSBxdWVzdGlvbnMgdGhhbiBpdCBhbnN3ZXJzIGFuZCBpcw0Kbm90IG5lZWRlZCBp biB0aGlzIGRvY3VtZW50Lg0KDQpKb2huOiBBcyBTaGVwaGVyZCwgY2FuIHlvdSBwbGVhc2UgcGlu ZyB0aGUgV0cgKHlvdSBtYXkgaGF2ZSB0byByZWFjaA0Kb3V0IHRvIGJlc3MgYXMgd2VsbCkgYWJv dXQgcG90ZW50aWFsIGludGVyZXN0IGluIFVwZGF0aW5nDQpyZmM1NTY2L3JmYzU2NDAuICBJIHdv bid0IGhvbGQgdGhpcyBkb2N1bWVudCB3YWl0aW5nIGZvciB0aGUNCnJlc29sdXRpb24sIGJ1dCBo YXZpbmcgYW4gaWRlYSBvZiBhbnkgaW50ZXJlc3Qgd291bGQgYmUgbmljZS4NCkludGVyZXN0IGhh cyBiZWVuIGV4cHJlc3NlZCBmb3IgcmZjNTU2NmJpcyBbMV0sIGJ1dCBkaWRuJ3Qgc2VlDQphbnl0 aGluZyByZWxhdGVkIHRvIHJmYzU2NDAuICBCVFcsIHRoZSBtYWlsaW5nIGxpc3QgY29udGFpbnMN CmRpc2N1c3Npb24gYWJvdXQgb3RoZXIgSVBzZWMtcmVsYXRlZCBkcmFmdHMgdGhhdCB1c2UgdHVu bmVsLWVuY2FwOyBJJ20NCm5vdCBzdXJlIG9mIHRoZWlyIHJlbGF0aW9uc2hpcCAoaWYgYW55KSB0 byByZmM1NTY2Lg0KDQo= --_000_10C39490C9C04B678942EAFDB0BFC35Fjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <7FA171408A9A8F4A992E5F13C0F24973@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIEFsdmFybywNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZGluZyBvYnNvbGV0aW5nIG90 aGVyIHdvcmssIGl0IG1ha2VzIHNlbnNlIHRvIG1lIHRoYXQgd29yayB0aGF0IGJlY29tZXMgZGUt ZmFjdG8gb2Jzb2xldGUgYXMgYSByZXN1bHQgb2YgNTUxMiBiZWluZyBvYnNvbGV0ZWQsIHNob3Vs ZCBhbHNvIGJlIG9ic29sZXRlZC4gSnVzdCBzZWVtcyBsaWtlIGdvb2QgZG9jdW1lbnQgaHlnaWVu ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkkgYXNzdW1lIHRoYXQgZG9lcyBOT1QgaW1wbHkgdGhhdCB0aGlzIGRvY3VtZW50IHdvdWxk IG5lZWQgdG8gcHJvdmlkZSByZXBsYWNlbWVudHMgZm9yIHRoZSBvYnNvbGV0ZWQgc3BlY2lmaWNh dGlvbnMuIEFzIHlvdSBzYXkgYmVsb3csIHRoYXTigJlzIGEgZGlmZmVyZW50IHRyYWNrIG9mIHdv cmsgYW5kIGNhbiBiZSBwdXJzdWVkIGluZGVwZW5kZW50bHkuIFdl4oCZcmUganVzdCB0YWxraW5n IGFib3V0IGFkZGluZyB0d28gbW9yZQ0KIGRvY3VtZW50IG51bWJlcnMgdG8gdGhlIE9ic29sZXRl cyBoZWFkZXIsIHJpZ2h0PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUSm9objxiciBjbGFzcz0iIj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk9uIEZlYiAyMSwgMjAyMCwgYXQgNzo0NyBBTSwgQWx2YXJvIFJldGFuYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFyZXRhbmEuaWV0ZkBnbWFpbC5jb20iIGNsYXNzPSIiPmFyZXRhbmEuaWV0ZkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPigxKQ0KIE9ic29sZXRpbmcgb3RoZXIgd29yazwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPlRoaXMNCiBkb2N1bWVudCBkZXByZWNhdGVzIHRoZSBFbmNhcHN1bGF0aW9uIFNB RkkgYmVjYXVzZSBpdCAmcXVvdDtoYXMgbmV2ZXI8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPmJlZW4NCiB1c2VkIGluIHByb2R1Y3Rpb24mcXVvdDsuICZuYnNwO1doYXQgYWJv dXQgb3RoZXIgd29yayB0aGF0IHNwZWNpZmllcyB0aGU8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPnVzZQ0KIG9mIHRoZSBFbmNhcHN1bGF0aW9uIFNBRkk/ICZuYnNwO1Nob3Vs ZCB0aGV5IGFsc28gYmUgT2Jzb2xldGVkIGJ5IHRoaXM8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPmRvY3VtZW50Pw0KICZuYnNwO1tZZXMsIEkga25vdyB0aGVyZSB3YXMgYSBs b25nIGRpc2N1c3Npb24gb24gdGhlIGxpc3QsIHdoaWNoPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx NHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5yZXN1bHRlZA0KIGluIHRoZSB0ZXh0IGluIMKnMS40Ll08L3NwYW4+PGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Cb3RoDQogcmZjNTU2NiAobWVudGlvbmVkIGluIMKnMS40 KSBhbmQgcmZjNTY0MCBzcGVjaWZ5IHRoZSB1c2Ugb2YgdGhlPC9zcGFuPjxiciBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx NHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj5FbmNhcHN1bGF0aW9uDQogU0FGSS4gJm5ic3A7SXMgdGhlcmUgaW50 ZXJlc3QgaW4gVXBkYXRpbmcgdGhvc2UgUkZDcz8gJm5ic3A7SWY8L3NwYW4+PGJyIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPm5vdCwNCiB0aGVuIGl0IHNlZW1zIGxpa2UgdGhlIGVhc3kgdGhp bmcgdG8gZG8gaXMgdG8gT2Jzb2xldGUgdGhhdCB3b3JrPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx NHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj53aXRoDQogdGhpcyBkb2N1bWVudC4gJm5ic3A7SWYgdGhlcmUgaXMsIHRo ZW4gSSBhZ3JlZSB3aXRoIHRoZSB0ZXh0IGluIMKnMS40PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx NHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5pbg0KIHRoYXQgdGhlIGVmZm9ydCB3b3VsZCBiZSBvdXQgb2Ygc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4gJm5ic3A7SW4gZWl0aGVyPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx NHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5jYXNlLA0KIEkgdGhpbmsgdGhhdCDCpzEuNCByYWlzZXMgbW9yZSBxdWVz dGlvbnMgdGhhbiBpdCBhbnN3ZXJzIGFuZCBpczwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+bm90DQogbmVlZGVkIGluIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxiciBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+Sm9objoNCiBBcyBTaGVwaGVyZCwgY2FuIHlvdSBwbGVhc2UgcGluZyB0 aGUgV0cgKHlvdSBtYXkgaGF2ZSB0byByZWFjaDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+b3V0DQogdG8gYmVzcyBhcyB3ZWxsKSBhYm91dCBwb3RlbnRpYWwgaW50ZXJlc3Qg aW4gVXBkYXRpbmc8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnJmYzU1NjYv cmZjNTY0MC4NCiAmbmJzcDtJIHdvbid0IGhvbGQgdGhpcyBkb2N1bWVudCB3YWl0aW5nIGZvciB0 aGU8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnJlc29sdXRpb24sDQogYnV0 IGhhdmluZyBhbiBpZGVhIG9mIGFueSBpbnRlcmVzdCB3b3VsZCBiZSBuaWNlLjwvc3Bhbj48YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SW50ZXJlc3QNCiBoYXMgYmVlbiBleHByZXNzZWQg Zm9yIHJmYzU1NjZiaXMgWzFdLCBidXQgZGlkbid0IHNlZTwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+YW55dGhpbmcNCiByZWxhdGVkIHRvIHJmYzU2NDAuICZuYnNwO0JUVywg dGhlIG1haWxpbmcgbGlzdCBjb250YWluczwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+ZGlzY3Vzc2lvbg0KIGFib3V0IG90aGVyIElQc2VjLXJlbGF0ZWQgZHJhZnRzIHRoYXQg dXNlIHR1bm5lbC1lbmNhcDsgSSdtPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij5ub3QNCiBzdXJlIG9mIHRoZWlyIHJlbGF0aW9uc2hpcCAoaWYgYW55KSB0byByZmM1NTY2Ljwv c3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_10C39490C9C04B678942EAFDB0BFC35Fjunipernet_-- From nobody Mon Apr 27 14:38:42 2020 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 E1C1B3A0B75; Mon, 27 Apr 2020 14:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 TYLf_2R__ROR; Mon, 27 Apr 2020 14:38:38 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 2AA923A0B73; Mon, 27 Apr 2020 14:38:38 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id r26so603187wmh.0; Mon, 27 Apr 2020 14:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=wJXlfZQf8hNiHy3yDLkuUo0GA9zKitO87IIQkR0/iI4=; b=hCEXpcd4fRGZQaWeKgq/MYetDrUls24Pvxns7C76Z0YayxUMs7rHY8WYTl3+x5BojL 1W3OO1xX+aDmIKnko4+hY004EBBmdbTHp1yxUXqJDQPsfZJS24cpoSZb9eAy4B1tFxww +u5lwEIOacNoNWguHbtjCgvtVvS+AISuAaNRiagjEddXCOIr3YOuaXys6XC8nh+R61nz UtpTKo1lJ6oedmycDicgiafIId2h/t+T/0RJdEsXZk5O1Az+IUa/LbosMW+isZFkSIbo 4ZcafvIEQROrdWcMuPEOscISD8arGmii43GJ3LI1e2izpOrbKusQMMW91opaWjShg5Vt hWIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=wJXlfZQf8hNiHy3yDLkuUo0GA9zKitO87IIQkR0/iI4=; b=gL7oDBuRBgbbZqNHgFv0AZYZMLBOgKfaqAXb3sRGIrkquir+q400VajEZsg3Dr3Ui4 kr53E+fTJgPUihdoLn1OLfVfFWj94xOG59dLZ83ZhXOihuXzaUuLssM52f+Qpi4Rfj+l wkDPrqyR9XJxV8+vTd/LWAl63WHo8UmpDjrxRQMbg0Amah0YXLLls7OQYy9fpHZfNG5M xQtFmzrvO82BtJAzU5QJenbFtIjsg4nUsFq7PvBaeKSqVLxNQiJY8b9mFoI6/daUOY41 QfxoHUEAJyALaAjwz72tdv+B8+rdco0pMU40W3QeoHo6erDZSVwTU4fTxBEmZtiCCL3J MV8w== X-Gm-Message-State: AGi0PuYLgW8ZtZQuxszVDHLoB4fL8sMFbWPbijSJxOsEKnsnOx3G/QsI xcZvYAYNvBIMHlbadjElCxTPk2Ix/yfg/8kMYqY= X-Google-Smtp-Source: APiQypKSrOewWNWUzGXfsM5H6Km0C49SqdPgmIggbLudnuvxnLOKO57HmorSk1Hi2VWEYBD49/64MnmmgB6PoNScORU= X-Received: by 2002:a05:600c:28e:: with SMTP id 14mr818873wmk.79.1588023516540; Mon, 27 Apr 2020 14:38:36 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 27 Apr 2020 21:38:35 +0000 From: Alvaro Retana In-Reply-To: <10C39490-C9C0-4B67-8942-EAFDB0BFC35F@juniper.net> References: <10C39490-C9C0-4B67-8942-EAFDB0BFC35F@juniper.net> MIME-Version: 1.0 Date: Mon, 27 Apr 2020 21:38:35 +0000 Message-ID: To: John Scudder Cc: "idr-chairs@ietf.org" , "idr@ietf. org" , "draft-ietf-idr-tunnel-encaps@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 21:38:40 -0000 On April 27, 2020 at 5:21:04 PM, John Scudder wrote: John: Hi! > Regarding obsoleting other work, it makes sense to me that work that beco= mes > de-facto obsolete as a result of 5512 being obsoleted, should also be > obsoleted. Just seems like good document hygiene. > > I assume that does NOT imply that this document would need to provide > replacements for the obsoleted specifications. As you say below, that=E2= =80=99s a > different track of work and can be pursued independently. We=E2=80=99re j= ust talking > about adding two more document numbers to the Obsoletes header, right? Yes, correct -- and a sentence to the Abstract/Introduction. I think that the decision to add those documents, or not, depends on whether the effort to Update them (if there is interest) starts soon or not (soon =3D by the time this document gets to IESG Evaluation). =C2=A0= As it stands now (I haven't found rfc5566bis or rfc5640bis), and unless there's explicit interest in starting work soon on *bis, it seem like Obsoleting is the right answer. Alvaro. > > On Feb 21, 2020, at 7:47 AM, Alvaro Retana wrote: > > (1) Obsoleting other work > > > > This document deprecates the Encapsulation SAFI because it "has never > > been used in production". What about other work that specifies the > > use of the Encapsulation SAFI? Should they also be Obsoleted by this > > document? [Yes, I know there was a long discussion on the list, which > > resulted in the text in =C2=A71.4.] > > > > Both rfc5566 (mentioned in =C2=A71.4) and rfc5640 specify the use of th= e > > Encapsulation SAFI. Is there interest in Updating those RFCs? If > > not, then it seems like the easy thing to do is to Obsolete that work > > with this document. If there is, then I agree with the text in =C2=A71.= 4 > > in that the effort would be out of scope of this document. In either > > case, I think that =C2=A71.4 raises more questions than it answers and = is > > not needed in this document. > > > > John: As Shepherd, can you please ping the WG (you may have to reach > > out to bess as well) about potential interest in Updating > > rfc5566/rfc5640. I won't hold this document waiting for the > > resolution, but having an idea of any interest would be nice. > > Interest has been expressed for rfc5566bis [1], but didn't see > > anything related to rfc5640. BTW, the mailing list contains > > discussion about other IPsec-related drafts that use tunnel-encap; I'm > > not sure of their relationship (if any) to rfc5566. > From nobody Tue Apr 28 01:56:25 2020 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 E5E703A111F; Tue, 28 Apr 2020 01:56:17 -0700 (PDT) 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.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158806417787.2032.14039500184708646151@ietfa.amsl.com> Date: Tue, 28 Apr 2020 01:56:17 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-sr-policy-path-mtu-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:56:18 -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 : Segment Routing Path MTU in BGP Authors : Cheng Li YongQing Zhu Ahmed El Sawaf Zhenbin Li Filename : draft-ietf-idr-sr-policy-path-mtu-00.txt Pages : 8 Date : 2020-04-28 Abstract: Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. This document defines extensions to BGP to distribute path MTU information within SR policies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-path-mtu/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-mtu-00 https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-mtu-00 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 Tue Apr 28 03:23:15 2020 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 324673A129E; Tue, 28 Apr 2020 03:23:13 -0700 (PDT) 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.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158806939315.22591.12582074410361748260@ietfa.amsl.com> Date: Tue, 28 Apr 2020 03:23:13 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-sr-policy-path-mtu-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 10:23:13 -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 : Segment Routing Path MTU in BGP Authors : Cheng Li YongQing Zhu Ahmed El Sawaf Zhenbin Li Filename : draft-ietf-idr-sr-policy-path-mtu-01.txt Pages : 9 Date : 2020-04-28 Abstract: Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. This document defines extensions to BGP to distribute path MTU information within SR policies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-path-mtu/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-mtu-01 https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-mtu-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sr-policy-path-mtu-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 Tue Apr 28 03:27:33 2020 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 BC88C3A12A9 for ; Tue, 28 Apr 2020 03:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxaLh4chhEJJ for ; Tue, 28 Apr 2020 03:27:30 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6903A12A8 for ; Tue, 28 Apr 2020 03:27:29 -0700 (PDT) Received: from lhreml701-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 188DC6B75D554E3DF255 for ; Tue, 28 Apr 2020 11:27:28 +0100 (IST) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 28 Apr 2020 11:27:27 +0100 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Tue, 28 Apr 2020 11:27:27 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.203]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Tue, 28 Apr 2020 18:27:20 +0800 From: "Chengli (Cheng Li)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 Thread-Index: AdYcqS9OUz9dKgHYTcabF1VCt18RHQAne0KQ Date: Tue, 28 Apr 2020 10:27:20 +0000 Message-ID: References: <005201d61ca9$71152430$533f6c90$@ndzh.com> In-Reply-To: <005201d61ca9$71152430$533f6c90$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029F84D1dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 10:27:32 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB029F84D1dggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Susan, Thank you for your notification. Already uploaded the text. Also, we updated the error handling rules to align with the rules defined i= n draft-ietf-idr-segment-routing-te-policy. Also, added text of Implementat= ion status. Will address the comments from Ketan and Aijun and Linda ASAP. Many thanks! Best Regards, Cheng A new version of I-D, draft-ietf-idr-sr-policy-path-mtu-01.txt has been successfully submitted by Cheng Li and posted to the IETF reposito= ry. Name: draft-ietf-idr-sr-policy-path-mtu Revision: 01 Title: Segment Routing Path MTU in BGP Document date: 2020-04-28 Group: idr Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-sr-poli= cy-path-mtu-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-p= ath-mtu/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-m= tu-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-pol= icy-path-mtu Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sr-polic= y-path-mtu-01 Abstract: Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. This document defines extensions to BGP to distribute path MTU information within SR policies. 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 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 27, 2020 11:35 PM To: idr@ietf.org Subject: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 The comment period on the adoption of draft-li-idr-sr-policy-path-mtu-03.tx= t has completed. The IDR WG has reached consensus to adopt this draft. The authors should submit this draft as draft-ietf-idr-sr-policy-path-mtu-0= 0.txt. Cheerily, Susan Hares --_000_C7C2E1C43D652C4E9E49FE7517C236CB029F84D1dggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Susan,

 

Thank you for your not= ification. Already uploaded the text.

 

Also, we updated the e= rror handling rules to align with the rules defined in draft-ietf-idr-segme= nt-routing-te-policy. Also, added text of Implementation status.=

 

Will address the comme= nts from Ketan and Aijun and Linda ASAP. Many thanks!

 

Best Regards,

Cheng

 

 

 

A new version of I-D, draft-ietf-idr-sr-policy-pa= th-mtu-01.txt

has been successfully submitted by Cheng Li and p= osted to the IETF repository.

 

Name:       &n= bsp;          draft-ietf-idr-s= r-policy-path-mtu

Revision:      &nbs= p;       01

Title:       &= nbsp;           &nbs= p;  Segment Routing Path MTU in BGP

Document date:      = ;         2020-04-28

Group:       &= nbsp;          idr<= /p>

Pages:       &= nbsp;           9

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-ietf-idr-sr-policy-path-mtu-01.t= xt

Status:       =   https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-path-mtu/

Htmlized:       https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-mtu-01

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-mtu=

Diff:       &n= bsp;   https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sr-policy-path-mtu-01

 

Abstract:

   Segment Routing is a source routing = paradigm that explicitly

   indicates the forwarding path for pa= ckets at the ingress node.  An SR

   policy is a set of candidate SR path= s consisting of one or more

   segment lists with necessary path at= tributes.  However, the path

   maximum transmission unit (MTU) info= rmation for SR path is not

   available in the SR policy since the= SR does not require signaling.

   This document defines extensions to = BGP to distribute path MTU

   information within SR policies.=

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

 

 

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

 

The IETF Secretariat

 

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Monday, April 27, 2020 11:35 PM
To: idr@ietf.org
Subject: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13=

 

The comment period on the adoption of draft-li-idr-s= r-policy-path-mtu-03.txt has completed.

The IDR WG has reached consensus to adopt this draft= .

 

The authors should submit this draft as draft-ietf-i= dr-sr-policy-path-mtu-00.txt.

 

Cheerily, Susan Hares

 

 

--_000_C7C2E1C43D652C4E9E49FE7517C236CB029F84D1dggeml529mbxchi_-- From nobody Tue Apr 28 06:26:04 2020 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 627D03A155D for ; Tue, 28 Apr 2020 06:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=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 7VNfaGDqRAhP for ; Tue, 28 Apr 2020 06:25:51 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 855C43A156D for ; Tue, 28 Apr 2020 06:25:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Chengli \(Cheng Li\)'" , References: <005201d61ca9$71152430$533f6c90$@ndzh.com> In-Reply-To: Date: Tue, 28 Apr 2020 09:25:44 -0400 Message-ID: <00a801d61d60$85ed36b0$91c7a410$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01D61D3E.FEDF1920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYIZzeOOzq/uO4/lfIasGbYGMbBQJlJUMrqHdUfHA= Content-Language: en-us X-Antivirus: AVG (VPS 200427-0, 04/27/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 13:26:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A9_01D61D3E.FEDF1920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cheng: Please send a note to the list when you address the issues from Ketan, Aijun and Linda. Thanks, Susan Hares From: Chengli (Cheng Li) [mailto:chengli13@huawei.com] Sent: Tuesday, April 28, 2020 6:27 AM To: Susan Hares; idr@ietf.org Subject: RE: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 Hi Susan, Thank you for your notification. Already uploaded the text. Also, we updated the error handling rules to align with the rules defined in draft-ietf-idr-segment-routing-te-policy. Also, added text of Implementation status. Will address the comments from Ketan and Aijun and Linda ASAP. Many thanks! Best Regards, Cheng A new version of I-D, draft-ietf-idr-sr-policy-path-mtu-01.txt has been successfully submitted by Cheng Li and posted to the IETF repository. Name: draft-ietf-idr-sr-policy-path-mtu Revision: 01 Title: Segment Routing Path MTU in BGP Document date: 2020-04-28 Group: idr Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-sr-policy-path-mtu-01.tx t Status: https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-path-mtu/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-mtu-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-mtu Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sr-policy-path-mtu-01 Abstract: Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. This document defines extensions to BGP to distribute path MTU information within SR policies. 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 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 27, 2020 11:35 PM To: idr@ietf.org Subject: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 The comment period on the adoption of draft-li-idr-sr-policy-path-mtu-03.txt has completed. The IDR WG has reached consensus to adopt this draft. The authors should submit this draft as draft-ietf-idr-sr-policy-path-mtu-00.txt. Cheerily, Susan Hares ------=_NextPart_000_00A9_01D61D3E.FEDF1920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cheng:

 

Please send a note to = the list when you address the issues from Ketan, Aijun and Linda. =

 

Thanks, Susan Hares =

 

From:= = Chengli (Cheng Li) [mailto:chengli13@huawei.com]
Sent: = Tuesday, April 28, 2020 6:27 AM
To: Susan Hares; = idr@ietf.org
Subject: RE: [Idr] = draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to = 4/13

 

Hi Susan,

 

Thank you for your = notification. Already uploaded the text.

 

Also, we updated the = error handling rules to align with the rules defined in = draft-ietf-idr-segment-routing-te-policy. Also, added text of = Implementation status.

 

Will address the = comments from Ketan and Aijun and Linda ASAP. Many = thanks!

 

Best = Regards,

Cheng

 

 

 

A new = version of I-D, = draft-ietf-idr-sr-policy-path-mtu-01.txt

has been successfully submitted by Cheng Li and = posted to the IETF repository.

 

Name:        = ;          = draft-ietf-idr-sr-policy-path-mtu

Revision:       &= nbsp;      01

Title:       &nbs= p;            = ;  Segment Routing Path MTU in BGP

Document = date:           &n= bsp;   2020-04-28

Group:       &nbs= p;          = idr

Pages:       &nbs= p;           = 9

URL:        =     https://www.ietf.org/internet-drafts/draft-ietf-idr-sr-poli= cy-path-mtu-01.txt

Status:       &nb= sp; https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-path-mtu/

Htmlized:       https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-mtu-01

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-pa= th-mtu

Diff:        = ;   https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sr-policy-pat= h-mtu-01

 

Abstract:

   Segment Routing is a source routing = paradigm that explicitly

   indicates the forwarding path for = packets at the ingress node.  An SR

   policy is a set of candidate SR paths = consisting of one or more

   segment lists with necessary path = attributes.  However, the path

   maximum transmission unit (MTU) = information for SR path is not

   available in the SR policy since the = SR does not require signaling.

   This document defines extensions to = BGP to distribute path MTU

   information within SR = policies.

 

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;            =

 

 

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

 

 

From: Idr = [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Monday, April 27, 2020 11:35 PM
To: = idr@ietf.org
Subject: [Idr] = draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to = 4/13

 

The comment = period on the adoption of draft-li-idr-sr-policy-path-mtu-03.txt has = completed.

The IDR WG has reached = consensus to adopt this draft.

 

The authors = should submit this draft as draft-ietf-idr-sr-policy-path-mtu-00.txt. =

 

Cheerily, Susan Hares

 

 

------=_NextPart_000_00A9_01D61D3E.FEDF1920-- From nobody Tue Apr 28 08:45:20 2020 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 1BC7D3A16E9 for ; Tue, 28 Apr 2020 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.848 X-Spam-Level: ** X-Spam-Status: No, score=2.848 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 tAJYIKsId8Gg for ; Tue, 28 Apr 2020 08:45:16 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 54A913A16D7 for ; Tue, 28 Apr 2020 08:45:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: Date: Tue, 28 Apr 2020 11:45:11 -0400 Message-ID: <013301d61d74$010f9aa0$032ecfe0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01D61D52.79FE48C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYdcjsBv2nNt2GqQU+Noo20zKnovA== Content-Language: en-us X-Antivirus: AVG (VPS 200427-0, 04/27/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt (4/28 to 5/14/2020) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 15:45:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0134_01D61D52.79FE48C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is an IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt. The authors should send their IPR statement. The WG LC for this draft will begin as soon as all authors send in their IPR statements. Cheerily, Susan Hares ------=_NextPart_000_0134_01D61D52.79FE48C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is an = IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt.   =

The authors  should send their = IPR statement. 

 

The WG LC = for this draft will begin as soon as all authors send in their IPR = statements.

 

Cheerily, Susan Hares =

------=_NextPart_000_0134_01D61D52.79FE48C0-- From nobody Tue Apr 28 09:51:05 2020 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 2115B3A0433 for ; Tue, 28 Apr 2020 09:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFwTL5PsCuvL for ; Tue, 28 Apr 2020 09:51:00 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 CB3083A05A0 for ; Tue, 28 Apr 2020 09:50:57 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id z2so23721221iol.11 for ; Tue, 28 Apr 2020 09:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K4VhMb+mMxam+4EzuX7QVwoH2EFjy/5XtRUnHryAdAo=; b=eyUWnVcSGo8Um4uwgm4zuUvSWFs3y1DBpM88mRc0NOHzqKIDM2ym7/Bg+PQiewbSCe DQygpLVXJnn1g72/9zGPkAlpeSRqpCY4ovdNeXgfcT2Sf/ntkYJe2TbX3b39Xa3YtP9P 2Yy3+KG5DqF+c6CPGly/oNku51SybfiBjs3DHFBrz6DGUzsif1Vk1T4/z8Vf9z3VJkSB 2JkgknbLv3CRgUUu2e+z1WSwO6cxtGeccmjoY7lSOEjEn+SZZaxijs4MgpZr3LFtdLnd IKu8YR1UcZsThe/L6pYN9R1LSDh6D56/zEk/qAIOXeybIcrmveEuY1AXnWB1U4ciYd5Y 9rCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K4VhMb+mMxam+4EzuX7QVwoH2EFjy/5XtRUnHryAdAo=; b=Ki0mEddbAsEyfi32Sr/+O9H9KPA48pk4CsmRbqOb2yfV02X5O4N7fMTs0FNW5ymtrB Hl+//EENGeW1rlTsPby3tpeodPqJ7+U8WPEiB0wFgQy9YOWQqCAuGKtqT55Gp7EUaz8P k29t0g8RLXJczeQLLKNtrgEoWiX3SDx4nTUJ+OpczGeDyfY6BULHQFSCLugljRIiwrXN H3BB9J0FNWlFruLrZM0TNFazP/OfhR0U65IHHbVlp3AsYLVJGwjXiHACOKtk+vHKyIhI w20glRplmMGPpJm3PtgmWzo6iB+T9Vo0Wg6FobCSjJgd2Z5ZfQCo+mwn/avwre4sWcqv jTTw== X-Gm-Message-State: AGi0PuZY7VZN6MFEmtBVeelL3xztBjjtidYxhCS4kMxlq/SzqcBvumTM 23vHHZCOJ9aWVmEBPscA9U7lqWh3ZDQ5/Xx6KlZsn5ulXx8= X-Google-Smtp-Source: APiQypL++nasi5XdATtlDYVmFzWx0jnor8+eSqFu/6552NINT7teQR6AcH9M/85VNycgN12zGAPvw7hvQiHuGfS+eR8= X-Received: by 2002:a6b:6e08:: with SMTP id d8mr21825542ioh.167.1588092656942; Tue, 28 Apr 2020 09:50:56 -0700 (PDT) MIME-Version: 1.0 References: <013301d61d74$010f9aa0$032ecfe0$@ndzh.com> In-Reply-To: <013301d61d74$010f9aa0$032ecfe0$@ndzh.com> From: Donald Eastlake Date: Tue, 28 Apr 2020 12:50:45 -0400 Message-ID: To: Susan Hares Cc: "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt (4/28 to 5/14/2020) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 16:51:02 -0000 I am not aware of any IPR in draft-ietf-idr-flowspec-l2vpn-14.txt that has not already been disclosed to the IETF. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Tue, Apr 28, 2020 at 11:45 AM Susan Hares wrote: > > This is an IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt. > > The authors should send their IPR statement. > > > > The WG LC for this draft will begin as soon as all authors send in their IPR statements. > > > > Cheerily, Susan Hares > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Apr 28 13:31:16 2020 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 29DAB3A0C70; Tue, 28 Apr 2020 13:31:14 -0700 (PDT) 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.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158810587410.32431.10858089785243044870@ietfa.amsl.com> Date: Tue, 28 Apr 2020 13:31:14 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-24.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 20:31:14 -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 : Dissemination of Flow Specification Rules Authors : Christoph Loibl Susan Hares Robert Raszuk Danny McPherson Martin Bacher Filename : draft-ietf-idr-rfc5575bis-24.txt Pages : 39 Date : 2020-04-28 Abstract: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. Other applications (e.g. centralized control of traffic in a SDN or NFV context) are also possible. Other documents may specify Flow Specification extensions. The information is carried via BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. This document obsoletes both RFC5575 and RFC7674. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-24 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-24 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 Tue Apr 28 13:43:57 2020 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 6A98C3A0CE7; Tue, 28 Apr 2020 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 7apYnZnqT9lk; Tue, 28 Apr 2020 13:43:46 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::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 9FFDB3A0CCA; Tue, 28 Apr 2020 13:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=Message-Id:To:Cc:References:Date:Subject:Mime-Version:Content-Type: From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=HMbgzdrgA67LZYq0hZltubLsc+YF8UNAfbTcPC/7J1o=; b=Q wEb3p3F7T4nRrf/kXUyU0FshR88WIRcsyJwe4KxKo0fMjIAB0cHc1w7KHQQRIV3JdhPNZUu15nEOT 0ZIgKQ/qMcUBdfnYs9uR1VC45XikZAwF9PA0pqHkyZy+niITjlCjAT9T/X1+h9xVV6+p0yFiILPX8 dDkpHOWYv/HgVcWQj3Z6uDMkoPPmSC+JjuksYQriT8dAdfQm5Vj7x4Ft4lmvRokWhGkk7I12GMiem 4Et5tA3b7k40qwtWa9aBCnA6TJmN5uQGzGxm4UXJk2si/AViW7v+6iy8xWHvxUtuIxSX30gCSLx7T W3pGVJrZ9F1wlLk2IA1w7PmXhIRMzvuYQ==; Received: from [213.147.165.5] (helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jTX4u-000Ntr-UV; Tue, 28 Apr 2020 22:43:43 +0200 From: Christoph Loibl Content-Type: multipart/alternative; boundary="Apple-Mail=_E1B5EFE1-500E-402D-AEB1-29AB8A636F77" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Tue, 28 Apr 2020 22:43:31 +0200 References: <158810587410.32431.10858089785243044870@ietfa.amsl.com> Cc: draft-ietf-idr-rfc5575bis@ietf.org To: IDR List , The IESG Message-Id: <3D2F86AA-7C69-49EA-AB2F-87CA03FF46C9@tix.at> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Tue, 28 Apr 2020 22:43:41 +0200 Archived-At: Subject: [Idr] Fwd: I-D Action: draft-ietf-idr-rfc5575bis-24.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 20:43:53 -0000 --Apple-Mail=_E1B5EFE1-500E-402D-AEB1-29AB8A636F77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On behalf of the authors I just uploaded a new Version of the draft: > 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. >=20 > Title : Dissemination of Flow Specification Rules > Authors : Christoph Loibl > Susan Hares > Robert Raszuk > Danny McPherson > Martin Bacher > Filename : draft-ietf-idr-rfc5575bis-24.txt > Pages : 39 > Date : 2020-04-28 This revision includes some smaller changes as a result of the IESG = review process. All the issues from this reviews have been added to the = Github repo at https://github.com/stoffi92/rfc5575bis = and can be reviewed there. Currently there is only one open issue. Thank you for all the comments on the draft! Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_E1B5EFE1-500E-402D-AEB1-29AB8A636F77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

On behalf of the authors I just uploaded a new Version of the = draft:

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 =           : = Dissemination of Flow Specification Rules
       Authors =         : Christoph Loibl
          &nb= sp;            = ;  Susan Hares
          &nb= sp;            = ;  Robert Raszuk
          &nb= sp;            = ;  Danny McPherson
          &nb= sp;            = ;  Martin Bacher
Filename =        : = draft-ietf-idr-rfc5575bis-24.txt
Pages =           : 39
= Date =            : = 2020-04-28

This revision includes some smaller = changes as a result of the IESG review process. All the issues from this = reviews have been added to the Github repo at

https://github.com/stoffi92/rfc5575bis

and can be reviewed = there. Currently there is only one open issue.

Thank you for all the comments on the = draft!

Cheers

Christoph

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

= --Apple-Mail=_E1B5EFE1-500E-402D-AEB1-29AB8A636F77-- From nobody Tue Apr 28 14:06:26 2020 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 A9E723A0D7A; Tue, 28 Apr 2020 14:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pSvL_lTUGgWE; Tue, 28 Apr 2020 14:06:21 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 24EB33A0D6D; Tue, 28 Apr 2020 14:06:20 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id k12so293783wmj.3; Tue, 28 Apr 2020 14:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=oT1igAMOT1G0oL0j180RC3z29yL5pdnribtH/EDZTQM=; b=CKo2mjUDVas0DJ/uSqohlOWCRaPsiaQSYcGDfNh5AUhJcLS9yxj9xHKUlc4ZyZStIM uz9/xTwu/0ogH8OYXG0MvR692aXj6X7GyNdVgxtWaNJBxHGga8C03e7nl5GqAvfiukje fHmy/OxMhBCff+AyG89/H+2g5DIKEO0DswJ2twzEV7mfx+fW/RAGJSuz4WXO9+YNnPLD RNfMnR117/NOWmNHwzp7q6JYtIpRsyyZpPOSqHO7WufTUFChtrRYuENEQDpXb30YJH7e uahy17B2JDfkJANQBCxwjPFU8ZkU0QiaLyTSf6RNQunMM70iINRkb1/DdFskmY7GOaOo NMAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=oT1igAMOT1G0oL0j180RC3z29yL5pdnribtH/EDZTQM=; b=fJXGanPpj1XV/WKb7IEh8cS5nLDiM8z6mDyqKe5ODyrL3Qdc7eOCxriKIU4ZCIjcOs hbVEdpSrR970uyk2NYhUqKOwzXFrzbLjOpVMonSuhzasTVVA3+97aLsx2bJMGqYLr115 xWoxaYL/DNJ2DeWYZqANCHbJxl6LO9QdrOoQwxAFUZCn74NP0JSyZC3DsOU50JzAEiD2 QssDwNAy/gue4zdulbsXIP6/Eu9K09L+9T2qGjvGHZn/uK72ocj2sCOxjK4uTkXumxes Fqk/dUMbPRAxKcrVEaM2O3GAr0ywdOFioEYGuYv5JZfLatyWhno6FNmJXr6RTOxylg90 X93g== X-Gm-Message-State: AGi0PuYLNH7mNQZuUV7eUREQJIV//JlnbVeNXbnQmybMoMBcil1FUB4e 4io6lblVqWJ8lt4jSeEbnkXBe94DIM/AAfkdxFE= X-Google-Smtp-Source: APiQypKAZwOqrUbnW3t9TiD2EmI3rMh2qBaQbYU0JL2ia2bCrUNAesZ/Hd2fgkHvvfd0Vm7abqXn1xLNopAS2sTnNw8= X-Received: by 2002:a05:600c:28e:: with SMTP id 14mr6952324wmk.79.1588107979386; Tue, 28 Apr 2020 14:06:19 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Apr 2020 21:06:18 +0000 From: Alvaro Retana In-Reply-To: <3D2F86AA-7C69-49EA-AB2F-87CA03FF46C9@tix.at> References: <158810587410.32431.10858089785243044870@ietfa.amsl.com> <3D2F86AA-7C69-49EA-AB2F-87CA03FF46C9@tix.at> MIME-Version: 1.0 Date: Tue, 28 Apr 2020 21:06:18 +0000 Message-ID: To: Christoph Loibl , Jie Dong Cc: draft-ietf-idr-rfc5575bis@ietf.org, The IESG , IDR List Content-Type: multipart/alternative; boundary="000000000000f9f58305a4603350" Archived-At: Subject: Re: [Idr] Fwd: I-D Action: draft-ietf-idr-rfc5575bis-24.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 21:06:25 -0000 --000000000000f9f58305a4603350 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christoph: Thanks for the update! As mentioned before, I=E2=80=99ll hold approval until Jie (cc=E2=80=99d) co= nfirms the changes (per Rob=E2=80=99s DISCUSS) and an update is submitted. Thanks!! Alvaro. On April 28, 2020 at 4:44:11 PM, Christoph Loibl (c@tix.at) wrote: This revision includes some smaller changes as a result of the IESG review process. All the issues from this reviews have been added to the Github repo at https://github.com/stoffi92/rfc5575bis and can be reviewed there. Currently there is only one open issue. --000000000000f9f58305a4603350 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Christoph:

Thanks for the update!

As mentioned before, I=E2=80=99ll hold approval unti= l Jie (cc=E2=80=99d) confirms the changes (per Rob=E2=80=99s DISCUSS) and a= n update is submitted.

Thanks!!

Alvaro= .

On April 28, 2020 at 4:44:11 PM, Christ= oph Loibl (c@tix.at) wrote:

This revision includes some smaller changes as a res= ult of the IESG review process. All the issues from this reviews have been = added to the Github repo at

https://github.com/stoffi= 92/rfc5575bis

= and can be reviewed there. Currently there is only one open issue.
--000000000000f9f58305a4603350-- From nobody Tue Apr 28 16:50:43 2020 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 90D7F3A0ACD; Tue, 28 Apr 2020 16:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jmVjs6e0uw8; Tue, 28 Apr 2020 16:50:37 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 906373A0AC9; Tue, 28 Apr 2020 16:50:36 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id b18so724587ilf.2; Tue, 28 Apr 2020 16:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=26i7oENWhAtDIsZ+lIdDQxMzbHKi6rABW2OgwCs42dk=; b=Aa4uvGQPImUOVIgdBRNbnnfmQEl1rJZgKwVu/QtGJaOm/O73wVSqnwc/zjJdMleZGq V3KAJ4JLlvtDtf07vvp2IdN6XxROtVbysT2Wllv48oZ7brWRpC8eT39QEU57qvec4BSI uzDCw2KmY4jbyKlvNdC28XWQpZPOa5aFm//GALmQtZL/yzlKQ/awmp4bNG02JnDJDgTi U2UqjxpoOerCCj9Sw3HGjaCve/h3Na2n7HHctFqeruu7QjkQdTzSsUTzdRwQ1XCB/6Iu Z8Sj1qQqD1X9LTjxqNSBHojcjjbKCVpHdQ/UnayPMBdtVgudcExCpk2bsZJ8VqTJBL5h nGQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=26i7oENWhAtDIsZ+lIdDQxMzbHKi6rABW2OgwCs42dk=; b=QsIlzfMGxoaM3thfQDUO6V1LWbBI0T0x8s3YOpeeA7bSyOz+tlULD8zm8Xb+cudDuI YmsxrW3DSXOUx0j60550qVjHl0eDGENUcsotKRLlOPZt1lh4EWlQAqaY2KTa6zMv0SXn PgEhkVHls+5e4eWm36cLIcwbsxy0VSDZFVMHFo2dao1QxqeFcEKb6ETEZGF/1WN7l+U6 FMk6qgKbfhpmF3ixvr/WXqV1yBhJ1Ys6OiDSFwvBLQxmouDH2G+3AEd0UaECCZNgpkSu xUbs1TmSCZ8+tEKbN1XHuM78AcE8Ng782HhmLbTfGj6/GUUqVhsnixehp5voXWNePiSG p/+w== X-Gm-Message-State: AGi0PuZ35a4qwz1XY6p6DgPEjD/vL1OOGBKh156ClLU/SS4cXWf9I0mg NBqM6qQ4Fi04NEDu+3bFy/W1DRzfI+IVOHQbr1J2RF06BTk= X-Google-Smtp-Source: APiQypL2cmlQBu+ChoCjfdzZ2AhGwMu8zTCTTExzYkdBBz+IezZik5za/34ZyLSWFwW6ONAxvfCr2LXJN7b0/SkvxFM= X-Received: by 2002:a92:3c55:: with SMTP id j82mr29856211ila.258.1588117835396; Tue, 28 Apr 2020 16:50:35 -0700 (PDT) MIME-Version: 1.0 References: <158629580378.13606.6350807287790835622@ietfa.amsl.com> <42014AE1-D058-486E-9E17-475D07A91885@tix.at> In-Reply-To: From: Gyan Mishra Date: Tue, 28 Apr 2020 19:50:24 -0400 Message-ID: To: Alissa Cooper Cc: Christoph Loibl , General Area Review Team , IDR List , draft-ietf-idr-rfc5575bis.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="00000000000070bc1305a4627faa" Archived-At: Subject: Re: [Idr] [Gen-art] Genart last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 23:50:41 -0000 --00000000000070bc1305a4627faa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Christoph & Alissa Gyan On Wed, Apr 22, 2020 at 9:55 AM Alissa Cooper wrote: > Gyan, thanks for your review. Christoph, thanks for your response. I thin= k > the intro in the draft is ok as-is. I entered a DISCUSS ballot with a > question about Section 7. > > Alissa > > > On Apr 17, 2020, at 3:43 AM, Christoph Loibl wrote: > > Hi Gyan, > > Thanks for your review. According to your review I made the following > changes to the document which is available now as revision -22: > > On 07.04.2020, at 23:43, Gyan Mishra via Datatracker > wrote: > > Reviewer: Gyan Mishra > Review result: Ready with Nits > > Reviewer: Gyan Mishra > Review result: Ready with Minor Issues > > Minor issues: > I am familiar with BGP Flow specification and would like to recommend som= e > verbiage that may help in the introduction as far as explaining how BGP > flow > spec works. Ssince the introduction has been re-written with this update= , > this > could be a possible addition to the draft. > > This could be placed at the end of the introduction if desired. > BGP flow specification is a client-server model that allows for a more > granular > approach to DDOS mitigation than its predecessor, =E2=80=9CRemotely Trigg= ered > Blackhole > (RTBF) which tagged a prefix with a community and sent it do a discard ne= xt > hop. BGP flow spec has two main components, the =E2=80=9Ccontroller=E2= =80=9D being the BGP > speaker device which acts as the server side, which injects the new > flowspec > entry, and the client side which is the BGP speaker devices that receives > the > flowspec NLRI and acts on the instruction to match a particular flow with > Layer > 3 and Layer 4 parameters and then implements the hardware forwarding acti= on > requested. > > > <-- > Tracked via issue #163: https://github.com/stoffi92/rfc5575bis/issues/163 > > I do not agree that BGP flowspec is a client-server model -only-. We can > propagate this NLRI over administrative domain borders as we do with IP > routing information, it follows the same mechanisms. We see such solution= s > being deployed in the internet as inter provider DDoS solutions. > > We actually had a paragraph in the darft that was explaining the > advantages over other approaches like RTBF but this has been removed > because it was pointed out that it is not relevant to the spec to justify= a > well deployed technology. > --> > > > Nits/editorial comments: > 7. Traffic Filtering Actions > This document defines a minimum set of Traffic Filtering Actions that > it standardizes as BGP extended community values [RFC4360] > > Any mention of [RFC4360] should be updated with [RFC7153] IANA Registri= es > for BGP Extended Communities. > > > <-- > Tracked via issue #164: https://github.com/stoffi92/rfc5575bis/issues/164 > Commits mentions: > > https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa2750fd376d= c148d7a590369 > > https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7d5c1822070= b862247dfaead > > Removed the "values" statement (as suggested by Alvaro) from the draft to > make clear we are not talking about particular values but about Extended > Communities as specified in RFC4360. > s/standardizes as BGP extended community values [RFC4360]/standardizes as > BGP extended communities [RFC4360]/ > > --> > > Cheers > Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > > > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --00000000000070bc1305a4627faa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Christoph & Alissa

Gyan

On Wed, Apr 22, 2020 at 9:5= 5 AM Alissa Cooper <alissa@cooperw.= in> wrote:
Gyan, thanks for your revie= w. Christoph, thanks for your response. I think the intro in the draft is o= k as-is. I entered a DISCUSS ballot with a question about Section 7.
<= div style=3D"word-wrap:break-word;line-break:after-white-space">

Alissa


On Ap= r 17, 2020, at 3:43 AM, Christoph Loibl <c@tix.at> wrote:

Hi Gyan,

Thanks for your review. According to your review I made th= e following changes to the document which is available now as revision -22:=

On 07.04.202= 0, at 23:43, Gyan Mishra via Datatracker <noreply@ietf.org> wrote:

= Reviewer: Gyan Mishra
Review result: Ready with Nits

Reviewer: Gy= an Mishra
Review result: Ready with Minor Issues

Minor issues:I am familiar with BGP Flow specification and would like to recommend some=
verbiage that may help in the introduction as far as explaining how BGP= flow
spec works.=C2=A0 Ssince the introduction has been re-written with= this update, this
could be a possible addition to the draft.

Thi= s could be placed at the end of the introduction if desired.
BGP flow sp= ecification is a client-server model that allows for a more granular
app= roach to DDOS mitigation than its predecessor, =E2=80=9CRemotely Triggered = Blackhole
(RTBF) which tagged a prefix with a community and sent it do a= discard next
hop.=C2=A0 BGP flow spec has two main components, the =E2= =80=9Ccontroller=E2=80=9D being the BGP
speaker device which acts as the= server side, which injects the new flowspec
entry, and the client side = which is the BGP speaker devices that receives the
flowspec NLRI and act= s on the instruction to match a particular flow with Layer
3 and Layer 4= parameters and then implements the hardware forwarding action
requested= .

<--=C2=A0
Tracked v= ia issue #163:=C2=A0https://github.com/stoffi92/rfc5575bi= s/issues/163

I do not agree that BGP flowspec is a client-server= model -only-. We can propagate this NLRI over administrative domain border= s as we do with IP routing information, it follows the same mechanisms. We = see such solutions being deployed in the internet as inter provider DDoS so= lutions.

We actually had a paragraph in the darft that was explainin= g the advantages over other approaches like RTBF but this has been removed = because it was pointed out that it is not relevant to the spec to justify a= well deployed technology.
-->


Nits/editorial comments:
7.=C2=A0 Traffic Filt= ering Actions
=C2=A0=C2=A0This document defines a minimum set of Traffic= Filtering Actions that
=C2=A0=C2=A0it standardizes as BGP extended comm= unity values [RFC4360]

=C2=A0=C2=A0Any mention of [RFC4360] should b= e updated with [RFC7153] IANA Registries
=C2=A0=C2=A0for BGP Extended Co= mmunities.


<--=C2=A0=
Tracked via issue #164:=C2=A0https://github.com/stoff= i92/rfc5575bis/issues/164
Commits mentions:
=C2=A0 =C2=A0= =C2=A0https://github.com/s= toffi92/rfc5575bis/commit/31f0ac79b7cd998aa2750fd376dc148d7a590369
= =C2=A0 =C2=A0=C2=A0h= ttps://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7d5c1822070b86= 2247dfaead

Removed the "values" statement (as suggeste= d by Alvaro) from the draft to make clear we are not talking about particul= ar values but about =C2=A0Extended Communities as specified in RFC4360.
= s/standardizes as BGP extended community values [RFC4360]/standardizes as B= GP extended communities [RFC4360]/

-->
<= br>
Cheers=C2=A0
Christoph

--=C2=A0
Christoph Loibl
c@tix.at=C2=A0| CL8-RIPE | PGP-Key-ID:= =C2=A00x4B2C0055 |=C2=A0http://www.nextlayer.at

<= div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va= riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start= ;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te= xt-decoration:none">

_______________________________= ________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

--
=

Gyan=C2=A0 Mishra

= Network Engineer= ing & Technology=C2=A0

Verizon=C2=A0

= Silver Spring, MD 20904

Phone: 301 502-1347

Email: gy= an.s.mishra@verizon.com


=

--00000000000070bc1305a4627faa-- From nobody Tue Apr 28 18:21:09 2020 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 05EC53A0995 for ; Tue, 28 Apr 2020 18:21:07 -0700 (PDT) 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 rdt2QACU00Cx for ; Tue, 28 Apr 2020 18:21:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7448C3A0992 for ; Tue, 28 Apr 2020 18:21:05 -0700 (PDT) Received: from lhreml720-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 38A529ABFAABA402D907; Wed, 29 Apr 2020 02:21:04 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Apr 2020 02:21:03 +0100 Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Apr 2020 09:21:01 +0800 Received: from nkgeml706-chm.china.huawei.com ([10.98.57.153]) by nkgeml706-chm.china.huawei.com ([10.98.57.153]) with mapi id 15.01.1913.007; Wed, 29 Apr 2020 09:21:01 +0800 From: Haoweiguo To: Donald Eastlake , Susan Hares CC: "idr@ietf. org" Thread-Topic: [Idr] IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt (4/28 to 5/14/2020) Thread-Index: AdYdcjsBv2nNt2GqQU+Noo20zKnovP//j7+A//7rh7A= Date: Wed, 29 Apr 2020 01:21:01 +0000 Message-ID: <0f183958abf74e20a485806a10512e00@huawei.com> References: <013301d61d74$010f9aa0$032ecfe0$@ndzh.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.30.193] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] =?gb2312?b?tPC4tDogIElQUiBjYWxsIGZvciBkcmFmdC1pZXRmLWlk?= =?gb2312?b?ci1mbG93c3BlYy1sMnZwbi0xNC50eHQgKDQvMjggdG8gNS8xNC8yMDIwKQ==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 01:21:07 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBpbiBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1sMnZw bi0xNC50eHQgdGhhdCBoYXMgbm90IGFscmVhZHkgYmVlbiBkaXNjbG9zZWQgdG8gdGhlIElFVEYu DQoNClRoYW5rcywNCldlaWd1bw0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogSWRyIFtt YWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRG9uYWxkIEVhc3RsYWtlDQq3osvNyrG8 5DogMjkgdU1iYXNvIDIwMjAgMTI6NTEgQU0NCsrVvP7IyzogU3VzYW4gSGFyZXMgPHNoYXJlc0Bu ZHpoLmNvbT4NCrOty806IGlkckBpZXRmLiBvcmcgPGlkckBpZXRmLm9yZz4NCtb3zOI6IFJlOiBb SWRyXSBJUFIgY2FsbCBmb3IgZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2cG4tMTQudHh0ICg0 LzI4IHRvIDUvMTQvMjAyMCkNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBpbiBkcmFmdC1p ZXRmLWlkci1mbG93c3BlYy1sMnZwbi0xNC50eHQgdGhhdCBoYXMgbm90IGFscmVhZHkgYmVlbiBk aXNjbG9zZWQgdG8gdGhlIElFVEYuDQoNClRoYW5rcywNCkRvbmFsZA0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIy NzAgKGNlbGwpDQogMjM4NiBQYW5vcmFtaWMgQ2lyY2xlLCBBcG9wa2EsIEZMIDMyNzAzIFVTQSAg ZDNlM2UzQGdtYWlsLmNvbQ0KDQpPbiBUdWUsIEFwciAyOCwgMjAyMCBhdCAxMTo0NSBBTSBTdXNh biBIYXJlcyA8c2hhcmVzQG5kemguY29tPiB3cm90ZToNCj4NCj4gVGhpcyBpcyBhbiBJUFIgY2Fs bCBmb3IgZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtbDJ2cG4tMTQudHh0Lg0KPg0KPiBUaGUgYXV0 aG9ycyAgc2hvdWxkIHNlbmQgdGhlaXIgSVBSIHN0YXRlbWVudC4NCj4NCj4NCj4NCj4gVGhlIFdH IExDIGZvciB0aGlzIGRyYWZ0IHdpbGwgYmVnaW4gYXMgc29vbiBhcyBhbGwgYXV0aG9ycyBzZW5k IGluIHRoZWlyIElQUiBzdGF0ZW1lbnRzLg0KPg0KPg0KPg0KPiBDaGVlcmlseSwgU3VzYW4gSGFy ZXMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== From nobody Tue Apr 28 19:52:41 2020 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 1EC5F3A0C23; Tue, 28 Apr 2020 19:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awmrXzoJ5QpI; Tue, 28 Apr 2020 19:52:36 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B333A0C13; Tue, 28 Apr 2020 19:52:36 -0700 (PDT) Received: from lhreml721-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 52E6041B8180A6A24AD1; Wed, 29 Apr 2020 03:52:34 +0100 (IST) Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by lhreml721-chm.china.huawei.com (10.201.108.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Wed, 29 Apr 2020 03:52:33 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 29 Apr 2020 10:52:31 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Wed, 29 Apr 2020 10:52:30 +0800 From: "Dongjie (Jimmy)" To: "Kirill.Kasavchenko@netscout.com" , "thomas.mangin@exa.net.uk" , "jhaas@juniper.net" , "bduvivie@cisco.com" , "Dongjie (Jimmy)" CC: IDR List , Alvaro Retana , "idr-chairs@ietf.org" Thread-Topic: Poll on the RFC5575bis implementations about the suggested changes during IETF review Thread-Index: AdYdzirJcIjY0X+CQ6WojBM8V+RWPw== Date: Wed, 29 Apr 2020 02:52:30 +0000 Message-ID: <14293c9f9c2e41219a13f09adacb6289@huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.184.136] Content-Type: multipart/alternative; boundary="_000_14293c9f9c2e41219a13f09adacb6289huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 02:52:39 -0000 --_000_14293c9f9c2e41219a13f09adacb6289huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBcyB5b3UgbWF5IGhhdmUgbm90aWNlZCwgZHVyaW5nIHRoZSBJRVRGIHJldmll dyBvZiBkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLCB0aGVyZSB3YXMgc29tZSBkaXNjdXNzaW9u IGFib3V0IHRoZSBkZXNjcmlwdGlvbiBvZiBiaXQvZmxhZyBzZXR0aW5ncyBpbiB0aGlzIGRyYWZ0 Lg0KDQpCYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBpbiBJRVNHLCBvdXIgQUQgQWx2YXJvIHN1Z2dl c3RlZCB0byBtYWtlIGZvbGxvd2luZyBjaGFuZ2VzIHRvIHRoZSBkcmFmdDoNCg0KKDEpIEEgYml0 IGlzIGRlZmluZWQgYXMgMCwgYnV0IHRoZSBkZWZpbml0aW9uIGlzOiAiMCAtICBTSE9VTEQgYmUg c2V0IHRvIDDigKbigJ0gKMKnNC4yLjEuMSkuICBJZiBpdOKAmXMgMCwgdGhlbiBJIHNlZSBubyBy ZWFzb24gZm9yIHRoYXQgbm90IHRvIGJlIGEgTVVTVC4gIEluIGZhY3QsIGlmIGFsd2F5cyBzZXQg dG8gMCB3ZeKAmXJlIHByb2JhYmx5IG92ZXIgc3BlY2lmeWluZyB0aGUgZmllbGQuICAgVGhlcmUg YXJlIDMgb2NjdXJyZW5jZXMgb2YgdGhpcyBpbiB0aGUgZG9jdW1lbnQuDQoNCigyKSBVbnVzZWQg KMKnNy4zKSBvciByZXNlcnZlZCAowqc3LjUpIGRlZmluZWQgYXMgIlNIT1VMRCBiZSBzZXQgdG8g MC4uLk1VU1QgYmUgaWdub3JlZOKAnS4gIEFnYWluLCBpZiB1bnVzZWQvcmVzZXJ2ZWQsIEkgc2Vl IG5vIHJlYXNvbiBub3QgdG8gY2hhbmdlIHRvIE1VU1QuICBJIHRoaW5rIFJvYiBtYWtlcyBhIGdv b2QgcG9pbnQgYWJvdXQgZXh0ZW5zaWJpbGl0eS4NCg0KSW4gc3VtbWFyeSwgaXQgaXMgc3VnZ2Vz dGVkIHRoYXQgaW4gdGhlIGJpdC9mbGFnIGRlc2NyaXB0aW9ucywg4oCcU0hPVUxEIGJlIHNldCB0 byAw4oCm4oCdICBpcyByZXBsYWNlZCB3aXRoIOKAnE1VU1QgYmUgc2V0IHRvIDDigKbigJ0uDQoN CkJlZm9yZSBtYWtpbmcgdGhvc2UgY2hhbmdlcywgd2XigJlkIGxpa2UgdG8gcG9sbCB0aGUgaW1w bGVtZW50ZXJzIChlc3BlY2lhbGx5IHdobyByZXBvcnRlZCB0aGVpciBpbXBsZW1lbnRhdGlvbnMg dG8gSURSIGJlZm9yZSkgYWJvdXQgd2hldGhlciBzdWNoIGNoYW5nZXMgY2FuIGhhdmUgYW4gaW1w YWN0IHRvIHlvdXIgaW1wbGVtZW50YXRpb24uDQoNClRoaXMgcG9sbCB3aWxsIGxhc3QgZm9yIG9u ZSB3ZWVrIGFuZCBlbmQgb24gTWF5IDZ0aC4gTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgZmVlZGJh Y2tzLiBUaGFua3MuDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQpGcm9tOiBBbHZhcm8gUmV0YW5h IFttYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAy NSwgMjAyMCAxOjAwIEFNDQpUbzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86 c2hhcmVzQG5kemguY29tPj47IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNv bTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PjsgRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0Bo dWF3ZWkuY29tPG1haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tPj4NCkNjOiBpZHItY2hhaXJzQGll dGYub3JnPG1haWx0bzppZHItY2hhaXJzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pZHItcmZjNTU3 NWJpc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pZHItcmZjNTU3NWJpc0BpZXRmLm9yZz47 IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5v cmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFJvYmVydCBXaWx0b24ncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXMtMjM6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpDQoNCkhpIQ0KDQpBcyBSb2IgbWVudGlvbmVkLCB3ZSB0YWxrZWQgYWJvdXQgaGlz IERJU0NVU1MgZHVyaW5nIHRvZGF54oCZcyBJRVNHIFRlbGVjaGF0Lg0KDQpXZeKAmXJlIGFsbCBp biBhZ3JlZW1lbnQgdGhhdCB0aGUgbGFzdCB0aGluZyB3ZSB3YW50IHRvIGRvIGlzIHRvIGJyZWFr IGFueSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMsIHNwZWNpYWxseSBiZWNhdXNlIHRoaXMgZG9j dW1lbnQgaXMgYSBiaXMuDQoNCg0KSSBsb29rZWQgYXQgcmZjNTU3NSwgYW5kIEkgZGlkbuKAmXQg ZmluZCB0aGUgc2FtZSB0ZXh0IHRoZXJlIOKAlCBJIGZvdW5kIG5vIHNwZWNpZmljYXRpb24gb2Yg dGhlIHNldHRpbmcgb2YgdGhlIGJpdHMsIHNwZWNpYWxseSB0aGUgcmVzZXJ2ZWQgb25lcy4NCg0K W0kgYWxzbyBkaWQgYSBxdWljayBhbmQgdW5zY2llbnRpZmljIHNlYXJjaCBvZiBvdGhlciByb3V0 aW5nIGRvY3VtZW50cyBhbmQgZm91bmQgYSBtaXggb2YgU0hPVUxEL01VU1QgYW5kIE1VU1QvTVVT VCBjb25zdHJ1Y3Rz4oCmXQ0KDQoNCk5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIGRpc3RpbmN0IGNh c2VzIChpbiByZmM1NTc1YmlzKToNCg0KKDEpIEEgYml0IGlzIGRlZmluZWQgYXMgMCwgYnV0IHRo ZSBkZWZpbml0aW9uIGlzOiAiMCAtICBTSE9VTEQgYmUgc2V0IHRvIDDigKbigJ0gKMKnNC4yLjEu MSkuICBJZiBpdOKAmXMgMCwgdGhlbiBJIHNlZSBubyByZWFzb24gZm9yIHRoYXQgbm90IHRvIGJl IGEgTVVTVC4gIEluIGZhY3QsIGlmIGFsd2F5cyBzZXQgdG8gMCB3ZeKAmXJlIHByb2JhYmx5IG92 ZXIgc3BlY2lmeWluZyB0aGUgZmllbGQuICAgVGhlcmUgYXJlIDMgb2NjdXJyZW5jZXMgb2YgdGhp cyBpbiB0aGUgZG9jdW1lbnQuDQoNCigyKSBVbnVzZWQgKMKnNy4zKSBvciByZXNlcnZlZCAowqc3 LjUpIGRlZmluZWQgYXMgIlNIT1VMRCBiZSBzZXQgdG8gMC4uLk1VU1QgYmUgaWdub3JlZOKAnS4g IEFnYWluLCBpZiB1bnVzZWQvcmVzZXJ2ZWQsIEkgc2VlIG5vIHJlYXNvbiBub3QgdG8gY2hhbmdl IHRvIE1VU1QuICBJIHRoaW5rIFJvYiBtYWtlcyBhIGdvb2QgcG9pbnQgYWJvdXQgZXh0ZW5zaWJp bGl0eS4NCg0KDQpCZWZvcmUgYW55IGNoYW5nZXMsIGFuZCBpbiB0aGUgc3Bpcml0IG9mIG5vdCBi cmVha2luZyBhbnl0aGluZywgd2Ugc2hvdWxkIGNoZWNrIHdoZXRoZXIgYW55b25lIGhhcyBhbiBp bXBsZW1lbnRhdGlvbiB3aGF0IHdvdWxkIGJlIGltcGFjdGVkLiAgSSBhc3N1bWUvaG9wZSB0aGF0 IHRoZSBwcm90b3R5cGUgaW1wbGVtZW50YXRpb25zIGhhdmUgYWxyZWFkeSBiZWVuIGZpeGVkLg0K DQpKaWU6ICBBcyBTaGVwaGVyZCwgY2FuIHlvdSBwbGVhc2UgZG8gYSBxdWljayBwb2xsIG9mIHRo ZSBwZW9wbGUgd2hvIHJlcG9ydGVkIGltcGxlbWVudGF0aW9ucyB0byBjb25maXJtIHRoYXQgdGhl c2UgY2hhbmdlcyB3b27igJl0IGhhdmUgYW4gaW1wYWN0Pw0KDQoNClRoYW5rcyENCg0KQWx2YXJv Lg0KDQoNCg0KDQoNCg0KT24gQXByaWwgMjQsIDIwMjAgYXQgMTI6MjQ6MjggUE0sIFJvYiBXaWx0 b24gKHJ3aWx0b24pIChyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+ KSB3cm90ZToNCj4gWW91ciBxdWVzdGlvbiBpcyBhIGdvb2Qgb25lOg0KPiBCdXQgSSBkb24ndCB1 bmRlcnN0YW5kIHdoeSB0aGF0IG1lYW5zIHRoZQ0KPiBzZW5kZXIgaXMgYSAiU0hPVUxEIGJlIDAi IG5vdCBhICJNVVNUIGJlIDAiPw0KPg0KPiBUaGlzIHRleHQgaXMgaW5oZXJpdGVkIGZyb20gUkZD NTU3NS4NCj4NCj4gT3JpZ2luYWxseSAod2hpY2ggaXMgbm90IGluIGFueSBkb2N1bWVudCkNCj4g dGhpcyB3YXMgc2V0IGJlY2F1c2UgcHJvdG90eXBlIGltcGxlbWVudGF0aW9ucyBvZg0KPiBSRkM1 NTc1IGhhZCBzZXQgaXQgdG8gYSAxIGR1cmluZyBhIHJ1c2hlZCBkZXBsb3ltZW50Lg0KPg0KPiBX aGV0aGVyIHRoZXNlIGltcGxlbWVudGF0aW9uIHN0aWxsIGV4aXN0IGluIHRoZQ0KPiBzbWFsbGVy IGJveGVzIGJveGVzIGZyb20gbWFqb3IgdmVuZG9ycyAtIEkgZG8gbm90IGtub3cuDQo+DQo+IE9u ZSBvZiB0aGUgaGFiaXRzIG9mIElEUiBpcyBub3QgdG8gYnJlYWsgZXhpc3RpbmcgQkdQLg0KW1JX XQ0KWWVzLCBhbmQgSSBmdWxseSBzdXBwb3J0IHRoYXQgcHJhZ21hdGljIGFpbS4NCg== --_000_14293c9f9c2e41219a13f09adacb6289huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHls ZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp IGFsbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5BcyB5b3UgbWF5IGhhdmUgbm90aWNlZCwgZHVyaW5nIHRoZSBJ RVRGIHJldmlldyBvZiBkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLCB0aGVyZSB3YXMgc29tZSBk aXNjdXNzaW9uIGFib3V0IHRoZSBkZXNjcmlwdGlvbiBvZiBiaXQvZmxhZyBzZXR0aW5ncw0KIGlu IHRoaXMgZHJhZnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBpbiBJRVNH LCBvdXIgQUQgQWx2YXJvIHN1Z2dlc3RlZCB0byBtYWtlIGZvbGxvd2luZyBjaGFuZ2VzIHRvIHRo ZSBkcmFmdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4oMSkgQSBiaXQgaXMgZGVmaW5lZCBhcyAwLCBidXQgdGhlIGRlZmluaXRpb24g aXM6ICZxdW90OzAgLSAmbmJzcDtTSE9VTEQgYmUgc2V0IHRvIDDigKbigJ0gKMKnNC4yLjEuMSku Jm5ic3A7IElmIGl04oCZcyAwLCB0aGVuIEkgc2VlIG5vIHJlYXNvbiBmb3IgdGhhdCBub3QgdG8g YmUgYSBNVVNULiZuYnNwOyBJbiBmYWN0LA0KIGlmIGFsd2F5cyBzZXQgdG8gMCB3ZeKAmXJlIHBy b2JhYmx5IG92ZXIgc3BlY2lmeWluZyB0aGUgZmllbGQuICZuYnNwOyBUaGVyZSBhcmUgMyBvY2N1 cnJlbmNlcyBvZiB0aGlzIGluIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+KDIpIFVudXNlZCAowqc3LjMpIG9yIHJlc2VydmVkICjCpzcu NSkgZGVmaW5lZCBhcyAmcXVvdDtTSE9VTEQgYmUgc2V0IHRvIDAuLi5NVVNUIGJlIGlnbm9yZWTi gJ0uJm5ic3A7IEFnYWluLCBpZiB1bnVzZWQvcmVzZXJ2ZWQsIEkgc2VlIG5vIHJlYXNvbiBub3Qg dG8gY2hhbmdlIHRvIE1VU1QuJm5ic3A7IEkNCiB0aGluayBSb2IgbWFrZXMgYSBnb29kIHBvaW50 IGFib3V0IGV4dGVuc2liaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIHN1bW1hcnksIGl0IGlzIHN1Z2dl c3RlZCB0aGF0IGluIHRoZSBiaXQvZmxhZyBkZXNjcmlwdGlvbnMsIOKAnFNIT1VMRCBiZSBzZXQg dG8gMOKApuKAnSZuYnNwOyBpcyByZXBsYWNlZCB3aXRoIOKAnE1VU1QgYmUgc2V0IHRvIDDigKbi gJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkJlZm9yZSBtYWtpbmcgdGhvc2UgY2hhbmdlcywgd2XigJlkIGxpa2Ug dG8gcG9sbCB0aGUgaW1wbGVtZW50ZXJzIChlc3BlY2lhbGx5IHdobyByZXBvcnRlZCB0aGVpciBp bXBsZW1lbnRhdGlvbnMgdG8gSURSIGJlZm9yZSkgYWJvdXQgd2hldGhlciBzdWNoDQogY2hhbmdl cyBjYW4gaGF2ZSBhbiBpbXBhY3QgdG8geW91ciBpbXBsZW1lbnRhdGlvbi4gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoaXMgcG9sbCB3aWxsIGxhc3QgZm9yIG9uZSB3ZWVrIGFuZCBlbmQgb24gTWF5IDY8c3VwPnRo PC9zdXA+LiBMb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFja3MuIFRoYW5rcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbHZh cm8gUmV0YW5hIFs8YSBocmVmPSJtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbSI+bWFpbHRv OmFyZXRhbmEuaWV0ZkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5 LCBBcHJpbCAyNSwgMjAyMCAxOjAwIEFNPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJlcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs7 IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5j b20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs7IERvbmdqaWUgKEppbW15KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20iPmppZS5kb25nQGh1YXdlaS5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkci1jaGFpcnNAaWV0Zi5vcmciPmlk ci1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pZHItcmZj NTU3NWJpc0BpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzQGlldGYub3JnPC9h PjsgPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPjsgVGhlIElF U0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFJvYmVydCBXaWx0b24ncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtaWRyLXJmYzU1NzViaXMtMjM6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IaSE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+QXMgUm9iIG1lbnRpb25lZCwgd2UgdGFsa2VkIGFib3V0IGhpcyBE SVNDVVNTIGR1cmluZyB0b2RheeKAmXMgSUVTRyBUZWxlY2hhdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ V2XigJlyZSBhbGwgaW4gYWdyZWVtZW50IHRoYXQgdGhlIGxhc3QgdGhpbmcgd2Ugd2FudCB0byBk byBpcyB0byBicmVhayBhbnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLCBzcGVjaWFsbHkgYmVj YXVzZSB0aGlzIGRvY3VtZW50IGlzIGEgYmlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgbG9va2VkIGF0IHJmYzU1NzUsIGFuZCBJ IGRpZG7igJl0IGZpbmQgdGhlIHNhbWUgdGV4dCB0aGVyZSDigJQgSSBmb3VuZCBubyBzcGVjaWZp Y2F0aW9uIG9mIHRoZSBzZXR0aW5nIG9mIHRoZSBiaXRzLCBzcGVjaWFsbHkgdGhlIHJlc2VydmVk IG9uZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPltJIGFsc28gZGlkIGEgcXVpY2sgYW5kIHVuc2NpZW50 aWZpYyBzZWFyY2ggb2Ygb3RoZXIgcm91dGluZyBkb2N1bWVudHMgYW5kIGZvdW5kIGEgbWl4IG9m IFNIT1VMRC9NVVNUIGFuZCBNVVNUL01VU1QgY29uc3RydWN0c+KApl08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ob3RlIHRoYXQgdGhl cmUgYXJlIHR3byBkaXN0aW5jdCBjYXNlcyAoaW4gcmZjNTU3NWJpcyk6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPigxKSBBIGJpdCBpcyBkZWZpbmVkIGFzIDAsIGJ1dCB0aGUgZGVmaW5pdGlvbiBpczogJnF1 b3Q7MCAtICZuYnNwO1NIT1VMRCBiZSBzZXQgdG8gMOKApuKAnSAowqc0LjIuMS4xKS4mbmJzcDsg SWYgaXTigJlzIDAsIHRoZW4gSSBzZWUgbm8gcmVhc29uIGZvciB0aGF0IG5vdCB0byBiZSBhIE1V U1QuJm5ic3A7IEluIGZhY3QsDQogaWYgYWx3YXlzIHNldCB0byAwIHdl4oCZcmUgcHJvYmFibHkg b3ZlciBzcGVjaWZ5aW5nIHRoZSBmaWVsZC4gJm5ic3A7IFRoZXJlIGFyZSAzIG9jY3VycmVuY2Vz IG9mIHRoaXMgaW4gdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4oMikgVW51c2VkICjC pzcuMykgb3IgcmVzZXJ2ZWQgKMKnNy41KSBkZWZpbmVkIGFzICZxdW90O1NIT1VMRCBiZSBzZXQg dG8gMC4uLk1VU1QgYmUgaWdub3JlZOKAnS4mbmJzcDsgQWdhaW4sIGlmIHVudXNlZC9yZXNlcnZl ZCwgSSBzZWUgbm8gcmVhc29uIG5vdCB0byBjaGFuZ2UgdG8gTVVTVC4mbmJzcDsgSQ0KIHRoaW5r IFJvYiBtYWtlcyBhIGdvb2QgcG9pbnQgYWJvdXQgZXh0ZW5zaWJpbGl0eS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5CZWZvcmUgYW55 IGNoYW5nZXMsIGFuZCBpbiB0aGUgc3Bpcml0IG9mIG5vdCBicmVha2luZyBhbnl0aGluZywgd2Ug c2hvdWxkIGNoZWNrIHdoZXRoZXIgYW55b25lIGhhcyBhbiBpbXBsZW1lbnRhdGlvbiB3aGF0IHdv dWxkIGJlIGltcGFjdGVkLiZuYnNwOyBJIGFzc3VtZS9ob3BlIHRoYXQNCiB0aGUgcHJvdG90eXBl IGltcGxlbWVudGF0aW9ucyBoYXZlIGFscmVhZHkgYmVlbiBmaXhlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+SmllOiAmbmJzcDtBcyBTaGVwaGVyZCwgY2FuIHlvdSBwbGVhc2UgZG8gYSBxdWljayBwb2xs IG9mIHRoZSBwZW9wbGUgd2hvIHJlcG9ydGVkIGltcGxlbWVudGF0aW9ucyB0byBjb25maXJtIHRo YXQgdGhlc2UgY2hhbmdlcyB3b27igJl0IGhhdmUgYW4gaW1wYWN0PyAmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U aGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEFwcmlsIDI0LCAyMDIwIGF0IDEyOjI0OjI4IFBNLCBS b2IgV2lsdG9uIChyd2lsdG9uKSAoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJt YWlsdG86cndpbHRvbkBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5yd2lsdG9uQGNpc2Nv LmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KQ0K IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5k OndoaXRlIj4mZ3Q7IFlvdXIgcXVlc3Rpb24gaXMgYSBnb29kIG9uZTo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZndDsgQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhhdCBtZWFucyB0aGU8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4N CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mZ3Q7IHNlbmRlciBpcyBhICZxdW90O1NI T1VMRCBiZSAwJnF1b3Q7IG5vdCBhICZxdW90O01VU1QgYmUgMCZxdW90Oz88c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jmd0OyBUaGlzIHRleHQgaXMgaW5oZXJpdGVkIGZyb20gUkZDNTU3NS48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jmd0OyBPcmlnaW5hbGx5ICh3aGljaCBpcyBub3QgaW4gYW55IGRvY3VtZW50KTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJy Pg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZndDsgdGhpcyB3YXMgc2V0IGJlY2F1 c2UgcHJvdG90eXBlIGltcGxlbWVudGF0aW9ucyBvZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZndDsgUkZDNTU3NSBoYWQgc2V0IGl0IHRvIGEgMSBkdXJpbmcgYSBydXNoZWQg ZGVwbG95bWVudC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+DQo8 c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jmd0OyBXaGV0aGVyIHRoZXNlIGltcGxlbWVu dGF0aW9uIHN0aWxsIGV4aXN0IGluIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZndDsgc21hbGxlciBib3hlcyBib3hlcyBmcm9tIG1ham9yIHZlbmRvcnMgLSBJIGRvIG5v dCBrbm93LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZndDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mZ3Q7IE9uZSBvZiB0aGUgaGFiaXRzIG9mIElEUiBp cyBub3QgdG8gYnJlYWsgZXhpc3RpbmcgQkdQLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPltSV108c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5ZZXMsIGFuZCBJ IGZ1bGx5IHN1cHBvcnQgdGhhdCBwcmFnbWF0aWMgYWltLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_14293c9f9c2e41219a13f09adacb6289huaweicom_-- From nobody Tue Apr 28 23:20:07 2020 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 434CF3A09EC for ; Tue, 28 Apr 2020 23:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 jFmoEfCdVIq2 for ; Tue, 28 Apr 2020 23:20:02 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3953A09EA for ; Tue, 28 Apr 2020 23:20:02 -0700 (PDT) Received: from lhreml720-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7C87FE200375F7C9E397 for ; Wed, 29 Apr 2020 07:19:56 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Apr 2020 07:19:55 +0100 Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Apr 2020 14:19:53 +0800 Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1913.007; Wed, 29 Apr 2020 14:19:53 +0800 From: Zhuangshunwan To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt (4/28 to 5/14/2020) Thread-Index: AdYdcjsBv2nNt2GqQU+Noo20zKnovAAe17Qw Date: Wed, 29 Apr 2020 06:19:53 +0000 Message-ID: <69a0b74ed73e49bbbfa8b9d419c97487@huawei.com> References: <013301d61d74$010f9aa0$032ecfe0$@ndzh.com> In-Reply-To: <013301d61d74$010f9aa0$032ecfe0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.202.109] Content-Type: multipart/alternative; boundary="_000_69a0b74ed73e49bbbfa8b9d419c97487huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt (4/28 to 5/14/2020) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 06:20:05 -0000 --_000_69a0b74ed73e49bbbfa8b9d419c97487huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any related IPR in draft-ietf-idr-flowspec-l2vpn-14.txt. Thanks, Shunwan From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, April 28, 2020 11:45 PM To: idr@ietf.org Subject: [Idr] IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt (4/28 to 5= /14/2020) This is an IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt. The authors should send their IPR statement. The WG LC for this draft will begin as soon as all authors send in their IP= R statements. Cheerily, Susan Hares --_000_69a0b74ed73e49bbbfa8b9d419c97487huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I am not aware of any related IPR in draft-ietf-idr-flowspec-l2vp= n-14.txt.

 

Thanks,

Shunwan

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, April 28, 2020 11:45 PM
To: idr@ietf.org
Subject: [Idr] IPR call for draft-ietf-idr-flowspec-l2vpn-14.txt (4/= 28 to 5/14/2020)

 

This is an IPR call for draft-i= etf-idr-flowspec-l2vpn-14.txt.  

The authors  should send t= heir IPR statement. 

 

The WG LC for this draft will b= egin as soon as all authors send in their IPR statements.

 

Cheerily, Susan Hares

--_000_69a0b74ed73e49bbbfa8b9d419c97487huaweicom_-- From nobody Wed Apr 29 04:25:16 2020 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 5683F3A0CFC; Wed, 29 Apr 2020 04:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 qDw6mhrVTmcx; Wed, 29 Apr 2020 04:25:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30433A0CFB; Wed, 29 Apr 2020 04:25:12 -0700 (PDT) Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BF496E0A8B8A3C9E9A7E; Wed, 29 Apr 2020 12:25:08 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Apr 2020 12:25:08 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Apr 2020 19:25:05 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Wed, 29 Apr 2020 19:25:05 +0800 From: "Wanghaibo (Rainsword)" To: "draft-ietf-idr-segment-routing-te-policy@ietf.org" CC: "idr@ietf.org" Thread-Topic: [idr]Question about draft-ietf-idr-segment-routing-te-policy Thread-Index: AdYeFkePilL//aA+REm5vt4K/rNllA== Date: Wed, 29 Apr 2020 11:25:05 +0000 Message-ID: <644ead03d4ba41a4af378123cc735b23@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.202.142] Content-Type: multipart/alternative; boundary="_000_644ead03d4ba41a4af378123cc735b23huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] [idr]Question about draft-ietf-idr-segment-routing-te-policy X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 11:25:15 -0000 --_000_644ead03d4ba41a4af378123cc735b23huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, About the draft draft-ietf-idr-segment-routing-te-policy-08, Section 2.= 1. SR Policy SAFI and NLRI Before the draft 08 version, it says: o NLRI Length: 1 octet of length expressed in bits as defined in [RFC4760]. Now in draft 08 version, it says: o NLRI Length: 1 octet of length expressed in bits as defined in [RFC4760]. When AFI =3D 1 value= MUST be 12 and when AFI =3D 2 value MUST be 24. I think the last sentence is conflict with before. If we use bits for lengt= h, when AFI =3D 1 the value is 96 and when AFI =3D 2, the value is 192. And now some implementation already use the bits for length. So is this a clerical error or is it based on other considerations? Regards, Haibo --_000_644ead03d4ba41a4af378123cc735b23huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

  About the draft draft-ie= tf-idr-segment-routing-te-policy-08,  Section  2.1. SR Policy SAF= I and NLRI

 

Be= fore the draft 08 version, it says:

&n= bsp;  o  NLRI Length: 1 octet of length expressed in bits as defi= ned in

&n= bsp;     [RFC4760].

 

No= w in draft 08 version, it says:

&n= bsp;  o  NLRI Length: 1 octet of length expressed in bits as defi= ned in

&n= bsp;     [RFC4760].  When AFI = =3D 1 value MUST be 12 and when AFI =3D 2 value

&n= bsp;     MUST be 24.

 

I = think the last sentence is conflict with before. If we use bits for length,= when AFI =3D 1 the value is 96 and when AFI =3D 2, the value is 192.<= /o:p>

An= d now some implementation already use the bits for length.

 

  So is this a clerical er= ror or is it based on other considerations?  

 

Regards,

Haibo

--_000_644ead03d4ba41a4af378123cc735b23huaweicom_-- From nobody Wed Apr 29 09:28:46 2020 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 CA2F43A138B; Wed, 29 Apr 2020 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.589 X-Spam-Level: X-Spam-Status: No, score=-9.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 header.b=c/MTZbD4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=g9FWvYw3 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 FkKskMEPws1g; Wed, 29 Apr 2020 09:28:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752F03A00AE; Wed, 29 Apr 2020 09:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10105; q=dns/txt; s=iport; t=1588177719; x=1589387319; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ebHKrX3u9AFws96f4PgFFkZ6kQYd+uRWl3Pbh8avnHw=; b=c/MTZbD4CjcQLuiLtQhdsWZjO6Zw115+2lcf8METiZafEl62ntOl/JKe GD3kNSftWTq9qO+T6C0Dk/eOAQrUvuTSPLV0+xgViX8tM4uvcPigM4V5m uuy5rzOfjKPRlNw8EsxVrJ5YxKlvquwltdBXhHOqEURHez1kbviFqkebP M=; IronPort-PHdr: =?us-ascii?q?9a23=3AFCdjFhy/66eDFwnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWBt/VwhUDEXMPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMVVcB8v/IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBBqqle/4MNJK1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBR4ElL1EFblgvKgqHXQONQ5NPhGKCUgNUCwEBAQw?= =?us-ascii?q?BAR8OAgQBAYREAoItJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQMSGxM?= =?us-ascii?q?BATcBDwIBCBEEAQEvMh0IAQEEAQ0FCBqDBYF+TQMuAQ6oPgKBOYhhdIE0gwA?= =?us-ascii?q?BAQWFOhiCDgMGgTiCY4leGoFBP4ERQ4JNPoJnAQEDgWQrgxiCLZdUimSOIIF?= =?us-ascii?q?hCoJFiBOQEYJbmiyQBYFXh3STQgIEAgQFAg4BAQWBaSKBVnAVgyRQGA2KaId?= =?us-ascii?q?Tg3KFFIMZgil0NgIGCAEBAwl8kF4BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,332,1583193600"; d="scan'208,217";a="752142898" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2020 16:28:38 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03TGScIB012588 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2020 16:28:38 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Apr 2020 11:28:37 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Apr 2020 12:28:37 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Apr 2020 11:28:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fJkRxghXYlKjVsNXwbYzQioN7DSIArjmEJzVf/2RGssx+AXBwUziNyEgrNCGgpcFp2P0Y9FUsShB4sI0YrYhGBeP/RflkQH2zQ1Xo6r/3mBKVuJg6GkiB1mKvb0uypsNjGvy9vmMOBxDwxFzf3cINJ4S6Hf6rZMt7V6zfIWRbBjTCnq9TwoySqLUp4725tfxnYCdTnmA39O0BSd9t2dWMRB23vTS7mw/1QbODL8UzrF/2tsHCXMKIip5f4DduRPuDK6ahshExhSUyeEbak3iptzT9cY2l2RHL27bieGs/pVSR1O3uD1O1A97y54+5jnfr8oa2uiRIxPAmvlCnF4tTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRYLRz53bOUJyQiZTZ6fg//oikiMq1wd7sv8mke/kMU=; b=SncwyxvSE1wqGir4mlZhc3e/bP2Fsx3QdkrtKrEGDO6L7vsRzLe6bY7xr25oLV934nn+g5e1MjZUJaAVZflyivIzzilooSgqie7UsTYSLhMB0tCTFQqicgFU5iKttC47eNLU5s6Y+1uQ/xzA64c2P9nJt/8vQzlp9E5jmJPqXn9ZSCCi/jPMERtYFA5Ip7AebflwJzRcw2yQg13ws4JD+Q1RPGaa0AMqAa3QiUuFHGhrld1XdB81rmFRpDc7VvTMqF8WTU5UmEQ5VNay9aeDIO44xgxVcGQqROYD6/KJF7V8s1fqmiwPcTFjM/rrgSSkYQ6TgetcAPm4yoSy+EcuCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRYLRz53bOUJyQiZTZ6fg//oikiMq1wd7sv8mke/kMU=; b=g9FWvYw3VAhRXV7ULkfltLgUtqYD6Zg1VV+YyJZk8K46RUq3oF0pxyBA/hAvO6SpQnmcgzshONBarHsMovQfPGud9ZPXV6MmiP17coacCuq7hr9UAtQFakRgeKP075wtOxQq9VzrWdbqK6kfrqbfxJEra4HfenvtmrCtYnu3w7M= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4538.namprd11.prod.outlook.com (2603:10b6:303:57::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Wed, 29 Apr 2020 16:28:36 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%6]) with mapi id 15.20.2937.023; Wed, 29 Apr 2020 16:28:35 +0000 From: "Ketan Talaulikar (ketant)" To: "Wanghaibo (Rainsword)" , "draft-ietf-idr-segment-routing-te-policy@ietf.org" CC: "idr@ietf.org" Thread-Topic: [idr]Question about draft-ietf-idr-segment-routing-te-policy Thread-Index: AdYeFkePilL//aA+REm5vt4K/rNllAALLmtw Date: Wed, 29 Apr 2020 16:28:35 +0000 Message-ID: References: <644ead03d4ba41a4af378123cc735b23@huawei.com> In-Reply-To: <644ead03d4ba41a4af378123cc735b23@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: abc3da38-2682-49f4-c4c3-08d7ec5a5da8 x-ms-traffictypediagnostic: MW3PR11MB4538: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03883BD916 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5x350u7mBljv3uUoYjHHMcq+AD7wBtsMbicTuHJHCFukSCNYt0sIVWyUUByc+hO0baSP4BzmNbd4x/V/9BFr0GPD6s1sevxZhxptJBptOye/5amLiU91yUerd/KaWYbi7GZ71DRbfsiFRW/xWpE0pNN2jtgFB0gZWhY17L7qeZt20ZyDQE0JQv0GSo+4p3Sk5qj22g96DT3pw57FLkF4bncuEP1eGMOEjqmk6m3TqvZGUYByn1HhsqMsntAGqAH38tizW2MtwUYl3nlak0tg8VFy6Ic/T1ZsgRbeeJXo7qwUIwtH6bEMJueH497qnwo9lcpL6NaiToKisfuTuf5cfbpAnH8raUSKZeADqJ4w7hzFDzpKgOH+pyF6/Q8praHrmAFnBipPBdGqWPFj3gcHOm9HNDmbeh5P44ctxY2QqfhgE1mVsBKDePQMWI/4uU6TcFqgbzwz3ebLL9xQTusChVYFNH/5s9t8uYD14dCzcpQE4IhhQnfNxL1uZzTIH+A+o26NFInwEqNJSIAi0uJ2YA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(346002)(39860400002)(376002)(5660300002)(71200400001)(86362001)(76116006)(66476007)(64756008)(66556008)(66946007)(66446008)(53546011)(6506007)(186003)(26005)(2906002)(478600001)(7696005)(110136005)(8936002)(8676002)(316002)(33656002)(52536014)(9326002)(9686003)(4326008)(4743002)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: gcK/YNqtH7Ckq/FZu6YmB0ABnNVwnOvDfpkQPa4TCzqB/yeYXZAeXdxXW00S/FfISy+jRxXNjsIk0EJDYauy7pGIVp1iP7HJpZFqNObSGfNHqYwhicc+3eZSRXbZa2fhhPOnS2LV5aQxzNQo7ygv5eEL3AtJqHE9exEAfiHDDODtocVm3Axv4YSijMN67WD2zpTvzVR4yIS4WfccQES369S5j/qo5JWGMTiMd5ZqcybJMyG9DgszqGAKxInzjg0RhwqHLoTDLsCDF3mELldWgBLXK8FJyC4wL6YHp2PmxNf8CrdGsZ1GOXpTTZ/570tON8vcIqoeVarQkNpE9bbTcwfBkydUAs+g3raD2OQO/fm3TDwAbAimLuFPdoDvvo9X5BNj4fOf5u9I9ruTmoapKSDh8qdvbfCzWIU9N+cwcAn0vvsSTpinHI0RNPVYbSmkuOHmijFw25nu7TzO2on/JS9wCJeTnuKcDmV3vy8wxKdtSg4s4OqOnaPTT/uFmFMlLlQRlSDM2Ghbu/loUr2VF047u0A5CjBlMw5nBzIWmuk5f/5/pcDrSv37nHIE/HJiuWBH4eTNsTGcW7BGyYvclG3QST7CTYRmQq9D8RO9StGq3oTtHq/9lFv0mEf+lEMcW8kQ8gN/UPvWaKbxTPThy8nyZGkeyPSwy2lhqDQxlQJU81fjlL3VKFZD9yX0Uj6S2iFXI9uAc2A328IL6q0Rm8r/dULIBrt49mzXjOQlxRZ71OwiHiM56t4b4muVOa3jEaH4cJkAR6QJeSLvTJdAK55aT7+iSbAXX1bEyuMnRTo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570DAA1871F2417087446A3C1AD0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: abc3da38-2682-49f4-c4c3-08d7ec5a5da8 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2020 16:28:35.7055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lfJV3Dj72Ha8Z19uod0TCCktw77bCJqXPpkPIn5XSFZ7YANhC0ADCAHXR+JofnqmzzS+mWLdWheIkQU/LJhNng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4538 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Idr] [idr]Question about draft-ietf-idr-segment-routing-te-policy X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 16:28:42 -0000 --_000_MW3PR11MB4570DAA1871F2417087446A3C1AD0MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haibo, Thanks for catching this error. Since the value is in bits, it should be 96= and 192 respectively as you mentioned. Will fix this in the next/upcoming draft update. Thanks, Ketan From: Wanghaibo (Rainsword) Sent: 29 April 2020 16:55 To: draft-ietf-idr-segment-routing-te-policy@ietf.org Cc: idr@ietf.org Subject: [idr]Question about draft-ietf-idr-segment-routing-te-policy Hi Authors, About the draft draft-ietf-idr-segment-routing-te-policy-08, Section 2.= 1. SR Policy SAFI and NLRI Before the draft 08 version, it says: o NLRI Length: 1 octet of length expressed in bits as defined in [RFC4760]. Now in draft 08 version, it says: o NLRI Length: 1 octet of length expressed in bits as defined in [RFC4760]. When AFI =3D 1 value= MUST be 12 and when AFI =3D 2 value MUST be 24. I think the last sentence is conflict with before. If we use bits for lengt= h, when AFI =3D 1 the value is 96 and when AFI =3D 2, the value is 192. And now some implementation already use the bits for length. So is this a clerical error or is it based on other considerations? Regards, Haibo --_000_MW3PR11MB4570DAA1871F2417087446A3C1AD0MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Haibo,

 

Thanks for catching this error. Since the value is in bits, it shou= ld be 96 and 192 respectively as you mentioned.

 

Will fix this in the next/upcoming draft update.<= /p>

 

Thanks,

Ketan

 

From: Wanghaibo (Rainsword) <rainsword.wang@huaw= ei.com>
Sent: 29 April 2020 16:55
To: draft-ietf-idr-segment-routing-te-policy@ietf.org
Cc: idr@ietf.org
Subject: [idr]Question about draft-ietf-idr-segment-routing-te-polic= y

 =

Hi Authors,

 

  About the draft draft-ietf-idr-segment-routing-te-policy-08,&n= bsp; Section  2.1. SR Policy SAFI and NLRI

 

Before the draft 08 version, it says:

   o  NLRI Length: 1 octe= t of length expressed in bits as defined in

      [RFC4760]= .

 

Now in draft 08 version, it says:

   o  NLRI Length: 1 octe= t of length expressed in bits as defined in

      [RFC4760].  When AFI =3D 1 value MUST be 12 and when AFI =3D 2 value=

      MUST be 2= 4.

 

I think the last sentence is conflict wi= th before. If we use bits for length, when AFI =3D 1 the value is 96 and wh= en AFI =3D 2, the value is 192.

And now some implementation already use = the bits for length.

 

  So is this a clerical error or is it based on other considerat= ions?  

 

Regards,

Haibo

--_000_MW3PR11MB4570DAA1871F2417087446A3C1AD0MW3PR11MB4570namp_-- From nobody Wed Apr 29 16:06:06 2020 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 20DBE3A0A8B; Wed, 29 Apr 2020 16:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 VwAUROw7GZV1; Wed, 29 Apr 2020 16:05:05 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2122.outbound.protection.outlook.com [40.107.89.122]) (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 55A283A0A89; Wed, 29 Apr 2020 16:05:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C1hcRLiqSlkv8F37F/xCNuqeU3hPMWe5VaH66BjhUr34rylJtvzAKk96b5m5HuicdaURm7JX1L9XWTBQVPZb0LQGbERUHb52fFeH2N42msV5mZEeuWQgHhDk6Lj/EmXpsbLgdJOZk6kzGGywQBApElSn66XPKtunUJZ+Qy4FsovZ68zZk5PD04Gmt7z14LW03EluSRs5eGL1lOlIWfzMd/u702/ljZarFM04VP2DRkYpdSQkJtp9UFtN8KDDlvjP17q902YuEFF1YqXIcBcY21JPKWGLhHZ8OMAesJ3TVnwUWqfFUEANEJlwYhY4qBF15FEaLeFOSpPpY3vRn2it/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5TW6SgyVNCG8WQcqbaWtwJGRamletrazKurqY3eX5sY=; b=DgbLlGiqf+MpaudO4d/b3Y+QtRRtnSCFNAPulAjT8FQufEAgp/CdaXKRvzsW+IvnttHw6iIW3rYPVKhyHHFlLuJ7IUH8guMoiIpGotVl1I/dyJnLMbJxySNjS7ptGxZ1+S4WcO8tQ4O9fv/d4eSZWIsUgijAdxBvI0EhgaddOpfPPTN3ueoHKiM4ADF3sQyijyyf5fNA8URnD+zr6mIlhbK1bZG1NAc2A8edUJEWytIKL04F6ZBi2c3MUbc3+PJ3qnFyMzu+42my31KoIuMjc6S1thHfsXFHnO0SOzlvD5dvSPXtXDgZOXrrRaIEgOicAto6LWDiFU0o8ucy8WMhew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5TW6SgyVNCG8WQcqbaWtwJGRamletrazKurqY3eX5sY=; b=nxJWzOk/EckpXp8IbKIio+ZZ3dsFHGyUzZiq39x2FnuI7J5BbXFe9BfhTWCHNvCyZCqm2FJPGCvHgxhuSB0ouMAugvM+v4KVPM7rfL1KuH81DYXd0l2zxpedapfYmYWhinL7D/+WYzg/SptVSf+XATBGS+NG87H6/VSqnuEs+Rk= Received: from BY5PR09MB5665.namprd09.prod.outlook.com (2603:10b6:a03:241::11) by BY5PR09MB4980.namprd09.prod.outlook.com (2603:10b6:a03:252::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Wed, 29 Apr 2020 23:05:00 +0000 Received: from BY5PR09MB5665.namprd09.prod.outlook.com ([fe80::6120:933:ad7c:3829]) by BY5PR09MB5665.namprd09.prod.outlook.com ([fe80::6120:933:ad7c:3829%7]) with mapi id 15.20.2958.020; Wed, 29 Apr 2020 23:04:59 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Colin Petrie , Nick Hilliard CC: "idr@ietf.org" , GROW WG , "Hannachi, Lilia (IntlAssoc)" , "draft-heitz-idr-wklc@ietf.org" Thread-Topic: [GROW] Measurements on Regular, Extended, and Large Communities Thread-Index: AQHWGe3MXOXky3BBr0yxtCqjBaxXEqiIN71NgAATA4CABQilgIADEpE9 Date: Wed, 29 Apr 2020 23:04:58 +0000 Message-ID: References: , <60e115b3-607d-f3c6-8ced-8db5fafea39e@spakka.net> In-Reply-To: <60e115b3-607d-f3c6-8ced-8db5fafea39e@spakka.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spakka.net; dkim=none (message not signed) header.d=none;spakka.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.197.83] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: aafa6b42-bc0c-4d00-7ea1-08d7ec91be05 x-ms-traffictypediagnostic: BY5PR09MB4980:|BY5PR09MB4980: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03883BD916 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nspLgtbs1bQPOJ+eU6VVCT0P4JjE1NNPJ/aEjAr/QS8wLMEDf10cnfMF3Xmrgw93EtuCtjhBe0rYVsujVM1Fd+wGpnc+qJnLmddup/EBa2/1TD68tEZfpeChAjX1sxFUaEX4pVIeN8SizRZ3h/CgpHGkwNsQkQONtlYDdlyglwaOgTcmJn+RwfyzZzppPWZEsmW4o1fLDZV6lWUlKxObrpylap+LIL99uVYr74ZAoDA25AUuOnLYks9pdPkVOzjyVUoCVflBZWswdkTfFsyHn6r9a4oRk/yF21BIVZlwsTSsP7ASI5pmCcmWMt507Z/joRA2aGW7Xvf49OfEs8xnNE89fwyq1VUNnpLa8x5EuGc/qFaYcPRnZR2OLJRVOhVoXqiEDwnQfKPq/BP/1Ji+5Ck8T8YZck/saRRqdUyiG36SnkiarqkeqYubcO1Oeou9 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR09MB5665.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(39860400002)(366004)(346002)(376002)(52536014)(91956017)(64756008)(66946007)(66556008)(76116006)(54906003)(316002)(5660300002)(66446008)(66476007)(110136005)(186003)(26005)(8936002)(478600001)(8676002)(86362001)(2906002)(7696005)(33656002)(4326008)(71200400001)(9686003)(55016002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CYTL4ntmms1eqJrd9PO1EY+eNIhCwCfgeS+2QiR8PGzqwkAr+XhPVfrZ9Slezehuno9i5+zUBTjioPTcyhZ7IHSgWRwAEtq56Pac7qimjdaC6JNwvBztxiF0LsryvOWRSBVYEFYZC+J1N25Jny0S7/1al3MsvIvVnNJaFz4SMgGtZgsSpnye4zewWa6Ay5xtwcB9P+ymIgvrhFlJz0m8eXx5Tq6WFJjH/ti46CoU2q0mgn1upvhOSlq2GvjyewmL6xJArmgex/7nakNeE/OKCB+yy2FMunD3i4MqMi8PdnmzANmz5s56HNJNvF11Ht3Gnwptaij5eV52hOsKrsTo0axOggPrpiJkH9OfqCBC+IiuBKC3J68QzwtXAkfLdu9r/wXaWSAeRmHfK5NSC+EmhNDCTn7YHh5wlxWLNB5D1Lw7fu+e0QKt32ZcwB2MhpYFVgoQB1KzhjoF5O7eVaVFbmC1ZA+jKunzw4MxpFReZtzbThhdLym0Vz9ue+uzynJa2p2C9l1yy+2qWDKUvLU3IF5AnMjP0E8UfIa9CndicQHMgdTuxKgDnm2tpqQdSMyj9AV6prhRwLBHd8a+6zTmZ6hEleMY4j1dd/m/7za8BwD2YwMYnS/ZbTg9vHh95Obi6NpsNXH19u6IszJhim3bl1cTLzwo6BQwmNOUpOnEflFw53zHXHH0ownweL1B4xXdtVopfoRw24pe+RxbEHoCXAqK9SqiCuqjFbEQA1auSM3cywAhMQKo1YrAP/xxVxvwlecjqFIB0YRaRddi+I4xZx6DUBLpCR5BeE1BLIf08m8= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: aafa6b42-bc0c-4d00-7ea1-08d7ec91be05 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2020 23:04:59.6687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Epe7WKh22XMG68x/8t9/QBkZps+xUhKFVp4HQmcafwrIBPp2EpSxAYOh6D0WiP8NBrnKk5k1P+/ijUh5WTZ8Iw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB4980 Archived-At: Subject: Re: [Idr] [GROW] Measurements on Regular, Extended, and Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 23:05:17 -0000 Thanks Nick and Colin. Insights you shared are helpful.=0A= =0A= Colin:=0A= =0A= >If you are analysing Route-Views table dumps (and not updates) then you=0A= >won't see ECs because Quagga/FRR only dumps selected attributes into the= =0A= >MRT files [0]. ECs are not on the list of dumped attributes. LCs were=0A= >added to the list as part of the LC implementation patch.=0A= =0A= Our analysis sees LCs in both Quagga and FRR RouteViews collectors in RIBs = and Updates.=0A= We don't see ECs at all in any of these cases.=0A= Some Quagga collectors show LCs in RIB (e.g., route-views3) and others don'= t (e.g., route-views2).=0A= =0A= >RIPE's RIS implementation records all the received attributes opaquely=0A= >so you will see ECs in there. They are also present within the=0A= >route-views updates files (as these are dumped raw by Quagga).=0A= =0A= Our measurements show LCs in RIPE-RIS but no ECs. =0A= Yep, we don't see ECs (in RIBs or Updates) in RIPE-RIS or Routeviews.=0A= May be Nick is right about lack of compelling reason to use EC.=0A= Examples (RIPE-RIS):=0A= *********************************************************************=0A= Community ANALYSIS (Collector : rrc00 2020-04-25:02)=0A= *********************************************************************=0A= # Updates =3D 366516 (Total)=0A= # COMMUNITY =3D 293050 (79%)=0A= AS path length distribution =3D 2: 1480 (0%) 3: 7177 (2%) 4: 20212= (6%) 5: 23894 (8%) 6: 17841 (6%) 7: 8023 (2%) 8: 2317 (0%) = 9: 539 (0%) 10: 197 (0%) 11: 150 (0%) 12: 102 (0%) 13: 32 (0%) = 14: 12 (0%)=0A= # LARGE_COMMUNITY =3D 222778 (60%)=0A= AS path length distribution =3D 2: 534 (0%) 3: 5066 (2%) 4: 18288 = (8%) 5: 75891 (34%) 6: 76389 (34%) 7: 33773 (15%) 8: 9108 (4%) = 9: 2151 (0%) 10: 833 (0%) 11: 247 (0%) 12: 232 (0%) 13: 54 (= 0%) 14: 6 (0%) 16: 1 (0%)=0A= # EXTENDED COMMUNITIES =3D 0 (0%)=0A= =0A= *********************************************************************=0A= Community ANALYSIS (Collector : rrc15 2020-04-25:02)=0A= *********************************************************************=0A= # Updates =3D 115386 (Total)=0A= # COMMUNITY =3D 92189 (79%)=0A= AS path length distribution =3D 1: 67 (0%) 2: 5996 (6%) 3: 23925 (= 25%) 4: 26179 (28%) 5: 16973 (18%) 6: 10503 (11%) 7: 4418 (4%) = 8: 1153 (1%) 9: 305 (0%) 10: 79 (0%) 11: 55 (0%) 12: 38 (0%)= 13: 19 (0%) 14: 6 (0%)=0A= # LARGE_COMMUNITY =3D 2555 (2%)=0A= AS path length distribution =3D 2: 89 (3%) 3: 1312 (51%) 4: 609 (2= 3%) 5: 429 (16%) 6: 104 (4%) 7: 9 (0%) 8: 3 (0%)=0A= # EXTENDED COMMUNITIES =3D 0 (0%)=0A= =0A= Sriram= From nobody Wed Apr 29 18:41:06 2020 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 4A35B3A0C75 for ; Wed, 29 Apr 2020 18:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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 cH20UP6R2pjT for ; Wed, 29 Apr 2020 18:41:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27FE3A0C74 for ; Wed, 29 Apr 2020 18:41:00 -0700 (PDT) Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 87E062410E6ED0118411 for ; Thu, 30 Apr 2020 02:40:58 +0100 (IST) Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 30 Apr 2020 02:40:58 +0100 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 30 Apr 2020 02:40:57 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.203]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0487.000; Thu, 30 Apr 2020 09:40:55 +0800 From: "Chengli (Cheng Li)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 Thread-Index: AdYcqS9OUz9dKgHYTcabF1VCt18RHQAne0KQ//+stQD//Ro/cA== Date: Thu, 30 Apr 2020 01:40:55 +0000 Message-ID: References: <005201d61ca9$71152430$533f6c90$@ndzh.com> <00a801d61d60$85ed36b0$91c7a410$@ndzh.com> In-Reply-To: <00a801d61d60$85ed36b0$91c7a410$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029FAC69dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 01:41:04 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB029FAC69dggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Susan, Will do! Best regards, Cheng From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, April 28, 2020 9:26 PM To: Chengli (Cheng Li) ; idr@ietf.org Subject: RE: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 Cheng: Please send a note to the list when you address the issues from Ketan, Aiju= n and Linda. Thanks, Susan Hares From: Chengli (Cheng Li) [mailto:chengli13@huawei.com] Sent: Tuesday, April 28, 2020 6:27 AM To: Susan Hares; idr@ietf.org Subject: RE: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 Hi Susan, Thank you for your notification. Already uploaded the text. Also, we updated the error handling rules to align with the rules defined i= n draft-ietf-idr-segment-routing-te-policy. Also, added text of Implementat= ion status. Will address the comments from Ketan and Aijun and Linda ASAP. Many thanks! Best Regards, Cheng A new version of I-D, draft-ietf-idr-sr-policy-path-mtu-01.txt has been successfully submitted by Cheng Li and posted to the IETF reposito= ry. Name: draft-ietf-idr-sr-policy-path-mtu Revision: 01 Title: Segment Routing Path MTU in BGP Document date: 2020-04-28 Group: idr Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-sr-poli= cy-path-mtu-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-p= ath-mtu/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-m= tu-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-pol= icy-path-mtu Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sr-polic= y-path-mtu-01 Abstract: Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. This document defines extensions to BGP to distribute path MTU information within SR policies. 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 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 27, 2020 11:35 PM To: idr@ietf.org Subject: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13 The comment period on the adoption of draft-li-idr-sr-policy-path-mtu-03.tx= t has completed. The IDR WG has reached consensus to adopt this draft. The authors should submit this draft as draft-ietf-idr-sr-policy-path-mtu-0= 0.txt. Cheerily, Susan Hares --_000_C7C2E1C43D652C4E9E49FE7517C236CB029FAC69dggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Susan,

 

Will do!

 

Best regards,

Cheng

 

 

From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, April 28, 2020 9:26 PM
To: Chengli (Cheng Li) <chengli13@huawei.com>; idr@ietf.org Subject: RE: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to = 4/13

 

Cheng:

 

Please send a note to = the list when you address the issues from Ketan, Aijun and Linda.

 

Thanks, Susan Hares

 

From: Chengli (Cheng Li) [mailto:chengli13@huawei.com]
Sent: Tuesday, April 28, 2020 6:27 AM
To: Susan Hares; idr@ietf.org Subject: RE: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to = 4/13

 

Hi Susan,

 

Thank you for your not= ification. Already uploaded the text.

 

Also, we updated the e= rror handling rules to align with the rules defined in draft-ietf-idr-segme= nt-routing-te-policy. Also, added text of Implementation status.=

 

Will address the comme= nts from Ketan and Aijun and Linda ASAP. Many thanks!

 

Best Regards,

Cheng

 

 

 

A new version of I-D, draft-ietf-idr-sr-policy-pa= th-mtu-01.txt

has been successfully submitted by Cheng Li and p= osted to the IETF repository.

 

Name:       &n= bsp;          draft-ietf-idr-s= r-policy-path-mtu

Revision:      &nbs= p;       01

Title:       &= nbsp;           &nbs= p;  Segment Routing Path MTU in BGP

Document date:      = ;         2020-04-28

Group:       &= nbsp;          idr<= /p>

Pages:       &= nbsp;           9

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-ietf-idr-sr-policy-path-mtu-01.t= xt

Status:       =   https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-path-mtu/

Htmlized:       https://tools.ietf.org/html/draft-ietf-idr-sr-policy-path-mtu-01

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-mtu=

Diff:       &n= bsp;   https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sr-policy-path-mtu-01

 

Abstract:

   Segment Routing is a source routing = paradigm that explicitly

   indicates the forwarding path for pa= ckets at the ingress node.  An SR

   policy is a set of candidate SR path= s consisting of one or more

   segment lists with necessary path at= tributes.  However, the path

   maximum transmission unit (MTU) info= rmation for SR path is not

   available in the SR policy since the= SR does not require signaling.

   This document defines extensions to = BGP to distribute path MTU

   information within SR policies.=

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

 

 

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

 

The IETF Secretariat

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, April 27, 2020 11:35 PM
To: idr@ietf.org
Subject: [Idr] draft-li-idr-sr-policy-path-mtu-03.txt - 3/30 to 4/13=

 

The comment period on the adoption of draft-li-idr-s= r-policy-path-mtu-03.txt has completed.

The IDR WG has reached consensus to adopt this draft= .

 

The authors should submit this draft as draft-ietf-i= dr-sr-policy-path-mtu-00.txt.

 

Cheerily, Susan Hares

 

 

--_000_C7C2E1C43D652C4E9E49FE7517C236CB029FAC69dggeml529mbxchi_-- From nobody Wed Apr 29 19:41:17 2020 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 56B543A0DD5; Wed, 29 Apr 2020 19:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12qdqxV0BR_4; Wed, 29 Apr 2020 19:41:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9C53A0DCA; Wed, 29 Apr 2020 19:41:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C254C1E2D6; Wed, 29 Apr 2020 22:48:17 -0400 (EDT) Date: Wed, 29 Apr 2020 22:48:17 -0400 From: Jeffrey Haas To: "Dongjie (Jimmy)" Cc: "Kirill.Kasavchenko@netscout.com" , "thomas.mangin@exa.net.uk" , "jhaas@juniper.net" , "bduvivie@cisco.com" , IDR List , "idr-chairs@ietf.org" Message-ID: <20200430024817.GE28692@pfrc.org> References: <14293c9f9c2e41219a13f09adacb6289@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14293c9f9c2e41219a13f09adacb6289@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 02:41:15 -0000 Jie, On Wed, Apr 29, 2020 at 02:52:30AM +0000, Dongjie (Jimmy) wrote: > Hi all, > > As you may have noticed, during the IETF review of draft-ietf-idr-rfc5575bis, there was some discussion about the description of bit/flag settings in this draft. > > Based on the discussion in IESG, our AD Alvaro suggested to make following changes to the draft: > > (1) A bit is defined as 0, but the definition is: "0 - SHOULD be set to 0…†(§4.2.1.1). If it’s 0, then I see no reason for that not to be a MUST. In fact, if always set to 0 we’re probably over specifying the field. There are 3 occurrences of this in the document. > > (2) Unused (§7.3) or reserved (§7.5) defined as "SHOULD be set to 0...MUST be ignoredâ€. Again, if unused/reserved, I see no reason not to change to MUST. I think Rob makes a good point about extensibility. > > In summary, it is suggested that in the bit/flag descriptions, “SHOULD be set to 0…†is replaced with “MUST be set to 0…â€. The pattern we normally want to see is "MUST be set to zero and SHOULD be ignored on receipt". By requiring it to be set, you have expectations for a compliant implementation of a given draft. By ignoring it on receipt, you permit the field to be used for something further in the future. The above is consistent with Postel's Maxim. With regard to Juniper's implementation: - In sections 4.2.1.1 and 4.2.1.2 for operators, we originate zeroes when generating new NLRI in the reserved bits and we ignore them on receipt. However, we also propagate what we are sent and use when we're not the originator of that NLRI. - In section 7.3 (traffic action), we similarly originate only the two bits in question and zero the rest of the fields if we set the community, but otherwise ignore the rest of the bits on receipt. - In section 7.5 (DSCP), we originate zero and ignore the top order bit and any other bits that should be zero. However, there are related things you're not asking: - If we receive two NLRI that are otherwise functionally equivalent but have the must-be-zero bits set differently, they are different NLRI per the memcmp rule. - The BGP extended communities suffer the common curse of all "magic" communities: More than one such extended community is present, we will pick the "first" one for use, where first is the internal lexicographical ordering of the collection of extended communities (again, roughly memcmp order). We will also propagate all such received communities. -- Jeff From nobody Wed Apr 29 20:03:03 2020 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 1DBC63A0E26 for ; Wed, 29 Apr 2020 20:03:01 -0700 (PDT) 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 oehUuFLtehcC for ; Wed, 29 Apr 2020 20:02:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DC2A43A0CDE for ; Wed, 29 Apr 2020 20:02:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6565D1E2D6; Wed, 29 Apr 2020 23:10:04 -0400 (EDT) Date: Wed, 29 Apr 2020 23:10:04 -0400 From: Jeffrey Haas To: Susan Hares Cc: idr@ietf.org Message-ID: <20200430031003.GF28692@pfrc.org> References: <016101d61a45$1d7e2440$587a6cc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016101d61a45$1d7e2440$587a6cc0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-flowspec-oid-11 - has past WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 03:03:01 -0000 Sue, On Fri, Apr 24, 2020 at 10:31:59AM -0400, Susan Hares wrote: > Greetings: > > draft-ietf-idr-bgp-flowspec-oid-11.txt has past WG last call. > > The shepherd would appreciate the co-authors providing implementation > reports on the IDR wiki at: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implem > entations Once the wiki is populated, Juniper will provide an implementation report. We are conformant to the draft. -- Jeff From nobody Thu Apr 30 01:09:57 2020 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 005C73A0B0B for ; Thu, 30 Apr 2020 01:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=HE5qwGT3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hio7USZ3 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 EZMMRNLr7PTT for ; Thu, 30 Apr 2020 01:09:52 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89F93A0B07 for ; Thu, 30 Apr 2020 01:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27510; q=dns/txt; s=iport; t=1588234191; x=1589443791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oIRWF16pxHuJ+bOcYMN+8vS6uv2UNprONAVSaC3YVgQ=; b=HE5qwGT3zTuH1wQUxlENMu7jhuJofNQZD7kVueuGD5ieMhDaWBaKm7f5 khz2EKKrI6eytKjuOi4ZzhcNbqiy8yD1ssmyDM+PvbI1KsLNETOU4UCY0 Ly3+ROLKHHHbLfEvcmpsBPD7L3p/32DixnHpyddY1TBhJE9aS+bagdqQa c=; IronPort-PHdr: =?us-ascii?q?9a23=3AKuPbShQVetvTdL0kSxYRFD8RNtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB?= =?us-ascii?q?65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AAAAh6pe/5ldJa1cChsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQGBdgMBAQELAYEkLyQtBW5YLyoKhBeDRgONQol2jju?= =?us-ascii?q?BQoEQA1QLAQEBDAEBGAEMCAIEAQGDf0UCF4IYJDcGDgIDAQELAQEFAQEBAgE?= =?us-ascii?q?FBG2FVgyFcQEBAQEDAQEQEQoTAQEsCwELBAIBCBEEAQEoAwICAh8GCxQJCAI?= =?us-ascii?q?EAQ0FCA0NgwWBfk0DLgEOp3cCgTmIYXaBMoMAAQEFhSwNC4IOAwaBOAGCYoJ?= =?us-ascii?q?HDocJGoFBP4ERQ4JNPoIeSQEBAgGBLQEHBQYBIwUHCRYJglwzgi2ORCmCUoY?= =?us-ascii?q?VJJlFMkoKgkWHH3SLLIRlgluIW5FRkAWBV4d0gkWQfQIEAgQFAg4BAQWBaCN?= =?us-ascii?q?mcHAVO4JpUBgNimiHUwkaFYM6hRSFQnQCATMCBgEHAQEDCXyPKoE0AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,334,1583193600"; d="scan'208,217";a="471043727" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2020 08:09:50 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03U89oMB028535 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2020 08:09:50 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Apr 2020 03:09:50 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Apr 2020 04:09:48 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 30 Apr 2020 03:09:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DrMEWXDSy6J3cknLYTHX4UfNFVpPhPKGPdSiD0OmPbVBcEu/D5nvMrnjzaz596aLdyloKZbRcp1gWnpmcbM9uYO/U0or1Xf85wTIGW91NfMJxlfukQ7u+QeunGWt92qG3D4Ff6Ftxr7DvAU8sPJDoxQwQKCmnnDRtuPT796wn3Qvp1BAGgZ2chi/WwW1ZGyXGyOCREC70qwLmZXNp4Zdyuf9dxPdhRabkndRvHOgLsiUbPcVq7hx83OoJBHH6GkEStt6Kad85nawMwdMBif0uw85Fl+WjbhIZnm/s23BRVaO1v24p42ex17v0vaTZUs7/N6rbMBNu5KgxQW/Xov5Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oIRWF16pxHuJ+bOcYMN+8vS6uv2UNprONAVSaC3YVgQ=; b=jTiinUXYIdy7I0WIMyYqF4IyqpURN9sbaIxR33gxnjSrAPu9yWicZ5it2H06FaYeevde1SH/p1AO8c2DzWNQeiqlCkb4mJPRhqxluS9Tqm7mkoAwpq/NhC2QZru8kft9ECee2H+JIaH1+sBt5kPevHOuBMwn8yTEynMkJgncwkrw8gMsumg2clyNWBDxAo1kHC3Kkv7pSjhZ59TiT9czhMP+xvXgnPP2yqB0pkLFc0Yspy+a7OoMPhD0pi/lkCYNGwXSazEdK7VT77Qe5kR/9aYf7Jrdr/iNIngiHnP4Qnkx9u1jC3eAYQIaoeKC1f8XVBtH9y46N2Zkx7eYahHUPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oIRWF16pxHuJ+bOcYMN+8vS6uv2UNprONAVSaC3YVgQ=; b=hio7USZ3g9k2kEmk/MQsVd3gEVdKisV1mtEYPYj0NhEFiplRMUc+nNBQ/uaTgc0CqfRqU2OqHfqbBv406P/i8zvmxD56nj6LhnMdEuNeB4jF+g3i96Ifdlfaz+DDWnvnOam9Rf414xq9+Mg/15oHdScZQ113DhGajGn7x9SIAFg= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4539.namprd11.prod.outlook.com (2603:10b6:303:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 30 Apr 2020 08:09:47 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%6]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 08:09:47 +0000 From: "Ketan Talaulikar (ketant)" To: Nandan Saha , Andrew Alston CC: idr wg Thread-Topic: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations Thread-Index: AQHV4fnX9GqjNaH+OECMSUudeTzukagZZg2AgCujLxCAAAX2AIAANRWAgEyEzfA= Date: Thu, 30 Apr 2020 08:09:47 +0000 Message-ID: References: <20200212231711.GB32507@pfrc.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5e93536-4b49-4d7a-01b2-08d7ecddd96f x-ms-traffictypediagnostic: MW3PR11MB4539: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0389EDA07F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VEhBfs6HOlBXDPdsMAfB4h3/BCHOYFCUmxQ0LAJ7GzoLe7luTss/+45rH8JqbUKPLRpADX5mmup3nD45U95XJl1mkb0Lw3eiJWeZDAW35pjS0naxoN+ZHXjSXqVjzBrvP74wYfQdSzm6XXxxymGrf+AE8qkAv7ppLvupI2OPjMele0T7cCuOughu6EgpeXAGCy5g0bJu0UioSv5VFrDxs0Vzv6QOEaqGVrRQ8anrha4k/fVMIiP2Wz6lWXpcsv1FCZTn7pnrSAU61XAaT2VNPRU/dSisBUVa8WaZicUGwFe6Jx0A8UAYbWz4/Rtk+hDof79fwhx/iBzM0a8H//XgXDOppQhHcsnRKvKwRiMQL1itq7XzOW+qcTQ0LdJ6AUusl8ZWh5TzzoJtT64DMYAn0TzWzjT0Rxv8gPWeghbGr/H43cUjblYhqYrbdFF4lXx7vffIHQExwDuIhD+PwmTOU8iFy7w7KkFnU8PwgZBid7PH2ONUu9A5UkQbWNyvNDtczD+32dZYmWWc3ja/niU7zg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(76116006)(71200400001)(66946007)(53546011)(2906002)(33656002)(186003)(64756008)(66446008)(86362001)(66556008)(966005)(66476007)(6506007)(7696005)(52536014)(4326008)(8676002)(55016002)(26005)(478600001)(8936002)(110136005)(316002)(9326002)(5660300002)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CEtVTDSHoBh08LLVo0WE17wgF6UCwr/SnOhZm/7aYx1oIBHP7jeR4LPT27bY2R3eobpxQsGV1KvnbfQ6l44JJLXqpuBfiz5ybAobYjZkqPBjZKClrloWLH/FMvU5gv3JvnFjlY4VVzvGLyh/sVAzx6T2jv7prV7Zs5wUWiVFuGIqge0foir8wlfgsfGgIal6yeOMQJqEgyajR5XsyH9giMvW8qxZ09TahKIawe+tIIirYXyNYKcz3JAw7oQnE66eARedLcBwsb0Yp5wn/kflembynNjEs4MBiqmiOA/EQwrN38y/78NIsA9njdJvvWW5sRDgSYMgbQxJMBkyp0JoS1szg5htt8GDEugPby1pMnjbUtKco5w/2E9mL76iBFUqIR41SqneiyQYb5JR6/dFb6hub4lKsVna+cd/lhm73wn7RH9qV1lz9BZ4FCnoi6OdEe1JoBasa+pBvmneJCnYp+XLN+5iz1ypgzrWF/XR8cNpLAF3kdvizWxovOuUNrWX203XW7+Ts5X2TVhNxpR0mBA5yFXON6Vr67rJKf+esZ8zhL0ePBOKUB6lqa/JIyzIcj0xfHwvYsHUcdGVH7rv8oRCZfp2/sQOn2JMuE4tJSDN2xgWxcSJNIfCbd3mnTcOV2klAnsuIFSgNg6iCz/HCxFmJQyNl4bEXPLHERlTTxKKVI9BZRE7afykugwDfdLlRVjtjFPfF++BZtsu3wuJPDh8Tey+V64jM43wGfsXhZFlf3Exz3cbOOK0egtJg5ZP9A8hir1hGzBgHJD+gQIZH3qjYa/NhEuAMv08/UL2FME= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45708350FC84A755EFB8E1CFC1AA0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c5e93536-4b49-4d7a-01b2-08d7ecddd96f X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 08:09:47.2339 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: klqjmSCi71yc1PEFBKn+4FR3KSRaqANixZ2migT7yfKzX/Bch0GqHDc5cbu9cnjYUtUmOFZYIBJtZw45/8l1Ug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4539 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 08:09:55 -0000 --_000_MW3PR11MB45708350FC84A755EFB8E1CFC1AA0MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmFuZGFuLA0KDQpMb29rcyBsaWtlIEkgbWlzc2VkIHRvIGFja25vd2xlZGdlIHlvdXIgZW1h aWwuIEkgYWdyZWUgYW5kIHdpbGwgY2hhbmdlIHMvUG9saWN5IE5hbWUvUG9saWN5IENhbmRpZGF0 ZSBQYXRoIE5hbWUvIGluIHRoZSBuZXh0IHVwZGF0ZS4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KRnJv bTogTmFuZGFuIFNhaGEgPG5hbmRhbj00MGFyaXN0YS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTZW50 OiAxMiBNYXJjaCAyMDIwIDIxOjA3DQpUbzogQW5kcmV3IEFsc3RvbiA8QW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbT4NCkNjOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRA Y2lzY28uY29tPjsgaWRyIHdnIDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkcl0gZHJh ZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeSBQb2xpY3kgTmFtZSBTdWItVExW IGNvbnNpZGVyYXRpb25zDQoNCk9uIGEgc2xpZ2h0IHRhbmdlbnQsIGNhbiB3ZSBwbGVhc2UgY2Fs bCB0aGUgc3ViIHRsdiAiQ2FuZGlkYXRlIHBhdGggbmFtZSIgb3Igc29tZSBzdWNoLiBJdCdzIG1v cmUgYWNjdXJhdGUgdGhhbiAicG9saWN5IG5hbWUiIHNpbmNlIHRoZSBjYW5kaWRhdGUgcGF0aCBp cyBzaWduYWxsZWQgaW4gYmdwLCBub3QgYSBwb2xpY3kuLg0KDQpPbiBUaHUsIE1hciAxMiwgMjAy MCBhdCA1OjU3IFBNIEFuZHJldyBBbHN0b24gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5j b208bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PiB3cm90ZToNCkkgd291 bGQgYmUgcXVpdGUgaGFwcHkgdG8gc3RpY2sgdG8gYXNjaWkgaGVyZSDigJMgaXQgbWFrZXMgd3Jp dGluZyBpbXBsZW1lbnRhdGlvbnMgc2ltcGxlciDigJMgYW5kIHdoaWxlIEnigJl2ZSBzZWVuIG9u ZSBoYXJkd2FyZSB2ZW5kb3IgdGhhdCBoYWQgYW4gZW50aXJlIGNsaSBpbiBDeXJpbGxpYyAtICBJ 4oCZbSBub3QgZW50aXJlbHkgc3VyZSB0aGF0IGl0IGp1c3RpZmllcyBzdWNoIGEgY2hhbmdlLg0K DQpUaGVuIGFnYWluIOKAkyBJ4oCZbSBhIG5hdGl2ZSBFbmdsaXNoIHNwZWFrZXIgc28gSeKAmW0g Ymlhc2VkIOKAkyBhbmQgdGhlIHByZWZlcmVuY2UgaGVyZSBpc27igJl0IHJlYWxseSBzdHJvbmcg b24gbXkgc2lkZS4NCg0KQW5kcmV3DQoNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgS2V0 YW4gVGFsYXVsaWthciAoa2V0YW50KQ0KU2VudDogVGh1cnNkYXksIDEyIE1hcmNoIDIwMjAgMTU6 MjINClRvOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz47IHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KQ2M6IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5v cmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj47IGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGlu Zy10ZS1wb2xpY3lAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGlu Zy10ZS1wb2xpY3lAaWV0Zi5vcmc+OyBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwu Y29tPG1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuLmNvbT4+DQpTdWJqZWN0OiBSZTogW3Nwcmlu Z10gZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeSBQb2xpY3kgTmFtZSBT dWItVExWIGNvbnNpZGVyYXRpb25zDQoNCkhlbGxvLA0KDQpXb3VsZCBsaWtlIHRvIGJyaW5nIGJh Y2sgdGhpcyB0b3BpYyBmb3IgZGlzY3Vzc2lvbiBhbmQgaW5wdXRzIGZyb20gdGhlIElEUiAmIFNQ UklORyBXR3MuDQoNCldlIG5lZWQgdG8gYXNrIGlmIHRoZSAiU1IgUG9saWN5IE5hbWUiIG9iamVj dCBpcyBzb21ldGhpbmcgdGhhdCBuZWVkcyBsb2NhbGl6YXRpb24gKGkuZS4gd2UgY2hhbmdlIHRo ZSBlbmNvZGluZyBmcm9tIEFTQ0lJIHRvIFVURi04KS4NCg0KQWNjb3JkaW5nIHRvIHJmYzYzNjUg IkxvY2FsaXphdGlvbiBpcyB0aGUgYWN0IG9mIHRhaWxvcmluZyBhbiBhcHBsaWNhdGlvbiBmb3Ig YSBkaWZmZXJlbnQgbGFuZ3VhZ2Ugb3Igc2NyaXB0IG9yIGN1bHR1cmUuIiBUaGUgcXVlc3Rpb24g dGhlbiBhcmlzZXM6IHdvdWxkIHNvbWVvbmUgd2FudCB0byBkZWZpbmUgYSBwb2xpY3kgbmFtZSBp biBzb21ldGhpbmcgb3RoZXIgdGhhbiBhIGxhbmd1YWdlIHN1cHBvcnRlZCBieSBBU0NJST8gRW5n bGlzaCBpcyBzdXBwb3J0ZWQsIGJ1dCB0aGVyZSBhcmUgb3RoZXIgbGFuZ3VhZ2VzIHdoaWNoIGFy ZSBub3QuDQoNClRoaXMgb2JqZWN0IHRyYWNlcyBpdCByb290cyB0byB0aGUgZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeSBkb2N1bWVudCB3aGljaCBpbmRpY2F0ZXMgdGhl IHVzZSBvZiAicHJpbnRhYmxlIEFTQ0lJIGNoYXJhY3RlcnMiIDogaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDYjc2Vj dGlvbi0yLjENClNvIGFueSBjaGFuZ2VzIHRvIHRoZSBlbmNvZGluZyB3b3VsZCBuZWVkIHRvIGJl IHJlZmxlY3RlZCBpbiB0aGlzIGRvY3VtZW50IChhbmQgb3RoZXIgcHJvdG9jb2xzIGFuZCBZYW5n IG1vZGVscyBhcyBhbiBleHRlbnNpb24pLg0KDQpGdXJ0aGVyIG9uLCB0aGUgZXF1aXZhbGVudCBv YmplY3QgaW4gUENFUCBoYXMgYmVlbiBhbHJlYWR5IGRlZmluZWQgYXMgdXNpbmcgQVNDSUkgaW4g dGhlIG5vdyBwdWJsaXNoZWQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgyMzEjc2Vj dGlvbi03LjMuMg0KDQpCYXNlZCBvbiB0aGUgV0cgaW5wdXRzLCB3ZSBjYW4gZGV0ZXJtaW5lIHRo ZSBuZXh0IGNvdXJzZSBvZiBhY3Rpb24uDQoNClRoYW5rcywNCktldGFuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpDQpTZW50OiAx MyBGZWJydWFyeSAyMDIwIDIzOjM4DQpUbzogSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZzxt YWlsdG86amhhYXNAcGZyYy5vcmc+PjsgZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRl LXBvbGljeUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRl LXBvbGljeUBpZXRmLm9yZz47IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3Vi amVjdDogUkU6IGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kgUG9saWN5 IE5hbWUgU3ViLVRMViBjb25zaWRlcmF0aW9ucw0KDQpIaSBKZWZmLA0KDQpJIGFncmVlIHdpdGgg eW91IGFib3V0IHRoZSBsaW1pdHMgb24gdGhlIHBvbGljeSBuYW1lIHNpemUuDQoNCkkgYW0gbm90 IGF3YXJlIG9mIGFueSBJRVRGIHN0YW5kYXJkIHRoYXQgbWFuZGF0ZXMgdGhlIHVzZSBvZiBVVEYt OCBmb3IgZW5jb2Rpbmcgb2Ygc3RyaW5nIGZvciBuYW1lcy4gVGhlIHNpbWlsYXIgb2JqZWN0IGlu IFBDRVAgaXMgZW5jb2RlZCBpbiBBU0NJSSAtIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM4MjMxI3NlY3Rpb24tNy4zLjINCg0KVGhhbmtzLA0KS2V0YW4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpo YWFzQHBmcmMub3JnPj4NClNlbnQ6IDEyIEZlYnJ1YXJ5IDIwMjAgMTU6MTcNClRvOiBkcmFmdC1p ZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5QGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5QGlldGYub3JnPjsgaWRyQGlldGYub3Jn PG1haWx0bzppZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJv dXRpbmctdGUtcG9saWN5IFBvbGljeSBOYW1lIFN1Yi1UTFYgY29uc2lkZXJhdGlvbnMNCg0KQXV0 aG9ycywNCg0KSW4gZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeS0wOCwg U2VjdGlvbiAyLjQuNiB3ZSBoYXZlIGEgVExWIGZvciBQb2xpY3kgTmFtZS4gSXRzIHRleHQgaXM6 DQoNCjogMi40LjYuIFBvbGljeSBOYW1lIFN1Yi1UTFYNCjoNCjogQW4gb3BlcmF0b3IgTUFZIHNl dCB0aGUgUG9saWN5IE5hbWUgc3ViLVRMViB0byBhdHRhY2ggYSBzeW1ib2xpYyBuYW1lDQo6IHRv IHRoZSBTUiBQb2xpY3kgY2FuZGlkYXRlIHBhdGguDQo6DQo6IFVzYWdlIG9mIFBvbGljeSBOYW1l IHN1Yi1UTFYgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMiBpbg0KOiBbSS1ELmlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ldLg0KOg0KOiBUaGUgUG9saWN5IE5hbWUgc3ViLVRMViBt YXkgZXhjZWVkIDI1NSBieXRlcyBsZW5ndGggZHVlIHRvIGxvbmcNCjogcG9saWN5IG5hbWUuIFRo ZXJlZm9yZSBhIDItb2N0ZXQgbGVuZ3RoIGlzIHJlcXVpcmVkLiBBY2NvcmRpbmcgdG8NCjogW0kt RC5pZXRmLWlkci10dW5uZWwtZW5jYXBzXSwgdGhlIGZpcnN0IGJpdCBvZiB0aGUgc3ViLVRMViBj b2RlcG9pbnQNCjogZGVmaW5lcyB0aGUgc2l6ZSBvZiB0aGUgbGVuZ3RoIGZpZWxkLiBUaGVyZWZv cmUsIGZvciB0aGUgUG9saWN5IE5hbWUNCjogc3ViLVRMViBhIGNvZGUgcG9pbnQgb2YgMTI4IG9y IGhpZ2hlciBpcyB1c2VkLg0KOg0KOiBUaGUgUG9saWN5IE5hbWUgc3ViLVRMViBpcyBvcHRpb25h bCBhbmQgaXQgTVVTVCBOT1QgYXBwZWFyIG1vcmUgdGhhbg0KOiBvbmNlIGluIHRoZSBTUiBQb2xp Y3kgVExWLg0KOg0KOiBUaGUgUG9saWN5IE5hbWUgc3ViLVRMViBoYXMgZm9sbG93aW5nIGZvcm1h dDoNCjoNCjogMCAxIDIgMw0KOiAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCjogKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCjogfCBUeXBlIHwgTGVuZ3Ro IHwgUkVTRVJWRUQgfA0KOiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KOiAvLyBQb2xpY3kgTmFtZSAvLw0KOiArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KOg0KOiBXaGVyZToNCjoNCjogVHlwZTogMTI5Lg0KOg0KOiBMZW5ndGg6IFZhcmlhYmxlLg0K Og0KOiBSRVNFUlZFRDogMSBvY3RldCBvZiByZXNlcnZlZCBiaXRzLiBTSE9VTEQgYmUgc2V0IHRv IHplcm8gb24NCjogdHJhbnNtaXNzaW9uIGFuZCBNVVNUIGJlIGlnbm9yZWQgb24gcmVjZWlwdC4N CjoNCjogUG9saWN5IE5hbWU6IFN5bWJvbGljIG5hbWUgZm9yIHRoZSBwb2xpY3kuIEl0IFNIT1VM RCBiZSBhIHN0cmluZw0KOiBvZiBwcmludGFibGUgQVNDSUkgY2hhcmFjdGVycywgd2l0aG91dCBh IE5VTEwgdGVybWluYXRvci4NCg0KZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeS0wNiwgU2VjdGlvbiAyLjEgZGlzY3Vzc2VzIHRoaXMNClN1Yi1UTFY6DQoNCjogQW4gaW1w bGVtZW50YXRpb24gTUFZIGFsbG93IGFzc2lnbm1lbnQgb2YgYSBzeW1ib2xpYyBuYW1lIGNvbXBy aXNpbmcNCjogb2YgcHJpbnRhYmxlIEFTQ0lJIGNoYXJhY3RlcnMgdG8gYW4gU1IgUG9saWN5IHRv IHNlcnZlIGFzIGEgdXNlci0NCjogZnJpZW5kbHkgYXR0cmlidXRlIGZvciBkZWJ1ZyBhbmQgdHJv dWJsZXNob290aW5nIHB1cnBvc2VzLiBTdWNoDQo6IHN5bWJvbGljIG5hbWVzIG1heSBpZGVudGlm eSBhbiBTUiBQb2xpY3kgd2hlbiB0aGUgbmFtaW5nIHNjaGVtZQ0KOiBlbnN1cmVzIHVuaXF1ZW5l c3MuDQoNClRoZXJlIGFyZSB0d28gb2JzZXJ2YXRpb25zIEknZCBsaWtlIHRvIG1ha2U6DQoxLiBB IDY1SyBsZW5ndGggaXNuJ3QgdmVyeSBsaWtlbHkgaW4gQkdQLiA6LSkgSSBzdWdnZXN0IHRoYXQg Z3JlYXRlciBndWlkYW5jZSBmb3Igc2hvcnRlciBuYW1lcyBzaG91bGQgYmUgb2ZmZXJlZC4gRm9y IGV4YW1wbGUsIHBlcmhhcHMgbGltaXQgdGhlIGxlbmd0aCB0byAxSy4gQWx0ZXJuYXRpdmVseSwg b2ZmZXIgYWR2aWNlIHN1Y2ggYXM6ICJJbXBsZW1lbnRhdGlvbnMgbWF5IGNob29zZSB0byB0cnVu Y2F0ZSBsb25nIFBvbGljeSBOYW1lcyIuDQoNCjIuIFRoZSBndWlkYW5jZSBhYm91dCAicHJpbnRh YmxlIEFTQ0lJIiBpcyByYXRoZXIgb2xkLXN0eWxlIGFuZCBsaWtlbHkgdG8gcnVuIGFza2FuY2Ug b2YgSUVTRyByZXZpZXcgZm9yIGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zLi4u IEknZCBzdWdnZXN0IHRoYXQgdGhlIGZpZWxkIGJlIGVuY29kZWQgaW4gVVRGLTggYW5kIG1ha2Ug cmVmZXJlbmNlIHRvIHByaW50LXNhZmV0eSBzaW1pbGFyIHRvIFJGQyA4MjAzIChCR1AgQWRtaW5p c3RyYXRpdmUgU2h1dGRvd24pIGluIGl0cyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4NCg0KLS0g SmVmZg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K c3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxp c3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== --_000_MW3PR11MB45708350FC84A755EFB8E1CFC1AA0MW3PR11MB4570namp_ 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 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1JTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBOYW5kYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkxvb2tzIGxpa2UgSSBtaXNzZWQg dG8gYWNrbm93bGVkZ2UgeW91ciBlbWFpbC4gSSBhZ3JlZSBhbmQgd2lsbCBjaGFuZ2Ugcy9Qb2xp Y3kgTmFtZS9Qb2xpY3kgQ2FuZGlkYXRlIFBhdGggTmFtZS8gaW4gdGhlIG5leHQgdXBkYXRlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5LZXRhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IE5hbmRhbiBTYWhhICZsdDtuYW5kYW49NDBhcmlzdGEuY29tQGRtYXJjLmll dGYub3JnJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDEyIE1hcmNoIDIwMjAgMjE6MDc8YnI+DQo8 Yj5Ubzo8L2I+IEFuZHJldyBBbHN0b24gJmx0O0FuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDtrZXRh bnRAY2lzY28uY29tJmd0OzsgaWRyIHdnICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9s aWN5IFBvbGljeSBOYW1lIFN1Yi1UTFYgY29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBhIHNsaWdodCB0YW5nZW50LCBjYW4gd2UgcGxlYXNlIGNh bGwgdGhlIHN1YiB0bHYgJnF1b3Q7Q2FuZGlkYXRlIHBhdGggbmFtZSZxdW90OyBvciBzb21lIHN1 Y2guIEl0J3MgbW9yZSBhY2N1cmF0ZSB0aGFuICZxdW90O3BvbGljeSBuYW1lJnF1b3Q7IHNpbmNl IHRoZSBjYW5kaWRhdGUgcGF0aCBpcyBzaWduYWxsZWQgaW4gYmdwLCBub3QgYSBwb2xpY3kuLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIg MTIsIDIwMjAgYXQgNTo1NyBQTSBBbmRyZXcgQWxzdG9uICZsdDs8YSBocmVmPSJtYWlsdG86QW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtt YXJnaW46MC4uOGV4Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+SSB3b3VsZCBiZSBxdWl0ZSBoYXBweSB0byBzdGljayB0byBhc2NpaSBo ZXJlIOKAkyBpdCBtYWtlcyB3cml0aW5nIGltcGxlbWVudGF0aW9ucyBzaW1wbGVyIOKAkyBhbmQg d2hpbGUgSeKAmXZlIHNlZW4gb25lIGhhcmR3YXJlIHZlbmRvciB0aGF0IGhhZCBhbiBlbnRpcmUg Y2xpIGluIEN5cmlsbGljDQogLSAmbmJzcDtJ4oCZbSBub3QgZW50aXJlbHkgc3VyZSB0aGF0IGl0 IGp1c3RpZmllcyBzdWNoIGEgY2hhbmdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZW4gYWdh aW4g4oCTIEnigJltIGEgbmF0aXZlIEVuZ2xpc2ggc3BlYWtlciBzbyBJ4oCZbSBiaWFzZWQg4oCT IGFuZCB0aGUgcHJlZmVyZW5jZSBoZXJlIGlzbuKAmXQgcmVhbGx5IHN0cm9uZyBvbiBteSBzaWRl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZHJldzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOmN1cnJlbnRj b2xvciBjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5P biBCZWhhbGYgT2YgPC9iPktldGFuIFRhbGF1bGlrYXIgKGtldGFudCk8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIDEyIE1hcmNoIDIwMjAgMTU6MjI8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHJAaWV0Zi5vcmc8L2E+OyA8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiBKZWZmcmV5IEhhYXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpqaGFhc0BwZnJjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpoYWFzQHBmcmMub3JnPC9hPiZn dDs7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBv bGljeUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1y b3V0aW5nLXRlLXBvbGljeUBpZXRmLm9yZzwvYT47IEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9 Im1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFyZXRhbmEu aWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10g ZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeSBQb2xpY3kgTmFtZSBTdWIt VExWIGNvbnNpZGVyYXRpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkhl bGxvLDxicj4NCjxicj4NCldvdWxkIGxpa2UgdG8gYnJpbmcgYmFjayB0aGlzIHRvcGljIGZvciBk aXNjdXNzaW9uIGFuZCBpbnB1dHMgZnJvbSB0aGUgSURSICZhbXA7IFNQUklORyBXR3MuDQo8YnI+ DQo8YnI+DQpXZSBuZWVkIHRvIGFzayBpZiB0aGUgJnF1b3Q7U1IgUG9saWN5IE5hbWUmcXVvdDsg b2JqZWN0IGlzIHNvbWV0aGluZyB0aGF0IG5lZWRzIGxvY2FsaXphdGlvbiAoaS5lLiB3ZSBjaGFu Z2UgdGhlIGVuY29kaW5nIGZyb20gQVNDSUkgdG8gVVRGLTgpLjxicj4NCjxicj4NCkFjY29yZGlu ZyB0byByZmM2MzY1ICZxdW90O0xvY2FsaXphdGlvbiBpcyB0aGUgYWN0IG9mIHRhaWxvcmluZyBh biBhcHBsaWNhdGlvbiBmb3IgYSBkaWZmZXJlbnQgbGFuZ3VhZ2Ugb3Igc2NyaXB0IG9yIGN1bHR1 cmUuJnF1b3Q7IFRoZSBxdWVzdGlvbiB0aGVuIGFyaXNlczogd291bGQgc29tZW9uZSB3YW50IHRv IGRlZmluZSBhIHBvbGljeSBuYW1lIGluIHNvbWV0aGluZyBvdGhlciB0aGFuIGEgbGFuZ3VhZ2Ug c3VwcG9ydGVkIGJ5IEFTQ0lJPyBFbmdsaXNoIGlzDQogc3VwcG9ydGVkLCBidXQgdGhlcmUgYXJl IG90aGVyIGxhbmd1YWdlcyB3aGljaCBhcmUgbm90Ljxicj4NCjxicj4NClRoaXMgb2JqZWN0IHRy YWNlcyBpdCByb290cyB0byB0aGUgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeSBkb2N1bWVudCB3aGljaCBpbmRpY2F0ZXMgdGhlIHVzZSBvZiAmcXVvdDtwcmludGFibGUg QVNDSUkgY2hhcmFjdGVycyZxdW90OyA6DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wNiNzZWN0aW9u LTIuMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDYjc2VjdGlvbi0yLjE8L2E+PGJy Pg0KU28gYW55IGNoYW5nZXMgdG8gdGhlIGVuY29kaW5nIHdvdWxkIG5lZWQgdG8gYmUgcmVmbGVj dGVkIGluIHRoaXMgZG9jdW1lbnQgKGFuZCBvdGhlciBwcm90b2NvbHMgYW5kIFlhbmcgbW9kZWxz IGFzIGFuIGV4dGVuc2lvbikuPGJyPg0KPGJyPg0KRnVydGhlciBvbiwgdGhlIGVxdWl2YWxlbnQg b2JqZWN0IGluIFBDRVAgaGFzIGJlZW4gYWxyZWFkeSBkZWZpbmVkIGFzIHVzaW5nIEFTQ0lJIGlu IHRoZSBub3cgcHVibGlzaGVkDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODIzMSNzZWN0aW9uLTcuMy4yIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzgyMzEjc2VjdGlvbi03LjMuMjwvYT4NCjxicj4NCjxicj4NCkJhc2VkIG9u IHRoZSBXRyBpbnB1dHMsIHdlIGNhbiBkZXRlcm1pbmUgdGhlIG5leHQgY291cnNlIG9mIGFjdGlv bi48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2V0YW48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGJyPg0K U2VudDogMTMgRmVicnVhcnkgMjAyMCAyMzozODxicj4NClRvOiBKZWZmcmV5IEhhYXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpqaGFhc0BwZnJjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpoYWFzQHBmcmMu b3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0 aW5nLXRlLXBvbGljeUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1pZHIt c2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpp ZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmlkckBpZXRmLm9yZzwvYT48YnI+DQpTdWJq ZWN0OiBSRTogZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeSBQb2xpY3kg TmFtZSBTdWItVExWIGNvbnNpZGVyYXRpb25zPGJyPg0KPGJyPg0KSGkgSmVmZiw8YnI+DQo8YnI+ DQpJIGFncmVlIHdpdGggeW91IGFib3V0IHRoZSBsaW1pdHMgb24gdGhlIHBvbGljeSBuYW1lIHNp emUuIDxicj4NCjxicj4NCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJRVRGIHN0YW5kYXJkIHRoYXQg bWFuZGF0ZXMgdGhlIHVzZSBvZiBVVEYtOCBmb3IgZW5jb2Rpbmcgb2Ygc3RyaW5nIGZvciBuYW1l cy4gVGhlIHNpbWlsYXIgb2JqZWN0IGluIFBDRVAgaXMgZW5jb2RlZCBpbiBBU0NJSSAtDQo8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODIzMSNzZWN0aW9uLTcuMy4yIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgyMzEjc2VjdGlv bi03LjMuMjwvYT4NCjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpLZXRhbjxicj4NCjxicj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSmVmZnJleSBIYWFzICZsdDs8YSBo cmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIHRhcmdldD0iX2JsYW5rIj5qaGFhc0BwZnJjLm9y ZzwvYT4mZ3Q7DQo8YnI+DQpTZW50OiAxMiBGZWJydWFyeSAyMDIwIDE1OjE3PGJyPg0KVG86IDxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmct dGUtcG9saWN5QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPg0KaWRyQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IGRyYWZ0LWlldGYt aWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kgUG9saWN5IE5hbWUgU3ViLVRMViBjb25zaWRl cmF0aW9uczxicj4NCjxicj4NCkF1dGhvcnMsPGJyPg0KPGJyPg0KSW4gZHJhZnQtaWV0Zi1pZHIt c2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeS0wOCwgU2VjdGlvbiAyLjQuNiB3ZSBoYXZlIGEgVExW IGZvciBQb2xpY3kgTmFtZS4gSXRzIHRleHQgaXM6PGJyPg0KPGJyPg0KOiAyLjQuNi4gUG9saWN5 IE5hbWUgU3ViLVRMVjxicj4NCjogPGJyPg0KOiBBbiBvcGVyYXRvciBNQVkgc2V0IHRoZSBQb2xp Y3kgTmFtZSBzdWItVExWIHRvIGF0dGFjaCBhIHN5bWJvbGljIG5hbWU8YnI+DQo6IHRvIHRoZSBT UiBQb2xpY3kgY2FuZGlkYXRlIHBhdGguPGJyPg0KOiA8YnI+DQo6IFVzYWdlIG9mIFBvbGljeSBO YW1lIHN1Yi1UTFYgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMiBpbjxicj4NCjogW0ktRC5pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5XS48YnI+DQo6IDxicj4NCjogVGhlIFBvbGlj eSBOYW1lIHN1Yi1UTFYgbWF5IGV4Y2VlZCAyNTUgYnl0ZXMgbGVuZ3RoIGR1ZSB0byBsb25nPGJy Pg0KOiBwb2xpY3kgbmFtZS4gVGhlcmVmb3JlIGEgMi1vY3RldCBsZW5ndGggaXMgcmVxdWlyZWQu IEFjY29yZGluZyB0bzxicj4NCjogW0ktRC5pZXRmLWlkci10dW5uZWwtZW5jYXBzXSwgdGhlIGZp cnN0IGJpdCBvZiB0aGUgc3ViLVRMViBjb2RlcG9pbnQ8YnI+DQo6IGRlZmluZXMgdGhlIHNpemUg b2YgdGhlIGxlbmd0aCBmaWVsZC4gVGhlcmVmb3JlLCBmb3IgdGhlIFBvbGljeSBOYW1lPGJyPg0K OiBzdWItVExWIGEgY29kZSBwb2ludCBvZiAxMjggb3IgaGlnaGVyIGlzIHVzZWQuPGJyPg0KOiA8 YnI+DQo6IFRoZSBQb2xpY3kgTmFtZSBzdWItVExWIGlzIG9wdGlvbmFsIGFuZCBpdCBNVVNUIE5P VCBhcHBlYXIgbW9yZSB0aGFuPGJyPg0KOiBvbmNlIGluIHRoZSBTUiBQb2xpY3kgVExWLjxicj4N CjogPGJyPg0KOiBUaGUgUG9saWN5IE5hbWUgc3ViLVRMViBoYXMgZm9sbG93aW5nIGZvcm1hdDo8 YnI+DQo6IDxicj4NCjogMCAxIDIgMzxicj4NCjogMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPGJyPg0KOiAmIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOzxicj4NCjogfCBUeXBlIHwgTGVuZ3RoIHwgUkVTRVJWRUQgfDxicj4NCjog JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8YnI+DQo6IC8vIFBvbGljeSBOYW1lIC8vPGJyPg0K OiAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxicj4NCjogPGJyPg0KOiBXaGVyZTo8YnI+DQo6 IDxicj4NCjogVHlwZTogMTI5Ljxicj4NCjogPGJyPg0KOiBMZW5ndGg6IFZhcmlhYmxlLjxicj4N CjogPGJyPg0KOiBSRVNFUlZFRDogMSBvY3RldCBvZiByZXNlcnZlZCBiaXRzLiBTSE9VTEQgYmUg c2V0IHRvIHplcm8gb248YnI+DQo6IHRyYW5zbWlzc2lvbiBhbmQgTVVTVCBiZSBpZ25vcmVkIG9u IHJlY2VpcHQuPGJyPg0KOiA8YnI+DQo6IFBvbGljeSBOYW1lOiBTeW1ib2xpYyBuYW1lIGZvciB0 aGUgcG9saWN5LiBJdCBTSE9VTEQgYmUgYSBzdHJpbmc8YnI+DQo6IG9mIHByaW50YWJsZSBBU0NJ SSBjaGFyYWN0ZXJzLCB3aXRob3V0IGEgTlVMTCB0ZXJtaW5hdG9yLjxicj4NCjxicj4NCmRyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDYsIFNlY3Rpb24gMi4xIGRpc2N1 c3NlcyB0aGlzPGJyPg0KU3ViLVRMVjo8YnI+DQo8YnI+DQo6IEFuIGltcGxlbWVudGF0aW9uIE1B WSBhbGxvdyBhc3NpZ25tZW50IG9mIGEgc3ltYm9saWMgbmFtZSBjb21wcmlzaW5nPGJyPg0KOiBv ZiBwcmludGFibGUgQVNDSUkgY2hhcmFjdGVycyB0byBhbiBTUiBQb2xpY3kgdG8gc2VydmUgYXMg YSB1c2VyLTxicj4NCjogZnJpZW5kbHkgYXR0cmlidXRlIGZvciBkZWJ1ZyBhbmQgdHJvdWJsZXNo b290aW5nIHB1cnBvc2VzLiBTdWNoPGJyPg0KOiBzeW1ib2xpYyBuYW1lcyBtYXkgaWRlbnRpZnkg YW4gU1IgUG9saWN5IHdoZW4gdGhlIG5hbWluZyBzY2hlbWU8YnI+DQo6IGVuc3VyZXMgdW5pcXVl bmVzcy48YnI+DQo8YnI+DQpUaGVyZSBhcmUgdHdvIG9ic2VydmF0aW9ucyBJJ2QgbGlrZSB0byBt YWtlOjxicj4NCjEuIEEgNjVLIGxlbmd0aCBpc24ndCB2ZXJ5IGxpa2VseSBpbiBCR1AuIDotKSBJ IHN1Z2dlc3QgdGhhdCBncmVhdGVyIGd1aWRhbmNlIGZvciBzaG9ydGVyIG5hbWVzIHNob3VsZCBi ZSBvZmZlcmVkLiBGb3IgZXhhbXBsZSwgcGVyaGFwcyBsaW1pdCB0aGUgbGVuZ3RoIHRvIDFLLiBB bHRlcm5hdGl2ZWx5LCBvZmZlciBhZHZpY2Ugc3VjaCBhczogJnF1b3Q7SW1wbGVtZW50YXRpb25z IG1heSBjaG9vc2UgdG8gdHJ1bmNhdGUgbG9uZyBQb2xpY3kgTmFtZXMmcXVvdDsuPGJyPg0KPGJy Pg0KMi4gVGhlIGd1aWRhbmNlIGFib3V0ICZxdW90O3ByaW50YWJsZSBBU0NJSSZxdW90OyBpcyBy YXRoZXIgb2xkLXN0eWxlIGFuZCBsaWtlbHkgdG8gcnVuIGFza2FuY2Ugb2YgSUVTRyByZXZpZXcg Zm9yIGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zLi4uIEknZCBzdWdnZXN0IHRo YXQgdGhlIGZpZWxkIGJlIGVuY29kZWQgaW4gVVRGLTggYW5kIG1ha2UgcmVmZXJlbmNlIHRvIHBy aW50LXNhZmV0eSBzaW1pbGFyIHRvIFJGQyA4MjAzIChCR1AgQWRtaW5pc3RyYXRpdmUNCiBTaHV0 ZG93bikgaW4gaXRzIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLjxicj4NCjxicj4NCi0tIEplZmY8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PklkckBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWRyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW3PR11MB45708350FC84A755EFB8E1CFC1AA0MW3PR11MB4570namp_-- From nobody Thu Apr 30 01:46:17 2020 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 D87C93A0BCE; Thu, 30 Apr 2020 01:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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 header.b=m4Jc+5fM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kOACpC8S 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 qArioKYiusij; Thu, 30 Apr 2020 01:46:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D893A0BC7; Thu, 30 Apr 2020 01:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12230; q=dns/txt; s=iport; t=1588236373; x=1589445973; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HTdi7FvnkEkaBI9XmAg7ZEstVRBTniRLXqf5wf+Ws9Q=; b=m4Jc+5fMDoJ+qm/GcoVmzKWb6lX65Pb3AZ8PVXD64xM+k6Muz9Efa5HS 8B4mOlLlRqYJ+a7DZ/YxWsQbIje/+tXcDVEpV0jONdQGZxTjh/UNkPnOC HmxhqG9dzn9qOc7ogMfSFeKwxmqL8sDztp9aluL8bWhpkB8EwRexyXoGV Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AT5x/dBao7qM9UCzZ5Aqgc1j/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD4XG4u1JiqzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZ0DbvXCzqzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AAB3j6pe/4cNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTUFAQELAYEkLyQtBW5YLyoKh10DjUOTT4RigS6BJANUCwE?= =?us-ascii?q?BAQwBASMKAgQBAYREAoIvJDYHDgIDAQELAQEFAQEBAgEFBG2FKgclDIVxAQE?= =?us-ascii?q?BAQMSGxMBATcBDwIBCBEEAQEvMh0IAQEEAQ0FCAwOgwWBfk0DLgEOp3kCgTm?= =?us-ascii?q?IYXSBNIMAAQEFhUcYgg4DBoE4AYJiiV4agUE/gVSCTT6CZwEBAgGBZCuDGII?= =?us-ascii?q?tl1SaZQqCRYgThXaKG4JbmiyQBYFXh3STQgIEAgQFAg4BAQWBWQYsgVZwFYM?= =?us-ascii?q?kUBgNgTyQfziDOoUUhUEBdDYCBggBAQMJfJBeAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,334,1583193600"; d="scan'208,217";a="759804393" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2020 08:46:12 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03U8kCTN019465 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2020 08:46:12 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Apr 2020 03:46:12 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Apr 2020 03:46:12 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 30 Apr 2020 03:46:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=amQThTGsIpOkWpgPa79SCFvhZV58K5KhNO+gCiOsDdSN6PGagAGdp6/Kd3pajzy+Fdkr29OUl44TMxYFczvRqCPajjXNU0sIgRJBqxhiOXCMyUUWBOZ5Pc9U54hGQBntWqptOSNv5MG9mLDQzYHoaSdG3Msb4OOzvzbb4CChHtDJKUlGUgncGrSx1DF9FhOAUFG+w2RoPZEdyeZW2CrtftDeTtfXYbQicDMR3zuHz16LmBeFgXdkXkIZoRjQoXD8po6yfdp5yI3i/z1NSpS1CsSfHizQzzDMG31HkAX/bOLpv5/GwijtRxBPnDZE/KIUmJjYVYTeY5iBgn2ZJQsuiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=08o4BhQjxMtsF+XsJck5NTLLMDC2K22olFb0eKDSKQ8=; b=d7DRtdTWm3mhQWTTboGfN51xWvAj0p8XmANKvKwLFDu3nXbCo8szErpAiq5WZLvMhrYCPqd8wlZDUMOH7ylTPHiiLu3EVoZcVX/D5Nrw6oXH9VHcSTX71CynmABnr2chdEyhkwb0yFLRAqXDfwAleMyVB2242qkMrM0cwd7WlbJjlCt8RFG9CMu4+1Wk0oX2SwWu9KYnSDk5HAIiftZsrfRS7nxGX0qrIDDN+1fgfhSVfX3ZNYyPLNXoINsE5zRMkZlJwqxcF7qxfYrrsOmnAOuBcn/cRE/yLK+a7Nb5nunWJShcdKXrQmpfv6Aq97DxjEKb/8TFv/JRa1IgD9Pi2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=08o4BhQjxMtsF+XsJck5NTLLMDC2K22olFb0eKDSKQ8=; b=kOACpC8SoJOO7Oq3L/h8tQXLrNbGjqWv2ne9rY0Utfoc+CV1uT/o2Uurf/nvvtS/vQ3iHNaZ0Ou85qRBFenz25bi3dxWg/cNuq/joLM+qCLTI1Ji1ikBYZZqjmcpl12gJTr/kto2v0UJbPQZFXSZSxs6pOyqq9POq41olyUJlGI= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4764.namprd11.prod.outlook.com (2603:10b6:303:5a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 30 Apr 2020 08:46:11 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%6]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 08:46:10 +0000 From: "Ketan Talaulikar (ketant)" To: "Chengli (Cheng Li)" , "draft-ietf-spring-segment-routing-policy@ietf.org" CC: SPRING WG , huruizhao , Fangsheng , idr wg Thread-Topic: Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy) Thread-Index: AdYek4MmKSUhOySlR86q9L0AexcDnQANyexg Date: Thu, 30 Apr 2020 08:46:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62a533b1-b91d-444d-a8b7-08d7ece2ee95 x-ms-traffictypediagnostic: MW3PR11MB4764: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0389EDA07F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xFAT3C0djiCkx/7/HTnoGJ2KovtbuwLmJ+n4iYKcLsB0oYQUkmUdXm7h6g9lbwVijE4K5JwCFSfp2Durvd/eF/hRhityB8v0rzR5hadsZggs1j0McQp0Vidgd2y2Q7xaOWR4GqrWlwKbeIZdE3vFGLj5/o7u1phFl2+K5C99KgBn0+NRDnz9Ac4M+PJrmBI0ZuNB20HAZ7SPQp736jHg5uMcQub7cpliUWpV2XaHh0Iv0gj1Y8+zDC+J+9LsRuqXjHD4CRj87JAd1x+IpmT0y1z1cF7qjsONxhg56mXlpudQg69jM4PqTElIUl3w3qo93m95eG0/CIWzh1TSISVb/TuKwF5wIP0pFh4chmMKwBiYCNPNAoOvbHylLrjVVnJQ0lwhgRjTOoOK678Z5JXKV6CzQmzsT3DhNmI2XVTx2PFIhOlWtQONvZKBNIFx4li/J/8qPg/ZWTIh6KajdLGj8DQDLYVZ9XquwUUAksT9WdJ3qRfNLUrmHqEGyj69rfaWnSR53zBqpUrvL3C6AlMqCg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(136003)(346002)(39860400002)(396003)(478600001)(86362001)(6506007)(53546011)(7696005)(186003)(54906003)(5660300002)(26005)(110136005)(316002)(71200400001)(66574012)(9686003)(8676002)(2906002)(8936002)(4326008)(66946007)(66476007)(55016002)(64756008)(66446008)(52536014)(66556008)(33656002)(76116006)(9326002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9fczFt5T+ICIwh4k5u4FKdpil1gVn1/mJ9RZK1FkReAIxUKTnl9Ok9qXpj9xNTKk+BLN/9Rj5Bc2NePO1OznmiAmDL3tCFi5N0lgGy/f3nzIG5QxqLgCi+1bK64/ZY/czCemiFufspAun6WykHN085hw4RfwoOGZbbdt06dWGnHKYKu5SORQSjJJEo4GvUFx8gpK7UCm1eWKkYfE2VlpQH0Lfl6NjsnDJ8Dq+pOD1WPgtXwlcMlm2ew6I+Xf117wDglOtfhGpz5lEO3Tjyw51AhrsUDhErayn7QPZD5PWQOT9u3VeqidQrX3zcE51vgMZB4uzAVNNUPXzJafuKgXzC4KNOzf0mGMAwXjCgjw4FmQNNp3VJ1jmPDqh7kSPJBstEJTumm1SxP/dibZq0RWTlBXJD7JN04ZDLaJhNodMIlaIeTq6hbvd6s1iCNvzxhH52hPDjylls0IrGaLRG9jDkkcFDAieLXfW8yTfNKm6o0lg8o2AxHRD8R6lsxwx04gL8EjX6p3VliC1twl3Ub66qrCu4c+PfpC6TS0M/fYL+9G8s79KYZxzMTaykdNOj62VlSiePD4f0/cMsx68pk9OZ3inf2ndhzJYTsOLRFZaDs7NynfhOYvguJW+yZeAx2wd19nUp2/ujT8uUz0i+1g7AJNY/kAvoyebDLz7c8zOd0jZrqT7b96Oj0DGlAguweM7Xx8ioJ+BPswtHgwRCzB7USalGsPuhPjDzCMscctAj8NWnmpzGGS/AltgaH6nrU45eezSU0VyM/WxffyZEFUs5me9ohiINmaYDSdpltsHNc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45702B49025A293583346F36C1AA0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 62a533b1-b91d-444d-a8b7-08d7ece2ee95 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 08:46:10.4758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iHfKU/KhfvNoHIhCKzvNZbFnRYDcXl7wCeBXUBcm4Qk9SnNv9UfYSXq2KDEoGRVUrPCS8q+3r7sOecUCpnsFYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4764 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 08:46:16 -0000 --_000_MW3PR11MB45702B49025A293583346F36C1AA0MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Cheng, I assume you are recommending the use of Route Origin Extended Community (h= ttps://tools.ietf.org/html/rfc4360#section-5) for conveying the "Originator= " when the SR Policy update is propagated over eBGP sessions via other eBGP= /iBGP sessions instead of direct peering with the headend. I believe it does address the scenario you describe given that it is expect= ed that SR Policy propagation via BGP is happening within a single administ= rative domain even if it comprises of multiple ASes. Also copying the IDR WG for inputs since this would likely need to be updat= ed in draft-ietf-idr-segment-routing-te-policy. Thanks, Ketan From: spring On Behalf Of Chengli (Cheng Li) Sent: 30 April 2020 07:34 To: draft-ietf-spring-segment-routing-policy@ietf.org Cc: SPRING WG ; huruizhao ; Fangshen= g Subject: [spring] Comments: Route Origin Community in SR Policy(draft-ietf-= spring-segment-routing-policy) Hi authors, In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced= how the node-address of "Originator of CP(Candidate Path)" is generated wh= en the Protocol-Origin is BGP. It says: "Protocol-Origin is BGP SR Policy, it is provided by the BGP component = on the headend and is: o the BGP Router ID and ASN of the node/controller signalling the can= didate path when it has a BGP session to the headend, OR o the BGP Router ID of the eBGP peer signalling the candidate path a= long with ASN of origin when the signalling is done via one or more interm= ediate eBGP routers, OR o the BGP Originator ID [RFC4456] and the ASN of the node/controller = when the signalling is done via one or more route-reflectors over iBGP se= ssion." In the operator's network, in order to reduce the number of BGP sessions i= n controller and achieve scalability, the controller only establishes eBGP = peer with the RR. And the RR establishes iBGP peers with the headends. As m= entioned in the draft, the headend will use the RR's Router ID as the CP's = node-address (the signaling is done via route transmission from RR to the h= eadend instead of route reflection). The headend needs to carry the CP's k= ey when reporting the SR Policy status to the controller through BGP-LS. An= d there is a problem that the controller may not recognize the key because = the node-address is generated by the RR node. For network robustness, two or more RRs are usually deployed. This will int= roduce another problem.. When the same CP advertised by the controller is d= elivered to the headend through different RRs, the headend cannot distingui= sh whether it is the same CP because the node-address in the CPs' key come= s from different RRs. To solve these problems, We recommend carrying the Route Origin Community = (defined in RFC 4360) directly when the controller advertises BGP routes. = In this way, the key of the CP is determined by the controller and will no= t change during the advertisement of BGP routes. Thanks, Cheng --_000_MW3PR11MB45702B49025A293583346F36C1AA0MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Cheng,

 

I assume you are recommending the use of Route Origin Extended Comm= unity (htt= ps://tools.ietf.org/html/rfc4360#section-5) for conveying the “Originator” when the SR Policy update is pr= opagated over eBGP sessions via other eBGP/iBGP sessions instead of direct = peering with the headend.

 

I believe it does address the scenario you describe given that it i= s expected that SR Policy propagation via BGP is happening within a single = administrative domain even if it comprises of multiple ASes.

 

Also copying the IDR WG for inputs since this would likely need to = be updated in draft-ietf-idr-segment-routing-te-policy.

 

Thanks,

Ketan

 

From: spring <spring-bounces@ietf.org> On Behalf Of Chengli (Cheng Li)
Sent: 30 April 2020 07:34
To: draft-ietf-spring-segment-routing-policy@ietf.org
Cc: SPRING WG <spring@ietf.org>; huruizhao <huruizhao@huawe= i.com>; Fangsheng <fangsheng@huawei.com>
Subject: [spring] Comments: Route Origin Community in SR Policy(draf= t-ietf-spring-segment-routing-policy)

 =

Hi auth= ors,

 <= o:p>

In sect= ion 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced how th= e node-address of "Originator of CP(Candidate Path)" is generated= when the Protocol-Origin is BGP. It says:

  =   “Protocol-Origin is BGP SR Policy, it is provided by the BGP c= omponent on the headend and is:

 &= nbsp;   o  the BGP Router ID and ASN of the node/controller = signalling the candidate path when it has a BGP session to the headend, OR<= o:p>

 &= nbsp;   o  the BGP Router ID of the eBGP peer signalling the= candidate path  along with ASN of origin when the signalling is done = via one or  more intermediate eBGP routers, OR

 &= nbsp;   o  the BGP Originator ID [RFC4456] and the ASN of th= e node/controller  when the signalling is done via one or more route-r= eflectors over  iBGP session.”

 &= nbsp;

In the = operator's network, in order to reduce the number of  BGP sessions in = controller and achieve scalability, the controller only establishes eBGP pe= er with the RR. And the RR establishes iBGP peers with the headends. As mentioned in the draft, the headend will use t= he RR's Router ID as the CP's node-address (the signaling is done via route= transmission from RR to the headend instead of route reflection).  Th= e headend needs to carry the CP's key when reporting the SR Policy status to the controller through BGP-LS. And = there is a problem that the controller may not recognize the key because th= e node-address is generated by the RR node.

&n= bsp;

For net= work robustness, two or more RRs are usually deployed. This will introduce = another problem.. When the same CP advertised by the controller is delivere= d to the headend through different RRs, the headend cannot distinguish whether it is the same CP because the node-= address in the CPs' key  comes from different RRs.

&n= bsp;

To solv= e these problems,  We recommend carrying the Route Origin Community (d= efined in RFC 4360) directly when the controller advertises BGP routes.&nbs= p; In this way, the key  of the CP is determined by the controller and will not change during the advertisement of BGP rout= es.

 

Thanks,=

Cheng

--_000_MW3PR11MB45702B49025A293583346F36C1AA0MW3PR11MB4570namp_-- From nobody Thu Apr 30 02:15:53 2020 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 BBD6F3A0C5C for ; Thu, 30 Apr 2020 02:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRqnIrMq5xzD for ; Thu, 30 Apr 2020 02:15:48 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4F2E93A0C5A for ; Thu, 30 Apr 2020 02:15:48 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id gr25so4065438ejb.10 for ; Thu, 30 Apr 2020 02:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PtJ8Y5t/uc1KMCEev/xmVfpWJ9Q+yE/eBSH6qJSO//s=; b=Udjm/CobZca8comyFOAKP7LCe+usUasSbXRcq7bPo0TGmRAiHqdg2hrRphmpPpqnQ4 Q22tgyoTQNAPwnV0nKofKoBqUXo1Jb4ntg6hTWp1GkxPvjBXthBbhhKY7n4r43smrs1G CXftk3LhKI7NuzN9LTogOnjXlYlGWRFrRzuETqvVhtG1e3OYj1JmqhAobPUXFttRRKK9 sU792EwAY8hK8vEc2dV2KE/BytEPWfu4GYvz0pprUrlLH0XlNEhyBMquxvCU1lOVcPM7 jSqxxv/R76mbHdmKfdEHto6XTm1As1sdogPI1LNrq2ysIhs49O9+d2AHyV2GtKkw17P5 grpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PtJ8Y5t/uc1KMCEev/xmVfpWJ9Q+yE/eBSH6qJSO//s=; b=VEQvbjK0y+NGEA37UrMtWLDilJjlLgu8TyWRAHheuwYL/Jjn321iyFVF0HBlMEyfhw pxcmUgTw70RgN6gFQfIqJ+oRw+Xw8YbhOXNB2RqTzMVoG6JwuEPLc9bDLZgE0q+B8SqR 9DjtrLEJZw3Yd1hq60iyemsDkTSqUWZBKAhVFYJqfJuWMI2ARy93u9M9rmZa02mJU6uw ncEIn0ax5uknltY5zv2ArMdrcxuf2H8dyVkPGyCblWbl26P2KUsvc1ficvlwT7kTWeRc vlFbXB4ztdZ8dir8FA8rE5oRL+YVqQDdC6N5sYAHXBmhSLbOyS4TwiWbDDh4u23hDXAX r0Ow== X-Gm-Message-State: AGi0PuYWb0BvZJeRKyonAwizPLeO5UyrHfW0ZYIrpVZesU9AwTeEWsDd pcOg+yBbs/WXtskWfr10vCdyqQgtd9Rv45grYwNhPA== X-Google-Smtp-Source: APiQypK2FH3dmDiT0wW6Zn6nG+6nphdYbtrRdOKbnex7r/hDZCST1huTuvZt+PBt8KL1DzkE9lv8Cd5L1dc3lZxVYDA= X-Received: by 2002:a17:906:a418:: with SMTP id l24mr1805095ejz.362.1588238146279; Thu, 30 Apr 2020 02:15:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Thu, 30 Apr 2020 11:15:36 +0200 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: "Chengli (Cheng Li)" , "draft-ietf-spring-segment-routing-policy@ietf.org" , idr wg , SPRING WG , Fangsheng , stefano previdi Content-Type: multipart/alternative; boundary="000000000000873daa05a47e8205" Archived-At: Subject: Re: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 09:15:51 -0000 --000000000000873daa05a47e8205 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chengli and Ketan, Well I think (perhaps to your surprise) the current text is actually correct. See the overall idea of section 2.4 is not to define the real source of the candidate path. That is done in section 2.5 The idea here is to keep multiple *paths or versions* of the candidate paths in the local system uniquely. See if you continue reading section 2.6 demystifies the real objective: The tuple uniquely identifies a candidate path. So the real originator is encoded in discriminator and here it just means the peer candidate path was received from. And if you read on this entire exercise only servers best path selection as described in section 2.9. .... the following order until only one valid best path is selected: 1. Higher value of Protocol-Origin is selected. 2. If specified by configuration, prefer the existing installed path. 3. Lower value of originator is selected. 4. Finally, the higher value of discriminator is selected. + The originator allows an operator to have multiple redundant controllers and still maintain a deterministic behaviour over which of them are preferred even if they are providing the same candidate paths for the same SR policies to the headend. Thx, R. On Thu, Apr 30, 2020 at 10:46 AM Ketan Talaulikar (ketant) wrote: > Hi Cheng, > > > > I assume you are recommending the use of Route Origin Extended Community = ( > https://tools.ietf.org/html/rfc4360#section-5) for conveying the > =E2=80=9COriginator=E2=80=9D when the SR Policy update is propagated over= eBGP sessions via > other eBGP/iBGP sessions instead of direct peering with the headend. > > > > I believe it does address the scenario you describe given that it is > expected that SR Policy propagation via BGP is happening within a single > administrative domain even if it comprises of multiple ASes. > > > > Also copying the IDR WG for inputs since this would likely need to be > updated in draft-ietf-idr-segment-routing-te-policy. > > > > Thanks, > > Ketan > > > > *From:* spring *On Behalf Of *Chengli (Cheng Li= ) > *Sent:* 30 April 2020 07:34 > *To:* draft-ietf-spring-segment-routing-policy@ietf.org > *Cc:* SPRING WG ; huruizhao ; > Fangsheng > *Subject:* [spring] Comments: Route Origin Community in SR > Policy(draft-ietf-spring-segment-routing-policy) > > > > Hi authors, > > > > In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], > introduced how the node-address of "Originator of CP(Candidate Path)" is > generated when the Protocol-Origin is BGP. It says: > > =E2=80=9CProtocol-Origin is BGP SR Policy, it is provided by the BGP = component > on the headend and is: > > o the BGP Router ID and ASN of the node/controller signalling the > candidate path when it has a BGP session to the headend, OR > > o the BGP Router ID of the eBGP peer signalling the candidate path > along with ASN of origin when the signalling is done via one or more > intermediate eBGP routers, OR > > o the BGP Originator ID [RFC4456] and the ASN of the > node/controller when the signalling is done via one or more > route-reflectors over iBGP session.=E2=80=9D > > > > In the operator's network, in order to reduce the number of BGP sessions > in controller and achieve scalability, the controller only establishes eB= GP > peer with the RR. And the RR establishes iBGP peers with the headends. As > mentioned in the draft, the headend will use the RR's Router ID as the CP= 's > node-address (the signaling is done via route transmission from RR to the > headend instead of route reflection). The headend needs to carry the CP'= s > key when reporting the SR Policy status to the controller through BGP-LS. > And there is a problem that the controller may not recognize the key > because the node-address is generated by the RR node. > > > > For network robustness, two or more RRs are usually deployed. This will > introduce another problem.. When the same CP advertised by the controller > is delivered to the headend through different RRs, the headend cannot > distinguish whether it is the same CP because the node-address in the CPs= ' > key comes from different RRs. > > > > To solve these problems, We recommend carrying the Route Origin Communit= y > (defined in RFC 4360) directly when the controller advertises BGP routes. > In this way, the key of the CP is determined by the controller and will > not change during the advertisement of BGP routes. > > > > Thanks, > > Cheng > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --000000000000873daa05a47e8205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chengli and Ketan,

Well I think (per= haps to your surprise) the current text is actually correct.=C2=A0

See the overall idea of section 2.4 is not to define the r= eal source of the candidate path. That is done in section 2.5 The idea here= is to keep multiple *paths or versions* of the candidate paths in the loca= l system uniquely.=C2=A0

See if you continue readi= ng section 2.6 demystifies the real objective:=C2=A0

   The tuple <Pro=
tocol-Origin, originator, discriminator> uniquely
   identifies a candidate path.

So the real originator is encoded in disc=
riminator and here it just means the peer candidate=C2=A0path was 
received from. And if you read on this entire exercise only s=
ervers best path selection as described in section 2.9. 


.... the follow=
ing order until only one valid best path is selected:

   1.  Higher value of Protocol-Origin is selected.

   2.  If specified by configuration, prefer the existing installed
       path.

   3.  Lower value of originator is selected.

   4.  Finally, the higher value of discriminator is selected.
<=
/div>

+
      The originator allows an operator to have multiple =
redundant
      controllers and still maintain a deterministic behaviour over
      which of them are preferred even if they are providing the same
      candidate paths for the same SR policies to the headend.
<=
div>
Thx,
R.

On Thu, Apr 30, 2020 at 10:46 AM Ketan T=
alaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org> wrote:











Hi Cheng,


=C2=A0<=
/span>


I assume you are reco=
mmending the use of Route Origin Extended Community (https://tools.=
ietf.org/html/rfc4360#section-5)
 for conveying the =E2=80=9COriginator=E2=80=9D when the SR Policy update i=
s propagated over eBGP sessions via other eBGP/iBGP sessions instead of dir=
ect peering with the headend.


=C2=A0<=
/span>


I believe it does add=
ress the scenario you describe given that it is expected that SR Policy pro=
pagation via BGP is happening within a single administrative domain even if=
 it comprises
 of multiple ASes.


=C2=A0<=
/span>


Also copying the IDR =
WG for inputs since this would likely need to be updated in draft-ietf-idr-=
segment-routing-te-policy.


=C2=A0<=
/span>


Thanks,=



Ketan


=C2=A0<=
/span>



=C2=
=A0


=
Hi authors,


=
=C2=A0


=
In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced=
 how the node-address of "Originator of CP(Candidate Path)" is ge=
nerated when the Protocol-Origin is BGP. It says:


=
=C2=A0 =C2=A0 =E2=80=9CProtocol-Origin is BGP SR Policy, it is provided by =
the BGP component on the headend and is:


=
=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 the BGP Router ID and ASN of the node/cont=
roller signalling the candidate path when it has a BGP session to the heade=
nd, OR


=
=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 the BGP Router ID of the eBGP peer signall=
ing the candidate path=C2=A0 along with ASN of origin when the signalling i=
s done via one or=C2=A0 more intermediate eBGP routers, OR


=
=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 the BGP Originator ID [RFC4456] and the AS=
N of the node/controller=C2=A0 when the signalling is done via one or more =
route-reflectors over=C2=A0 iBGP session.=E2=80=9D


=
=C2=A0=C2=A0 


=
In the operator's network, in order to reduce the number of=C2=A0 BGP s=
essions in controller and achieve scalability, the controller only establis=
hes eBGP peer with the RR. And the RR establishes iBGP
 peers with the headends. As mentioned in the draft, the headend will use t=
he RR's Router ID as the CP's node-address (the signaling is done v=
ia route transmission from RR to the headend instead of route reflection).=
=C2=A0 The headend needs to carry the CP's key
 when reporting the SR Policy status to the controller through BGP-LS. And =
there is a problem that the controller may not recognize the key because th=
e node-address is generated by the RR node.


=
=C2=A0


=
For network robustness, two or more RRs are usually deployed. This will int=
roduce another problem.. When the same CP advertised by the controller is d=
elivered to the headend through different RRs,
 the headend cannot distinguish whether it is the same CP because the node-=
address in the CPs' key=C2=A0 comes from different RRs.



=
=C2=A0


=
To solve these problems,=C2=A0 We recommend carrying the Route Origin Commu=
nity (defined in RFC 4360) directly when the controller advertises BGP rout=
es.=C2=A0 In this way, the key=C2=A0 of the CP is determined
 by the controller and will not change during the advertisement of BGP rout=
es.


=C2=A0


=
Thanks,


=
Cheng






_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr




--000000000000873daa05a47e8205--


From nobody Thu Apr 30 03:55:36 2020
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 E7B223A0953; Thu, 30 Apr 2020 03:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 69qpmr6ioJYF; Thu, 30 Apr 2020 03:55:04 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 595933A0942; Thu, 30 Apr 2020 03:55:01 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id g13so6291434wrb.8; Thu, 30 Apr 2020 03:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=H5vq11Ck3ue0DR2YM9QSrN+S/VmVrtsMbdxAUnukLhY=; b=bf+YStx8qiY2hrDJUlBjM6VPGEkM9RCpFMJFWrN8oD/0mUUEnoU7ZLWfw3T9kFKxsY yW3Mr8UXxVIu3p+55Q9OIXcwTZa/bRCmZ1IH8oKR7O5Utu+1mgAFgayuXsetLsuP5QZ6 z5zrkSBGHsv1zM2uWMZVEod0mcwMzf+Cnex+KJSaSxP04/JVlu2zYKTH+Dzc4V1hwiRo ebmyA34eugldtFYRT1oqyzb4o1lnL1N2Bqqcc5O14uZcLK0iNf69FIEhki53lirWIct5 w3BnsEkeZC4TThEErv+Nhaupb+ynZZ4buDcu201Os/h4zeQe8Xcg3iaOLiwLKZa+xZ5Q IQlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=H5vq11Ck3ue0DR2YM9QSrN+S/VmVrtsMbdxAUnukLhY=; b=Z3ltq8cVpceYHbSuOBoaiIadT8BsZHvp/gIzOTNNhe5DasJHq5ZCi4ACUr4uta2lkn y8rVT2my79Ov3Ff/FzBq3Jp48zcjejGBklFJi4/keZv8ejFwXrLs4vEK/k/E+2q5jE8k gD+Wb1jwAd+gPt5cfS9+aAH/xuqfJVZXLUpRHt5Ek3lvAnR3u6ikgNvHf9ndZvrbYYWl rvZwSZiUS7+SegOvdsxviD1hKZ8lwPTG5TUenxgDh0wW2I8R9wlXf3TBnFvLg2umuRIR Kb1KXYqtEpc8dPlRFgbe4xXXHVocqZbbwJTv1OibHZxFWI1Iw3rvwh/G8JpC8AcORUO2 tT2Q==
X-Gm-Message-State: AGi0PuYRWZxcNM0D9QDTaLHIsQhQsRlGKBZgk/Ezt2A1LDMd48QYVF22 7YKzb7bfoKioWATnoAndEUJ+HxmvVXDr7/C5DzVI9+H9
X-Google-Smtp-Source: APiQypI8zB9jeBL/9dYsyKFv67nURvFg0a1ulIbTP42KTxYJH0HKTNF3EkJRzemmlVOk9Ci+5y03DmgZlKDS5bw/eqg=
X-Received: by 2002:adf:9793:: with SMTP id s19mr3022940wrb.147.1588244099503;  Thu, 30 Apr 2020 03:54:59 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 30 Apr 2020 03:54:58 -0700
From: Alvaro Retana 
In-Reply-To: <158793289621.976.611584354541089569@ietfa.amsl.com>
References: <158793289621.976.611584354541089569@ietfa.amsl.com>
MIME-Version: 1.0
Date: Thu, 30 Apr 2020 03:54:58 -0700
Message-ID: 
To: Theresa Enghardt , John Scudder 
Cc: last-call@ietf.org, gen-art@ietf.org, idr@ietf.org,  draft-ietf-idr-capabilities-registry-change.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Idr] Genart last call review of draft-ietf-idr-capabilities-registry-change-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 10:55:07 -0000

On April 26, 2020 at 4:28:18 PM, Theresa Enghardt wrote:


Theresa: =C2=A0Hi! =C2=A0Thanks you for the review!

John: =C2=A0Please make the changes below before the document is discussed
by the IESG.


Thanks!!

Alvaro.


...
> Regarding the code points that are now assigned as "First Come First Serv=
e"
> in Section 3, the document points to drafts for some of them, but not for
> all. Is there any documentation for the code points that are currently
> without any reference? If so, please provide a reference. If not, maybe i=
t's
> worth briefly stating that for some of them there is no reference and tha=
t
> they are all deprecated, e.g., because they were used in past experiments=
.

Yes -- for consistency they should either all include a reference
(which is available) or not. =C2=A0Because of their nature, I would rather
if all just pointed to "(this document)" to avoid confusion with
continued work.

BTW, we should also be consistent in the "prestandard" tagging: add
the tag to the 185 entry.


> For code point 129, a reference to a draft is provided in the "Descriptio=
n"
> column, while for code point 185, a reference to a draft is provided in t=
he
> "Reference / Change Controller" column. Is this intentional? If not, plea=
se
> consider unifying the presentation here. Otherwise, please consider makin=
g
> clear why the references are in different columns.

s/draft-li-idr-flowspec-rpd/Routing Policy Distribution


From nobody Thu Apr 30 04:14:23 2020
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 A05453A09D9; Thu, 30 Apr 2020 04:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 Ojk28hXI4g5C; Thu, 30 Apr 2020 04:14:19 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 7EE563A09D8; Thu, 30 Apr 2020 04:14:18 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id x25so1393600wmc.0; Thu, 30 Apr 2020 04:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=QBvICIvudjIapJMF7w2M2fb2JiBF+Unhv1od5sx0l48=; b=ramHJLFkJq2Pys7XMwLbV1LFliO4PKsaKEBb2/bP5KKI1J6PUqUiV8w2PuQUtkXyCP ZY38JAZAFhqvASEzjwO8xDNFrQ1xjAsH73TrM903I/raZ8zakZZMELqkKcpNYwMdIltd xUN6oDPo1L71qUFN6s/3E46hn1n9808dZLu4ION3ObR4N8iDbEsHR3c1enSGzVwgy7Wh juQMUww44gNsitqW4F/6QnuzlTid2ce6zRUiDLdwDTatJjS0mpkDqFoQ06EHkEHGtrNm z4tCm5w41rrWr1T4c7FOAOFGT5GkWtD+xhoXIJmxDPu6o/q6XN1+qz3vznuVWxFVtk5O gaxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=QBvICIvudjIapJMF7w2M2fb2JiBF+Unhv1od5sx0l48=; b=PSfoD53zfMbL7HaGA++bhJhzp4gb1llTeyWUBUPDKf3V155iUR98ve3fBZh1fD9jmG kKCjFz5KHYtpp0h/qNiVWPkoPmA2LgJPEohzktRfDorcwCktGJ2SJUbuoOZVka0+22o6 /VwZ7mASUo92yJ33M0jJYz8/7PhuTgu9WuBqSOJ1epeSuPhH4ctK/kW83Y564gpvWNLJ N/GAaw6Vui3d+4gKsVJiTqCTM+ivV27I+xP1VCFPZJXVuWa8HVno1vSDXLWzR6m8oWoI XmbK3JVOWK99d+UGhR5TuUKARskNlw6Q3s5vUEoDXBWQM5Y82hf8yTmJNqF1wXKrt9fF ulGg==
X-Gm-Message-State: AGi0Pub4LPG93tosFe09W9SnnX+Ceaz/1oKOCfU0HH2RpwAqirUR0kBt Dcmpd69SKq65WxlsNjtHXkanHEG24L4MM/am8Oo=
X-Google-Smtp-Source: APiQypLmyiA1JNNTaRbN8zI9mQTfg9NuKfOmHm2lB0tiygeLWn4jAD3u6Xn5gUCY+uPoWR4HsBxhAo/GtGkhlc+Nfx0=
X-Received: by 2002:a05:600c:1:: with SMTP id g1mr2386460wmc.142.1588245257057;  Thu, 30 Apr 2020 04:14:17 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 30 Apr 2020 04:14:16 -0700
From: Alvaro Retana 
In-Reply-To: <20200430024817.GE28692@pfrc.org>
References: <14293c9f9c2e41219a13f09adacb6289@huawei.com> <20200430024817.GE28692@pfrc.org>
MIME-Version: 1.0
Date: Thu, 30 Apr 2020 04:14:16 -0700
Message-ID: 
To: Jeffrey Haas , "Dongjie (Jimmy)" 
Cc: "Kirill.Kasavchenko@netscout.com" ,  "jhaas@juniper.net" , "idr-chairs@ietf.org" ,  "thomas.mangin@exa.net.uk" , IDR List 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 11:14:21 -0000

On April 29, 2020 at 10:41:32 PM, Jeffrey Haas wrote:


Jeff:

Hi!


...
> The pattern we normally want to see is "MUST be set to zero and SHOULD be
> ignored on receipt".
>
> By requiring it to be set, you have expectations for a compliant
> implementation of a given draft.
>
> By ignoring it on receipt, you permit the field to be used for something
> further in the future.
>
> The above is consistent with Postel's Maxim.

That makes sense.



> With regard to Juniper's implementation:
> - In sections 4.2.1.1 and 4.2.1.2 for operators, we originate zeroes when
> generating new NLRI in the reserved bits and we ignore them on receipt.
> However, we also propagate what we are sent and use when we're not the
> originator of that NLRI.

To make sure I understand: if 0s are not received, you ignore the
value and process the NLRI.

Does this behavior also apply to =C2=A74.2.2.12 (Fragment)?


Thanks!

Alvaro.


From nobody Thu Apr 30 04:23:39 2020
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 E5FA63A0A06; Thu, 30 Apr 2020 04:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gmL_-1Lb7-l; Thu, 30 Apr 2020 04:23:35 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 36C683A0A02; Thu, 30 Apr 2020 04:23:27 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 71E071E2D6; Thu, 30 Apr 2020 07:30:34 -0400 (EDT)
Date: Thu, 30 Apr 2020 07:30:34 -0400
From: Jeffrey Haas 
To: Alvaro Retana 
Cc: "Dongjie (Jimmy)" , "Kirill.Kasavchenko@netscout.com" , "jhaas@juniper.net" , "idr-chairs@ietf.org" , "thomas.mangin@exa.net.uk" , IDR List 
Message-ID: <20200430113034.GG28692@pfrc.org>
References: <14293c9f9c2e41219a13f09adacb6289@huawei.com> <20200430024817.GE28692@pfrc.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 11:23:37 -0000

Alvaro,

On Thu, Apr 30, 2020 at 04:14:16AM -0700, Alvaro Retana wrote:
> On April 29, 2020 at 10:41:32 PM, Jeffrey Haas wrote:
> > With regard to Juniper's implementation:
> > - In sections 4.2.1.1 and 4.2.1.2 for operators, we originate zeroes when
> > generating new NLRI in the reserved bits and we ignore them on receipt.
> > However, we also propagate what we are sent and use when we're not the
> > originator of that NLRI.
> 
> To make sure I understand: if 0s are not received, you ignore the
> value and process the NLRI.

At the risk of getting into further English ambiguity, we do not use the
contents of the fields but preserve them.

This detail is particularly important vs. BGP (or other protocol) features
since sometimes an implementation will discard the ignored value on
propagation.  It causes all sorts of interesting interop bugs. :-)

> Does this behavior also apply to §4.2.2.12 (Fragment)?

I'm personally unable to confirm that detail right now.  The full set of
code leaves BGP land and goes deep enough into our firewall implementation
that I can't follow it.

And that said, once I get an answer from the group one way or the other,
we'd be aiming for "ignore the MBZ fields".

A discussion point that was held across the 5575 endeavor is that we SHALL
find implementations that are not fully compliant with various details of
the draft.  This isn't because it's on purpose.  It's simply that we're
cleaning up a lot of edge cases and implementations will take time to come
into compliance.  This is a feature, not a bug of our process.

-- Jeff


From nobody Thu Apr 30 15:01:47 2020
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 2CFB53A0593; Thu, 30 Apr 2020 15:00:38 -0700 (PDT)
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.128.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: idr@ietf.org
Message-ID: <158828403789.18630.9451175948153544792@ietfa.amsl.com>
Date: Thu, 30 Apr 2020 15:00:38 -0700
Archived-At: 
Subject: [Idr] I-D Action: draft-ietf-idr-capabilities-registry-change-08.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 22:00:40 -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           : Revision to Capability Codes Registration Procedures
        Author          : John Scudder
	Filename        : draft-ietf-idr-capabilities-registry-change-08.txt
	Pages           : 5
	Date            : 2020-04-30

Abstract:
   This document updates RFC 5492 by making a change to the registration
   procedures for BGP Capability Codes.  Specifically, the range
   formerly designated "Reserved for Private Use" is divided into three
   new ranges, respectively designated as "First Come First Served",
   "Experimental Use" and "Reserved".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-capabilities-registry-change-08
https://datatracker.ietf.org/doc/html/draft-ietf-idr-capabilities-registry-change-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-capabilities-registry-change-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/



From nobody Thu Apr 30 15:02:03 2020
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 B3DCD3A141D; Thu, 30 Apr 2020 15:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=ANxtJwiR; dkim=pass (1024-bit key) header.d=juniper.net header.b=V4ueO4S+
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 0oOoye2NlBI3; Thu, 30 Apr 2020 15:01:04 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B6B3A0598; Thu, 30 Apr 2020 15:01:04 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03ULw76R009723; Thu, 30 Apr 2020 15:01:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=ksuRSAukIz9ZmD+/B1/3zwLyraldHmTVlGOdQ8gbJrQ=; b=ANxtJwiR6wkfi8Rv+PA3FD1PeX3HINzMCQDlvvuQuJlvutMN4FyRBc9mNvNwIQ8GBLXw AGkILrbDvqvZJpjxajkrX2fP76Tc8h/nl/NiQlwps5MZwwlFoY4koiiX/8PTJCxc2fDu XpcnxeNgksCBoQn9zIf1A1Mmb2Ju/jI9tqaMt84YPXMW1wIdY6avwgOh/t+UrxLV1w5k B4F+fHrmEd40aE2RlXxIchW96sc2bMBCdVeNcFWcGRyhU2MhOhsmx22fI7n7VBOuUey4 lCkVGJssWA9JagaSY4cBqMsl9SNVogPs4Guj4jhXbmGlvfmrbfqNok1OWsTljp4cLrTT aw== 
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2107.outbound.protection.outlook.com [104.47.58.107]) by mx0b-00273201.pphosted.com with ESMTP id 30qb1su25x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Apr 2020 15:01:03 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S5FG2preWTwc/0fXxJVQonvxyytGVwryPc+ckLMR2VuWGvFpUBi+EBWNPLyak1zKAtXRB7q14seHBS9gqVF6UnHtgakVmyyE0eLc1mUmYlUUlqwb6PAYSZO6CjjAKK7iT7hXZktHX34NNB+gikHSmmKCbNZkTwGQTy6mPoCnzukcpN9iPxRebfrqesU3hVT5jBa/uA5LuFDz99ca6VvwwcafTspkXY5KD/kqPJamWBq60KOpnvUqoldUijWBpFbPnGJzFqzOO+3R7p7jz9mNjHtsBCxOV9xrMZtxSC0P9D9662L8i1CEaAXU68ITBacaOm+HUaXl7gQ9v4RCAM+Mow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ksuRSAukIz9ZmD+/B1/3zwLyraldHmTVlGOdQ8gbJrQ=; b=Zg/q7b4mBPL5l7Sj3r/2qJVI4EWcK0agHr8im9LRgXzqUAwqj37dnsxedro+l3yDacamqoLF8fLLFQRdfNKhtxMyVVUo1EKTEr5uSq7H1gXUsrBKO8+QDw4SvuyZc0rfQegWsgy3AYYt9/yQ/8a3z9yYnv76e5OD9yjZIs99We4A+r7avnZNOu8drJJnb3+AhAb2YXmnIDq5ERX58mGM4Vum6sSoQNjYcn90T4PjavMbFgkTTayWfUxX7DqYXcCBkYHqcgUs/R8zHaSa/5Al4mgP5jLt4nZo0wb3xPvPDyL0RrMGLrjHfqWEkJwYw7sOwNHEPS672mG9X+0LIpIkng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ksuRSAukIz9ZmD+/B1/3zwLyraldHmTVlGOdQ8gbJrQ=; b=V4ueO4S+SkPGk07EfcNEoBlNSFNBS0V1ukDVCq2BPAPcBAkJsFaGAJDc1O2cYxD33Aa1uck++ROgkJarkiMr91DZ9Ue2mI1/50bOAFXCixK50rmbMh7emAcyiVVpyscK/kACO56GcSTgStJSEtTiScOuV3OyuhFp52gVec92/7E=
Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB5633.namprd05.prod.outlook.com (2603:10b6:208:6e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.8; Thu, 30 Apr 2020 22:00:58 +0000
Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::d450:6f4c:4c28:b45f%7]) with mapi id 15.20.2958.014; Thu, 30 Apr 2020 22:00:58 +0000
From: John Scudder 
To: Alvaro Retana 
CC: Theresa Enghardt , "last-call@ietf.org" , "gen-art@ietf.org" , "idr@ietf. org" , "draft-ietf-idr-capabilities-registry-change.all@ietf.org" 
Thread-Topic: Genart last call review of draft-ietf-idr-capabilities-registry-change-07
Thread-Index: AQHWHAk75ZAJ7AKCd0+g8f3zWYvwt6iRg4EAgAC6FAA=
Date: Thu, 30 Apr 2020 22:00:58 +0000
Message-ID: <2DFA4CC4-0ABD-43B1-BF49-714260E0784F@juniper.net>
References: <158793289621.976.611584354541089569@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.80.23.2.2)
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 039c4a54-38e5-4335-23e3-08d7ed51f6e5
x-ms-traffictypediagnostic: BL0PR05MB5633:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0389EDA07F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: l/9wddoeOZNDJ837UIOH/o8TO3xDqU0hSLWQ82K+AChITaVSvUDLISBWmkez8N63zZj0tFw3eLZIdzSWs8RCPklSCzFemluKcgxiePO8LCA1ZoNVUo6srPPdN9YGGWI/6JPLgHYUJq+1LfWY0YZ8cZlD84Kwh1e/dQCz0dVBUMUqeBvHqIl5uc0C3VH2yvRjUFbLNQqqZ4WLtvN+4ZICg94lclvc1M3ZpPHwZzG8PcbTJlIsef1LE7t8gY4naZbv/SBT6pjlAH5ivaMpy92XNqq5UP+bteIZtneUjADe1cPABgaW5I5IEOfXwZ35/OIoZP7zsW81v+/YIVFQ3uolq34TxV+vJS1ra2cJavOmyylqcJKbe480AXEigm8PiUohZz7zy4EU8513iBXkpPip3dDQ0PmskBQhczL5bgMXR/C/uUSk9b4t9ww0IiydSnls
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(346002)(396003)(376002)(66946007)(8676002)(6916009)(316002)(66556008)(2616005)(54906003)(64756008)(33656002)(66446008)(478600001)(6486002)(186003)(6506007)(66476007)(26005)(86362001)(71200400001)(4326008)(53546011)(76116006)(6512007)(5660300002)(2906002)(8936002)(36756003); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: uhsdUp1eoMO7dEIfuMC7CnLzRHN+oTPAbJ3IFJ5KO4ZYQN+oYa5ceT9sbKVBHQ6U5xSm1kZRU8D4oVJbPNlNslqswOcNV+ET+cUefLzIGTOmQyJ9PJ1vHFIwhzDrq5DD0VjuUxnEK1+KT69/hOiD903M2cgvOs1M7tJJPVctC/sgeesAcrCwqAtjjbb9GPCHgl47RJMBAq2r1d0tr+rjzwG3DY9i8TBvytIT/8X85lk3QU6+TkXW2s6OTy6gCdyb86SveD4MZK3wYg8hFWb88k9Ouh9HAKwPV1l5CgoIUho5q158ZioHWoyOKhgjtkuv2vaaNW33cGEehrtGwiHIGkGeCOqtjUvGxUS+PjMKTYr96UlMYv8icNJP6pCZZ/WD7ohG4uPULtzAMzEPNk3BB6tLjPVINgTTBNbDk+nucQXnGYNF0wNO8qxeZ6O+OJNnCCG8nMakD4K7njsONMDmc1LWv5pkMZYQmALq3dG+Vc9pgOACHzQWp9q1mMFjkZ65G2GfyMktQ+9VcIqokaVj55/5cTRvo0FepyZJIHpnItm9o3JDS2FbItBxpECGTF0ONG0QrJGJ0i1iktmQUufmK1nwuW5Pk7RnV/mfnrL/Sc7ZE6yRd8f6wjrYZWGWNkE0ZA9C3b+iCH7bdEG+AGzGf/Sp4LJn78NMvhR0NVts0WDL+c5Hi5g1kgmBDzKPRgnp3YH2BAFoVUIKtT+o8wP+75w6vqTj5M71rX4ah65z3KLGFq7LflpOh4vaSz3VttVqBpE+LBp/MqrAJ6Au3XW2BNZf4E+HYHQVga3S4plSqC4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 039c4a54-38e5-4335-23e3-08d7ed51f6e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 22:00:58.5581 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YMCndGpSd8+/2MWy91us4IPP2NzHXqv8u3smmPqxYqYx4PizxKV+GGBPTuLwiIMe
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5633
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-30_13:2020-04-30, 2020-04-30 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 priorityscore=1501 clxscore=1011 adultscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004300162
Archived-At: 
Subject: Re: [Idr] Genart last call review of draft-ietf-idr-capabilities-registry-change-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 22:01:09 -0000

SGkgQWx2YXJvLA0KDQpJ4oCZdmUganVzdCB1cGxvYWRlZCAtMDggd2l0aCB5b3VyIHJlcXVlc3Rl
ZCBjaGFuZ2VzLCBhbHNvIHdpdGggdGhlIGV4dHJhIGV4cGxhbmF0b3J5IGludHJvZHVjdGlvbiB0
ZXh0IFRoZXJlc2Egc3VnZ2VzdGVkICh0aGFua3MhKS4NCg0K4oCUSm9obg0KDQo+IE9uIEFwciAz
MCwgMjAyMCwgYXQgNjo1NCBBTSwgQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNv
bT4gd3JvdGU6DQo+IA0KPiBbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRd
DQo+IA0KPiANCj4gT24gQXByaWwgMjYsIDIwMjAgYXQgNDoyODoxOCBQTSwgVGhlcmVzYSBFbmdo
YXJkdCB3cm90ZToNCj4gDQo+IA0KPiBUaGVyZXNhOiAgSGkhICBUaGFua3MgeW91IGZvciB0aGUg
cmV2aWV3IQ0KPiANCj4gSm9objogIFBsZWFzZSBtYWtlIHRoZSBjaGFuZ2VzIGJlbG93IGJlZm9y
ZSB0aGUgZG9jdW1lbnQgaXMgZGlzY3Vzc2VkDQo+IGJ5IHRoZSBJRVNHLg0KPiANCj4gDQo+IFRo
YW5rcyEhDQo+IA0KPiBBbHZhcm8uDQo+IA0KPiANCj4gLi4uDQo+PiBSZWdhcmRpbmcgdGhlIGNv
ZGUgcG9pbnRzIHRoYXQgYXJlIG5vdyBhc3NpZ25lZCBhcyAiRmlyc3QgQ29tZSBGaXJzdCBTZXJ2
ZSINCj4+IGluIFNlY3Rpb24gMywgdGhlIGRvY3VtZW50IHBvaW50cyB0byBkcmFmdHMgZm9yIHNv
bWUgb2YgdGhlbSwgYnV0IG5vdCBmb3INCj4+IGFsbC4gSXMgdGhlcmUgYW55IGRvY3VtZW50YXRp
b24gZm9yIHRoZSBjb2RlIHBvaW50cyB0aGF0IGFyZSBjdXJyZW50bHkNCj4+IHdpdGhvdXQgYW55
IHJlZmVyZW5jZT8gSWYgc28sIHBsZWFzZSBwcm92aWRlIGEgcmVmZXJlbmNlLiBJZiBub3QsIG1h
eWJlIGl0J3MNCj4+IHdvcnRoIGJyaWVmbHkgc3RhdGluZyB0aGF0IGZvciBzb21lIG9mIHRoZW0g
dGhlcmUgaXMgbm8gcmVmZXJlbmNlIGFuZCB0aGF0DQo+PiB0aGV5IGFyZSBhbGwgZGVwcmVjYXRl
ZCwgZS5nLiwgYmVjYXVzZSB0aGV5IHdlcmUgdXNlZCBpbiBwYXN0IGV4cGVyaW1lbnRzLg0KPiAN
Cj4gWWVzIC0tIGZvciBjb25zaXN0ZW5jeSB0aGV5IHNob3VsZCBlaXRoZXIgYWxsIGluY2x1ZGUg
YSByZWZlcmVuY2UNCj4gKHdoaWNoIGlzIGF2YWlsYWJsZSkgb3Igbm90LiAgQmVjYXVzZSBvZiB0
aGVpciBuYXR1cmUsIEkgd291bGQgcmF0aGVyDQo+IGlmIGFsbCBqdXN0IHBvaW50ZWQgdG8gIih0
aGlzIGRvY3VtZW50KSIgdG8gYXZvaWQgY29uZnVzaW9uIHdpdGgNCj4gY29udGludWVkIHdvcmsu
DQo+IA0KPiBCVFcsIHdlIHNob3VsZCBhbHNvIGJlIGNvbnNpc3RlbnQgaW4gdGhlICJwcmVzdGFu
ZGFyZCIgdGFnZ2luZzogYWRkDQo+IHRoZSB0YWcgdG8gdGhlIDE4NSBlbnRyeS4NCj4gDQo+IA0K
Pj4gRm9yIGNvZGUgcG9pbnQgMTI5LCBhIHJlZmVyZW5jZSB0byBhIGRyYWZ0IGlzIHByb3ZpZGVk
IGluIHRoZSAiRGVzY3JpcHRpb24iDQo+PiBjb2x1bW4sIHdoaWxlIGZvciBjb2RlIHBvaW50IDE4
NSwgYSByZWZlcmVuY2UgdG8gYSBkcmFmdCBpcyBwcm92aWRlZCBpbiB0aGUNCj4+ICJSZWZlcmVu
Y2UgLyBDaGFuZ2UgQ29udHJvbGxlciIgY29sdW1uLiBJcyB0aGlzIGludGVudGlvbmFsPyBJZiBu
b3QsIHBsZWFzZQ0KPj4gY29uc2lkZXIgdW5pZnlpbmcgdGhlIHByZXNlbnRhdGlvbiBoZXJlLiBP
dGhlcndpc2UsIHBsZWFzZSBjb25zaWRlciBtYWtpbmcNCj4+IGNsZWFyIHdoeSB0aGUgcmVmZXJl
bmNlcyBhcmUgaW4gZGlmZmVyZW50IGNvbHVtbnMuDQo+IA0KPiBzL2RyYWZ0LWxpLWlkci1mbG93
c3BlYy1ycGQvUm91dGluZyBQb2xpY3kgRGlzdHJpYnV0aW9uDQoNCg==


From nobody Thu Apr 30 16:51:41 2020
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 4E23D3A1689; Thu, 30 Apr 2020 16:51:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker 
To: "The IESG" 
Cc: draft-ietf-idr-capabilities-registry-change@ietf.org, idr-chairs@ietf.org,  idr@ietf.org, Susan Hares , aretana.ietf@gmail.com, jgs@juniper.net, shares@ndzh.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.128.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke 
Message-ID: <158829067587.20254.11019177115301288258@ietfa.amsl.com>
Date: Thu, 30 Apr 2020 16:51:16 -0700
Archived-At: 
Subject: [Idr] Martin Duke's No Objection on draft-ietf-idr-capabilities-registry-change-08: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2020 23:51:17 -0000

Martin Duke has entered the following ballot position for
draft-ietf-idr-capabilities-registry-change-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In section 3, it would be nice to have a sentence about the motivation for the new registry entries.

Should 255 be in table 1 as well as table 2?
Hi Jim,

Yes the topic is related to how= multiple ASes under one administrative umbrella can operate BGP.=C2=A0

But I must say that there are two fundamental approac= hes:=C2=A0

a) the one as you described=C2=A0in the= OAD draft defining the=C2=A0ATTR_SET_STACK attribute - sort of being an Ei= ffle Tower of what needs to be carried across.=C2=A0

b) the other option is to decouple the problem into two sub functions:= =C2=A0
=C2=A0 =C2=A0 =C2=A0b.1 - make those ASNs operating under = same administration aware of each other by cfg
=C2=A0 =C2=A0 =C2= =A0b.2 - make new transitive rule to allow passing under same administratio= n.=C2=A0

I just proposed b.=C2=A0

Jakob proposed c) which is yet one more option to define set of re= served values (could be ASN or a prefix for easy ACL) to indicate within gi= ven attribute the scope of propagation when=C2=A0ingress policy allows. I f= ind it much more complex=C2=A0and error prone as compared with (b)

Thx,
R.







On Wed, Apr 8, 2020 at 4:53= PM UTTARO, JAMES <ju1738@att.com&= gt; wrote:

Not sure if the intention here intersects with what I had in mind in 20= 12.. Pradosh, Saikat and I created a draft that introduced the notion of OA= D ( One Administrative Domain ). The challenge from my point of view was and still is how to treat non-transitive attribu= tes as transitive across the set of AS domains that =E2=80=9Cbelong=E2=80= =9D to the same administrative domain. An example of this is the applicatio= n of Local-Pref across a set of disparate As domains that a customers VPN spans.

=C2=A0

We are tackling a similar problem when spanning AS domains that are ref= lective of differing services.. i.e =C2=A0a customer VPN spans EVPN and 254= 7 signaling domains.

=C2=A0

https://tools.ietf.org/html/draft-uttaro-idr-oad-01

=C2=A0

https://tools.ietf.org/html/draft-ietf-bess-e= vpn-ipvpn-interworking-02

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Jim Uttaro

=C2=A0

From: Idr <idr-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Wednesday, April 08, 2020 10:41 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: idr@ietf. org <idr@ietf.org>
Subject: [Idr] XXCs

=C2=A0

Hey Jakob,=C2=A0

=C2=A0

So just an idea - if we are to redefine transitivity= for XXC why don't we forget about all of this ASN reservations and sim= ply instead of two transitive bits define three.=C2=A0

=C2=A0

Make 3rd bit to mean transitive only under set=C2=A0= of=C2=A0ASes=C2=A0under same administrative=C2=A0control ?=C2=A0<= /u>

=C2=A0

You still need a knob to know which ASNs are to be t= reated as same administration. And with that no change to community syntax= =C2=A0 is needed at all - LOCAL_ASN:NUMBER

=C2=A0

Done !=C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

--000000000000a3634905a2c8db14-- From nobody Wed Apr 8 09:02:55 2020 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 1936B3A0C9C for ; Wed, 8 Apr 2020 09:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.347 X-Spam-Level: * X-Spam-Status: No, score=1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 62S_ip1dkeA3 for ; Wed, 8 Apr 2020 09:02:52 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 F33883A0C93 for ; Wed, 8 Apr 2020 09:02:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <008901d60da2$74031370$5c093a50$@ndzh.com> In-Reply-To: Date: Wed, 8 Apr 2020 12:02:48 -0400 Message-ID: <00c501d60dbf$26a17b40$73e471c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01D60D9D.9F935DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJSXj8xSpKU3KWOYHHPr+fE+FRy4gF9kCecp2rUGyA= Content-Language: en-us X-Antivirus: AVG (VPS 200407-0, 04/07/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] status - incremental 4/8/2020 - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 16:02:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C6_01D60D9D.9F935DB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Acee: =20 My understanding is that the authors need to address the issues that = Alvaro raised. See email on the subject on 2/21/2019.=20 =20 Keyur said he would get on it on 2/21. Life may be challenged. The = other option is to Ping Gunter or Sri. I=E2=80=99ll ping them again = today. =20 =20 Maybe it will raise the urgency and they can deal with it while we are = offline=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, April 8, 2020 9:00 AM To: Susan Hares; idr@ietf.org Subject: Re: [Idr] status - incremental 4/8/2020 - =20 Hi Sue,=20 One clarification=E2=80=A6=20 =20 From: Idr on behalf of Susan Hares = Date: Wednesday, April 8, 2020 at 8:40 AM To: IDR List Subject: [Idr] status - incremental 4/8/2020 - =20 IDR WG: =20 A little status to read with your coffee this morning. We have an = interim at 13:00 UTC (9:00 EDT, 6:00 PDT, 21:00 Bejing time)=20 =20 Please let me know if I=E2=80=99ve missed any updates.=20 =20 Cheers, Sue=20 =20 --------- At IESG in IETF LC=20 1) draft-ietf-idr-rfc5575bis-19.txt =E2=80=93=20 Shepherd: John Scudder=20 Status: IETF LC ended, IESG telechat: 4/15=20 IESG Publication request: 7/9/2019=20 2 AD Reviews [8/2-9/10/2019, [1/17-1/23/2020] =20 2) draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt [Shepherd: Susan Hares] Status: 3rd round of AD revisions =20 IESG Publication requested: 10/15/2019 IETF WG LC: 6 days =20 =20 -------------- AD review =E2=80=93 authors need to respond=20 1) = draft-ietf-idr-tunnel-encaps-14 - sent to IESG=20 [Waiting 47 days]=20 =20 So, this draft requires a response from the authors to Alvaro? It = hasn=E2=80=99t gone to full IESG yet =E2=80=93 right? We have a couple = LSR drafts with a normative reference.=20 =20 Thanks, Acee =20 2) draft-ietf-idr-capabilities-registry-change-05.txt=20 [Waiting 57 days]=20 ------------ WG past WG LC =E2=80=93 stuck waiting for implementation reports on = wiki [reported to have 2 implementations, but no details on wiki]=20 =20 1) draft-ietf-idr-ext-opt-param 2) draft-idr-eag-distribution-09.txt=20 --------- Drafts stuck post WG LC =E2=80=93 waiting for minor edits=20 1) draft-ietf-idr-rfc8203bis.05.txt -=20 ---- Flow specification drafts in WG LC=20 =20 1) Draft-ietf-idr-flow-spec-v6-10.txt Status: restarted [4/8 to 4/22] Status: IESG desires, but is it ready?=20 Needed: implementation reports=20 =20 2) = draft-ietf-idr-bgp-flowspec-oid-11 Status: 3/13/ to 4/13=20 Status: light response, please comment=20 Authors: Please fill out implementation report=20 =20 ----------- WG Adoption calls:=20 =20 1) Draft-hujun-idr-bgp-ipsec WG adoption: 3/30-4/13 Shepherd: Susan Hares=20 Comment: only 1 response, heading toward =E2=80=9Cno = consensus=E2=80=9D =20 2) draft-hujun-idr-bgp-ipsec-transport-mode WG Adoption: 3/30 =E2=80=93 4/13 Shepherd: Susan Hares=20 Comment: only 1 response, heading toward =E2=80=9Cno = consensus=E2=80=9D =20 3) draft-li-idr-sr-policy-path-mtu-03.txt=20 WG adoption: 3/30 =E2=80=93 4/13=20 Shepherd: Susan Hares=20 Comment: Positive response: Heading toward WG Adoption=20 =20 Request for input: ---------------------- draft-scharf-tcpm-yang-tcp-04 =20 Proposed WG LC drafts for flow-specification that were on hold:=20 ------------------------------------------- [Authors should contact chairs]=20 =20 1) draft-ietf-idr-flowspec-interfaceset-05 =E2=80=93=20 WG notes indicated this might go ahead without flow-specification v2=20 =20 2) draft-ietf-idr-flowspec-path-redirect-10 =E2=80=93=20 WG discussion needs to occur on whether flowspecification=20 =20 =20 Proposed WG LCs (3/30 and 4/8)=20 ---------------- 1) draft-ietf-idr-bgp-open-policy-08 =E2=80=93 on hold pending revision = -09 2) draft-ietf-idr-flowspec-l2vpn-13 =E2=80=93 in slides for 4/8 =20 =20 Proposed Adoption calls =20 ----------------------- draft-cl-idr-bgp-ext-com-registry-udpate-00.txt =20 =20 =20 =20 =20 ------=_NextPart_000_00C6_01D60D9D.9F935DB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Acee:

 

My understanding is that = the authors need to address the issues that Alvaro raised. = =C2=A0=C2=A0=C2=A0=C2=A0See email on the subject on 2/21/2019. =

 

Keyur said he would get = on it on 2/21.=C2=A0 Life may be challenged.=C2=A0 =C2=A0=C2=A0The other = option is to Ping Gunter or Sri.=C2=A0=C2=A0 I=E2=80=99ll ping them = again today.=C2=A0=C2=A0

 

Maybe it will raise the = urgency and they can deal with it while we are offline =

 

Sue =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem = (acee)
Sent: Wednesday, April 8, 2020 9:00 AM
To: = Susan Hares; idr@ietf.org
Subject: Re: [Idr] status - = incremental 4/8/2020 -

 

Hi Sue, =

One clarification=E2=80=A6 =

 

From: Idr <idr-bounces@ietf.org> = on behalf of Susan Hares <shares@ndzh.com>
Date: = Wednesday, April 8, 2020 at 8:40 AM
To: IDR List = <idr@ietf.org>
Subject: [Idr] status - incremental = 4/8/2020 -

 

IDR WG:

 

A little status = to read with your coffee this morning.   We have an interim at = 13:00 UTC (9:00 EDT,  6:00 PDT, 21:00 Bejing time) =

 

Please let me = know if I=E2=80=99ve missed any updates.

 

Cheers, Sue =

 

---------

At IESG in IETF LC

1) draft-ietf-idr-rfc5575bis-19.txt =E2=80=93 =

    Shepherd: John Scudder =

    Status:  IETF LC ended, IESG telechat: = 4/15

    IESG Publication request: 7/9/2019 =

   2  AD Reviews [8/2-9/10/2019, = [1/17-1/23/2020]

   

2) = draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt

 = ;    [Shepherd: Susan Hares]

 = ;    Status:  3rd round of AD revisions =  

 = ;    IESG Publication requested: =  10/15/2019

   &nbs= p; IETF WG LC:  6 days  

 

--------------

AD review =E2=80=93 authors = need to respond

1) <= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-idr-tunnel-encaps-14 - sent to IESG =

[Waiting 47 days]

 

So, this = draft requires a response from the authors to Alvaro? It hasn=E2=80=99t = gone to full IESG yet =E2=80=93 right? We have a couple LSR drafts with = a normative reference.

 

Thanks,

Acee

 = ;

2) = draft-ietf-idr-capabilities-registry-change-05.txt =

[Waiting 57 days]

------------

WG past WG LC =E2=80=93 = stuck  waiting for implementation reports on wiki

[reported to have 2 = implementations, but no details on wiki]

 

1) draft-ietf-idr-ext-opt-param

2) draft-idr-eag-distribution-09.txt

---------

Drafts stuck post WG LC =E2=80=93 waiting for = minor edits

1) draft-ietf-idr-rfc8203bis.05.txt  -

----

Flow specification drafts in WG LC

 

1) Draft= -ietf-idr-flow-spec-v6-10.txt

 = ;  Status: restarted [4/8 to 4/22]

 = ;  Status: IESG desires, but is it ready?

 = ;  Needed:  implementation reports =

 = ;

2) = draft-ietf-idr-bgp-flowspec-oid-11

    Status: =  3/13/ to 4/13

    Status: light = response, please comment

    Authors:  Please = fill out implementation report

 

-----------

WG Adoption calls:

 

 = ;  1) Draft-hujun-idr-bgp-ipsec

 = ;      WG adoption:  = 3/30-4/13

 = ;       Shepherd: Susan Hares =

 = ;       Comment: only 1 response, = heading toward =E2=80=9Cno consensus=E2=80=9D

 = ;

2) = draft-hujun-idr-bgp-ipsec-transport-mode

 = ;    WG Adoption: 3/30 =E2=80=93 = 4/13

 = ;     Shepherd: Susan Hares

 = ;    Comment: only 1 response, heading toward = =E2=80=9Cno consensus=E2=80=9D

 = ;

3) = draft-li-idr-sr-policy-path-mtu-03.txt

 = ;   WG adoption: 3/30 =E2=80=93 4/13 =

 = ;    Shepherd: Susan Hares

 = ;   Comment: Positive response: Heading toward WG = Adoption

 = ;

Reque= st for input:

-----= -----------------

draft= -scharf-tcpm-yang-tcp-04

 = ;

Propo= sed WG LC drafts for flow-specification that were on hold: =

-----= --------------------------------------

[Auth= ors should contact chairs]

 = ;

1) =  draft-ietf-idr-flowspec-interfaceset-05 =E2=80=93 =

WG = notes indicated this might go ahead without flow-specification v2 =

 = ;

2) = draft-ietf-idr-flowspec-path-redirect-10 =E2=80=93 =

WG = discussion needs to occur on whether flowspecification =

 = ;

 = ;

Propo= sed WG LCs (3/30 and 4/8)

-----= -----------

1) = draft-ietf-idr-bgp-open-policy-08 =E2=80=93 on hold pending  = revision -09

2) =  draft-ietf-idr-flowspec-l2vpn-13 =E2=80=93 in slides for = 4/8

 = ;

 = ;

Propo= sed Adoption calls  

-----= ------------------

draft= -cl-idr-bgp-ext-com-registry-udpate-00.txt

 = ;

 = ;

 

 

 

------=_NextPart_000_00C6_01D60D9D.9F935DB0-- From nobody Wed Apr 8 09:08:11 2020 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 9F3013A0F2A for ; Wed, 8 Apr 2020 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.447 X-Spam-Level: * X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 QWq3O5RjbGw8 for ; Wed, 8 Apr 2020 09:08:08 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 1C4133A0F2D for ; Wed, 8 Apr 2020 09:07:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'UTTARO, JAMES'" , "'IDR List'" References: <00d101d606b2$7d036c50$770a44f0$@ndzh.com> <32e5358433ae47ee8c6217bc0f1a32fc@att.com> In-Reply-To: <32e5358433ae47ee8c6217bc0f1a32fc@att.com> Date: Wed, 8 Apr 2020 12:07:50 -0400 Message-ID: <000301d60dbf$dab073c0$90115b40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01D60D9E.53A08170" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF1ecGMwNKtmhcYNICGpdpPVFdMMAIBhsURqSB/lBA= Content-Language: en-us X-Antivirus: AVG (VPS 200407-0, 04/07/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 16:08:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01D60D9E.53A08170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jim: Is this information for public consumption? If so, can I place it on idr wiki and shepherd's report. If not, may I forward the information to Alvaro so he can use it to pass this work through the IESG. Thanks, Sue Hares From: UTTARO, JAMES [mailto:ju1738@att.com] Sent: Wednesday, April 8, 2020 10:04 AM To: Susan Hares; 'IDR List' Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) Sue, Apologies I could not attend today's IDR meeting. As per our conversation last week, AT&T has deployed the following services that distribute flowspec updates/rules from a centralized controller that depend on the flowspec-oid technology specification. Note these are all on demand. a. Edge Blocking b. DDOS Diversion c. Traffic Rate Limiting Thanks, Jim Uttaro From: Idr On Behalf Of Susan Hares Sent: Monday, March 30, 2020 12:44 PM To: 'IDR List' Subject: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) This is a 2 week WG LC for draft-idr-bgp-flowspec-oid-1.txt. You may find the draft at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ Based on our discussion at the 3/30/2020 interim, Most Flow Specification implementations add this feature. 1) draft authors will send a response to this email with their IPR statements. 2) draft authors will update the IDR wiki page https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implem entations 3) The WG will run a 2 week WG last call discussion During this discussion please indicate: a) What deployments you know about (3rd party information about an implementation is fine) b) Are there any issues with the implementations c) Is this specification ready for publication? Cheerily, Sue Hares ------=_NextPart_000_0004_01D60D9E.53A08170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim:

 

Is this information for = public consumption?   If so, can I place it on idr wiki and = shepherd’s report.

 

If not, may I forward = the information to Alvaro so he can use it to pass this work through the = IESG.

 

Thanks,  Sue Hares =

 

From:= = UTTARO, JAMES [mailto:ju1738@att.com]
Sent: Wednesday, April = 8, 2020 10:04 AM
To: Susan Hares; 'IDR = List'
Subject: RE: [Idr] = draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 = to 4/13)

 

Sue,

 

=

     &n= bsp;        Apologies I could not = attend today’s IDR meeting. As per our conversation last week, =  AT&T has deployed the following services that distribute = flowspec updates/rules from a centralized controller that depend on the = flowspec-oid technology specification. Note these are all on = demand.

 

=

a.      = Edge Blocking =

b.      = DDOS = Diversion

c.       = Traffic Rate = Limiting

 

=

Thanks,

     &n= bsp;        Jim = Uttaro

 

=

From: Idr = <idr-bounces@ietf.org> On Behalf Of Susan = Hares
Sent: Monday, March 30, 2020 12:44 PM
To: 'IDR = List' <idr@ietf.org>
Subject: [Idr] = draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 = to 4/13)

 

This is a 2 = week WG LC for  draft-idr-bgp-flowspec-oid-1.txt.

You may find the draft at:

 

https://datatracker.ietf.org/doc/draft-ietf= -idr-bgp-flowspec-oid/

 

Based on our = discussion at the 3/30/2020 interim,

Most  Flow Specification implementations add this = feature.

 

1) draft authors will send a response to this email = with their IPR statements.

2) draft = authors will update the IDR wiki page

 

https://trac.ietf.org= /trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations=

 

3) The WG will run a 2 week WG last call discussion =

 

During this discussion please indicate: =

 

a) What deployments you know about

  (3rd party information about an = implementation is fine)

 

b) Are there = any issues with the implementations

 

c) Is this = specification ready for publication?

 

Cheerily, = Sue  Hares

 

 

------=_NextPart_000_0004_01D60D9E.53A08170-- From nobody Wed Apr 8 09:10:18 2020 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 C4F203A0F49; Wed, 8 Apr 2020 09:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 fTESuFGh1Ldr; Wed, 8 Apr 2020 09:09:57 -0700 (PDT) Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C000A3A0F47; Wed, 8 Apr 2020 09:09:56 -0700 (PDT) Received: from [192.168.1.119] (unknown [101.242.202.101]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id D36926655D2; Thu, 9 Apr 2020 00:09:47 +0800 (CST) Content-Type: multipart/alternative; boundary=Apple-Mail-1F1D9266-FE59-4CDC-9E0B-EB404600F362 Content-Transfer-Encoding: 7bit From: Aijun Wang Mime-Version: 1.0 (1.0) Date: Thu, 9 Apr 2020 00:07:56 +0800 Message-Id: References: Cc: "Ketan Talaulikar (ketant)" , Susan Hares , IDR List , SPRING WG In-Reply-To: To: "Chengli (Cheng Li)" X-Mailer: iPhone Mail (17D50) X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZSVVLTEtCQkJDTUtMTUhOTllXWShZQU pMS0tKN1dZLVlBSVdZCQ4XHghZQVk1NCk2OjckKS43PlkG X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6M006Sww*Tjg9LBc#USMWHw0q OhowCxxVSlVKTkNNSE1JSkJISk1DVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS0pVSU9JVUlLSVVKS0pZV1kIAVlBSUJDSE43Bg++ X-HM-Tid: 0a715a8e005c9373kuwsd36926655d2 Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 16:10:03 -0000 --Apple-Mail-1F1D9266-FE59-4CDC-9E0B-EB404600F362 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Cheng: I am considering the following scenarios: When the size of some packets of one flow are small and do not exceed the PM= TU value, they are encapsulated upon the corresponding SR policy and will be= transferred according to the appointed path as expected.=20 But how about other larger packets within the same flow? Will they be droppe= d or transferred via other non-SR path? If so, will the SR influence the flo= w=E2=80=99s jitter? PMTU for the path is one useful information but I think current draft has no= t elaborate how to use it in different situations.=20 Without SR, we can tell the customer the MTU of the network. But with SR, th= e network MTU will be changed based on the path length. Considering this, ma= ybe the PMTU that detected by the host will be more convincible? Aijun Wang China Telecom > On Apr 8, 2020, at 17:07, Chengli (Cheng Li) wrote:= >=20 > =EF=BB=BF > Hi Ketan, > =20 > Many thanks for your comments, and sorry for my delay, please see my reply= inline. > =20 > Thanks, > Cheng > =20 > =20 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ket= ant) > Sent: Friday, April 3, 2020 4:18 PM > To: Susan Hares ; 'IDR List' > Cc: SPRING WG > Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) > =20 > Hello, > =20 > I have a few questions for the authors of this draft and some discussion p= oints for the WG. > =20 > 1) What is precisely the definition of this =E2=80=9Cpath MTU=E2=80=9D= for an SR Policy? I am guessing that it includes all the labels/SIDs that a= re used for the SR path? > [Cheng] Yes, The Path MTU describes the largest size of the packet, includ= ing the overhead of Labels/SIDs/IPv6 header/SRH and others. When encapsulati= ng a packet, the length of the payload(inner IP packet or something else) sh= ould be less than the PMTU minus the overhead of SID List/SRH/ FRR overhead a= nd Binding SID overhead, but it is a implementation choice. > =20 > 2) While https://tools.ietf.org/html/rfc3209#section-2.6 defines =E2=80= =9Cpath MTU=E2=80=9D for RSVP-TE LSPs, it does describe the procedures for t= he same for handling IP packets/payloads on the headend. It does not cover t= he scenarios where the incoming packets may be themselves labelled. > [Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/r= fc3209#section-2.6, but I think it covers the scenarios where the incoming p= ackets may be themselves labelled. I may be wrong. > =20 > =E2=80=9C > The following algorithm applies to all unlabeled IP datagrams and to > any labeled packets which the node knows to be IP datagrams, to which > labels need to be added before forwarding. For labeled packets the > bottom of stack is found, the IP header examined. > =20 > Using the terminology defined in [5], an LSR MUST execute the > following algorithm: > =20 > 1. Let N be the number of bytes in the label stack (i.e, 4 times the > number of label stack entries) including labels to be added by > this node. > =E2=80=9C > =20 > 3) Shouldn=E2=80=99t the concept of =E2=80=9Cpath MTU=E2=80=9D for SR= Policies and its=E2=80=99 applicability and operations be first defined in a= (Spring WG?) document before we introduce its signalling aspects in protoco= ls like BGP? Note that such a document would bring in requirements and guide= lines for how the value is going to be computed and it=E2=80=99s usage for d= ifferent steering mechanisms over SR Policies. > [Cheng] This is a really small but useful and straight forward extensions,= it might not need to write a draft to describe the requirement instead of a= dding text in the current SR policy architecture draft or it current documen= t. =20 > =20 > =20 > =20 > 4) Finally, specific to the proposed encoding here, would this =E2=80= =9Cpath MTU=E2=80=9D not be more suitable on the CP level since each SL may h= ave different size label stack and different paths and one does not know whi= ch SL would be picked for a particular flow? So may be the lowest value comp= uted for all SLs is what gets applied to the packets at the CP (i.e. SR Poli= cy) level? > [Cheng] You are correct. The PMTU is defined for SID List. When we talk ab= out Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID li= sts. But do we need this value? If we need, then the node can compute it bas= ed on PMTUs. > =20 > =20 > =20 > =20 > Thanks, > Ketan > =20 > =20 > From: Idr On Behalf Of Susan Hares > Sent: 30 March 2020 18:06 > To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 We= ek WG adoption call (3/30 - 4/13) > =20 > This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-= 03.txt > =20 > You can view this draft at: > https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ > =20 > This draft distributes path maximum transmission unit for the > SR policy via BGP.=20 > =20 > Any discussion regarding on whether one desires > SR Policy should be clearly distinguished from the > Technical discussions on the mechanisms to pass SR policy MTU. > =20 > The questions for the people to discuss on this draft are: > =20 > 1) Is there a need for this mechanism in networks using > MPLS-SR or SR-V6 and SR policy? > =20 > 2) Are there any error handling issues besides what is being > Taken care of in RFC7752bis-03.txt > =20 > 3) Do you think this draft is ready to be adopted? > In this category, please list any concerns you have > regarding adoption. This category can include > general concerns about BGP-LS, MPLS-SR, > SR-V6, and SR-Policy. =20 > =20 > Cheers, Sue Hares =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-1F1D9266-FE59-4CDC-9E0B-EB404600F362 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Cheng:
I am considering the followi= ng scenarios:
When the size of some packets of one flow are small a= nd do not exceed the PMTU value, they are encapsulated upon the correspondin= g SR policy and will be transferred according to the appointed path as expec= ted. 
But how about other larger packets within the same flow= ? Will they be dropped or transferred via other non-SR path? If so, will the= SR influence the flow=E2=80=99s jitter?

PMTU for t= he path is one useful information but I think current draft has not elaborat= e how to use it in different situations. 

With= out SR, we can tell the customer the MTU of the network. But with SR, the ne= twork MTU will be changed based on the path length. Considering this, maybe t= he PMTU that detected by the host will be more convincible?

Aijun Wang
China Telecom
=
On Apr 8, 2020, at 17:07, Chengli (Cheng Li) &= lt;chengli13@huawei.com> wrote:

=EF=BB=BF =

Hi Ketan,

 

Many thanks for your co= mments, and sorry for my delay, please see my reply inline.

 

Thanks,

Cheng=

 

 

From: Idr [mailto:idr-bounces@ietf.org] On B= ehalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org&= gt;
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.t= xt - 2 Week WG adoption call (3/30 - 4/13)

 

Hello,

 

I have a few questions for the authors of this draft and some discussio= n points for the WG.

 

1)      What is precisely the definition of this =E2=80=9Cpath MTU=E2= =80=9D for an SR Policy? I am guessing that it includes all the labels/SIDs t= hat are used for the SR path?

[Cheng] Yes, The Path MTU describes the largest size of the packet, inc= luding the overhead of Labels/SIDs/IPv6 header/SRH and others. When encapsul= ating a packet, the length of the payload(inner IP packet or something else) should be less than the PMTU min= us the overhead of SID List/SRH/ FRR overhead and Binding SID overhead, but i= t is a implementation choice. =

 

2)      While https://tools.ietf.org/html/rfc3209#section-2.6 defines =E2=80=9Cpath MTU=E2=80=9D for RSVP-TE LSPs, it does d= escribe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where t= he incoming packets may be themselves labelled.

[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the scenarios where the incom= ing packets may be themselves labelled. I may be wrong.

 

   =E2=80=9C

   The following algorithm applies to a= ll unlabeled IP datagrams and to

   any labeled packets which the node k= nows to be IP datagrams, to which

   labels need to be added before forw= arding.  For labeled packets the

   bottom of stack is found, the IP he= ader examined.

 

   Using the terminology defined i=
n [5], an LSR MUST execute the
   following algorithm:
 
   1. Let N be the number of byte=
s in the label stack (i.e, 4 times the
      number of la=
bel stack entries) including labels to be added by
      this node.

       =E2=80=9C

 

3)      Shouldn=E2=80=99t th= e concept of =E2=80=9Cpath MTU=E2=80=9D for SR Policies and its=E2=80=99 app= licability and operations be first defined in a (Spring WG?) document before= we introduce its signalling aspects in protocols like BGP? Note that such a document would bring in requirements and guidelines for how the valu= e is going to be computed and it=E2=80=99s usage for different steering mech= anisms over SR Policies.

[Cheng] This is a really small but useful and straight forward extensio= ns, it might not need to write a draft to describe the requirement instead o= f adding text in the current SR policy architecture draft or it current document.  

 

 

 

4)      Finally, specific to= the proposed encoding here, would this =E2=80=9Cpath MTU=E2=80=9D not be mo= re suitable on the CP level since each SL may have different size label stac= k and different paths and one does not know which SL would be picked for a particular flow? So may be the lowest value computed f= or all SLs is what gets applied to the packets at the CP (i.e. SR Policy) le= vel?

[Cheng] You are correct. The PMTU is defined for SID List. When we talk= about Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID= lists. But do we need this value? If we need, then the node can compute it based on PMTUs.<= /p>

 

 

 

 

Thanks,

Ketan

 

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' <idr@ietf.org&g= t;
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt -= 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoption call for draft-li-id= r-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org/doc/draft-li-idr-sr-po= licy-path-mtu/

 

This draft distributes path maximum transmission unit= for the

SR policy via BGP. 

 

Any discussion regarding on whether one desires =

SR Policy should be clearly distinguished from the

Technical discussions on the mechanisms to pass SR po= licy MTU.

 

The questions for the people to discuss on this draft= are:

 

1) Is there a need for this mechanism in networks usi= ng

        MPLS-= SR or SR-V6 and SR policy?

 

2) Are there any error handling issues besides what i= s being

     Taken care of in RFC775= 2bis-03.txt

 

3) Do you think this draft is ready to be adopted?

     In this category, pleas= e list any concerns you have

     regarding adoption.  Th= is category can include

     general concerns about B= GP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  &= nbsp;

 

Cheers, Sue Hares  

 

 

 

 

 

_______________________________________________
Idr ma= iling list
Idr@ietf.org
https://www.ietf.org= /mailman/listinfo/idr
= --Apple-Mail-1F1D9266-FE59-4CDC-9E0B-EB404600F362-- From nobody Wed Apr 8 09:22:05 2020 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 D06D73A0CC2 for ; Wed, 8 Apr 2020 09:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 M2NNrVgj4xhc for ; Wed, 8 Apr 2020 09:22:01 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 2E5903A0CA0 for ; Wed, 8 Apr 2020 09:22:01 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 038GCLrZ023454; Wed, 8 Apr 2020 12:22:00 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 3091nwpq5y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Apr 2020 12:22:00 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038GLxGM001096; Wed, 8 Apr 2020 12:21:59 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038GLpQB000917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2020 12:21:51 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 224914009E66; Wed, 8 Apr 2020 16:21:51 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30484.vci.att.com (Service) with ESMTPS id 0B6984009E65; Wed, 8 Apr 2020 16:21:51 +0000 (GMT) Received: from GAALPA1MSGEX1BA.ITServices.sbc.com (135.50.89.102) by GAALPA1MSGHUBAB.ITServices.sbc.com (130.8.218.151) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 8 Apr 2020 12:21:49 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BA.ITServices.sbc.com (135.50.89.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Apr 2020 12:21:49 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.1913.007; Wed, 8 Apr 2020 12:21:49 -0400 From: "UTTARO, JAMES" To: Susan Hares , "'IDR List'" Thread-Topic: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) Thread-Index: AdYGsjkGouveGy3sT42zRQgNbUUoFQG+68lgAAzeNAAAB+e74A== Date: Wed, 8 Apr 2020 16:21:49 +0000 Message-ID: <5948c51db2a942b989cc2051d4e71c58@att.com> References: <00d101d606b2$7d036c50$770a44f0$@ndzh.com> <32e5358433ae47ee8c6217bc0f1a32fc@att.com> <000301d60dbf$dab073c0$90115b40$@ndzh.com> In-Reply-To: <000301d60dbf$dab073c0$90115b40$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.132.73] Content-Type: multipart/alternative; boundary="_000_5948c51db2a942b989cc2051d4e71c58attcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-07_10:2020-04-07, 2020-04-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 phishscore=0 suspectscore=0 mlxscore=0 spamscore=0 clxscore=1015 bulkscore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004080126 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 16:22:03 -0000 --_000_5948c51db2a942b989cc2051d4e71c58attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sue, Let me double check with the manager of this team.. Thanks, Jim Uttaro From: Susan Hares Sent: Wednesday, April 08, 2020 12:08 PM To: UTTARO, JAMES ; 'IDR List' Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group L= ast Call (3/30 to 4/13) Jim: Is this information for public consumption? If so, can I place it on idr = wiki and shepherd's report. If not, may I forward the information to Alvaro so he can use it to pass th= is work through the IESG. Thanks, Sue Hares From: UTTARO, JAMES [mailto:ju1738@att.com] Sent: Wednesday, April 8, 2020 10:04 AM To: Susan Hares; 'IDR List' Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group L= ast Call (3/30 to 4/13) Sue, Apologies I could not attend today's IDR meeting. As per our = conversation last week, AT&T has deployed the following services that dist= ribute flowspec updates/rules from a centralized controller that depend on = the flowspec-oid technology specification. Note these are all on demand. a. Edge Blocking b. DDOS Diversion c. Traffic Rate Limiting Thanks, Jim Uttaro From: Idr > On Behalf Of = Susan Hares Sent: Monday, March 30, 2020 12:44 PM To: 'IDR List' > Subject: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last = Call (3/30 to 4/13) This is a 2 week WG LC for draft-idr-bgp-flowspec-oid-1.txt. You may find the draft at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ Based on our discussion at the 3/30/2020 interim, Most Flow Specification implementations add this feature. 1) draft authors will send a response to this email with their IPR statemen= ts. 2) draft authors will update the IDR wiki page https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20imple= mentations 3) The WG will run a 2 week WG last call discussion During this discussion please indicate: a) What deployments you know about (3rd party information about an implementation is fine) b) Are there any issues with the implementations c) Is this specification ready for publication? Cheerily, Sue Hares --_000_5948c51db2a942b989cc2051d4e71c58attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Su= e,

 

&n= bsp;            = ; Let me double check with the manager of this team..=

 

Th= anks,

&n= bsp;            = ; Jim Uttaro

 

From: Susan Hares <shares@ndzh.com> Sent: Wednesday, April 08, 2020 12:08 PM
To: UTTARO, JAMES <ju1738@att.com>; 'IDR List' <idr@ietf.or= g>
Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working = Group Last Call (3/30 to 4/13)

 

Jim:=

 

Is this information fo= r public consumption?   If so, can I place it on idr wiki and she= pherd’s report.

 

If not, may I forward = the information to Alvaro so he can use it to pass this work through the IE= SG.

 

Thanks,  Sue Hare= s

 

From: UTTARO, JAMES [mailto:ju1738@att.com]
Sent: Wednesday, April 8, 2020 10:04 AM
To: Susan Hares; 'IDR List'
Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working = Group Last Call (3/30 to 4/13)

 

Su= e,

 

&n= bsp;            = ; Apologies I could not attend today’s IDR meeting. As per our conver= sation last week,  AT&T has deployed the following services that d= istribute flowspec updates/rules from a centralized controller that depend on the flowspec-oid technology specification. Note = these are all on demand.

 

a.      Edge Blocking

b.      DDOS Diversion

c.       Traffic Rate Limiting

 

Th= anks,

&n= bsp;            = ; Jim Uttaro

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 12:44 PM
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Grou= p Last Call (3/30 to 4/13)

 

This is a 2 week WG LC for  draft-idr-bgp-flows= pec-oid-1.txt.

You may find the draft at:

 

https://datatracker.ietf.or= g/doc/draft-ietf-idr-bgp-flowspec-oid/

 

Based on our discussion at the 3/30/2020 interim,

Most  Flow Specification implementations add th= is feature.

 

1) draft authors will send a response to this email = with their IPR statements.

2) draft authors will update the IDR wiki page =

 

https= ://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementa= tions

 

3) The WG will run a 2 week WG last call discussion =

 

During this discussion please indicate: <= /p>

 

a) What deployments you know about

  (3rd party information about = an implementation is fine)

 

b) Are there any issues with the implementations

 

c) Is this specification ready for publication?

 

Cheerily, Sue  Hares

 

 

--_000_5948c51db2a942b989cc2051d4e71c58attcom_-- From nobody Wed Apr 8 09:38:27 2020 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 4A6A93A0F4A for ; Wed, 8 Apr 2020 09:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.447 X-Spam-Level: * X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 eFJTl0Kzr8ex for ; Wed, 8 Apr 2020 09:38:23 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 2C2043A0F51 for ; Wed, 8 Apr 2020 09:38:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'UTTARO, JAMES'" , "'IDR List'" References: <00d101d606b2$7d036c50$770a44f0$@ndzh.com> <32e5358433ae47ee8c6217bc0f1a32fc@att.com> <000301d60dbf$dab073c0$90115b40$@ndzh.com> <5948c51db2a942b989cc2051d4e71c58@att.com> In-Reply-To: <5948c51db2a942b989cc2051d4e71c58@att.com> Date: Wed, 8 Apr 2020 12:38:16 -0400 Message-ID: <003601d60dc4$1aeed860$50cc8920$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01D60DA2.93DEBF00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF1ecGMwNKtmhcYNICGpdpPVFdMMAIBhsURAfDYnYEBf9BKiakFAyUg Content-Language: en-us X-Antivirus: AVG (VPS 200407-0, 04/07/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 16:38:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0037_01D60DA2.93DEBF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jim: Thank you for checking. Sue From: UTTARO, JAMES [mailto:ju1738@att.com] Sent: Wednesday, April 8, 2020 12:22 PM To: Susan Hares; 'IDR List' Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) Sue, Let me double check with the manager of this team.. Thanks, Jim Uttaro From: Susan Hares Sent: Wednesday, April 08, 2020 12:08 PM To: UTTARO, JAMES ; 'IDR List' Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) Jim: Is this information for public consumption? If so, can I place it on idr wiki and shepherd's report. If not, may I forward the information to Alvaro so he can use it to pass this work through the IESG. Thanks, Sue Hares From: UTTARO, JAMES [mailto:ju1738@att.com] Sent: Wednesday, April 8, 2020 10:04 AM To: Susan Hares; 'IDR List' Subject: RE: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) Sue, Apologies I could not attend today's IDR meeting. As per our conversation last week, AT&T has deployed the following services that distribute flowspec updates/rules from a centralized controller that depend on the flowspec-oid technology specification. Note these are all on demand. a. Edge Blocking b. DDOS Diversion c. Traffic Rate Limiting Thanks, Jim Uttaro From: Idr On Behalf Of Susan Hares Sent: Monday, March 30, 2020 12:44 PM To: 'IDR List' Subject: [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 to 4/13) This is a 2 week WG LC for draft-idr-bgp-flowspec-oid-1.txt. You may find the draft at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ Based on our discussion at the 3/30/2020 interim, Most Flow Specification implementations add this feature. 1) draft authors will send a response to this email with their IPR statements. 2) draft authors will update the IDR wiki page https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implem entations 3) The WG will run a 2 week WG last call discussion During this discussion please indicate: a) What deployments you know about (3rd party information about an implementation is fine) b) Are there any issues with the implementations c) Is this specification ready for publication? Cheerily, Sue Hares ------=_NextPart_000_0037_01D60DA2.93DEBF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim:

 

Thank you for checking. =

 

Sue =

 

From:= = UTTARO, JAMES [mailto:ju1738@att.com]
Sent: Wednesday, April = 8, 2020 12:22 PM
To: Susan Hares; 'IDR = List'
Subject: RE: [Idr] = draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 = to 4/13)

 

Sue,

 

=

     &n= bsp;        Let me double check with = the manager of this team..

 

=

Thanks,

     &n= bsp;        Jim = Uttaro

 

=

From: Susan = Hares <shares@ndzh.com>
Sent: Wednesday, April 08, 2020 = 12:08 PM
To: UTTARO, JAMES <ju1738@att.com>; 'IDR List' = <idr@ietf.org>
Subject: RE: [Idr] = draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 = to 4/13)

 

Jim:

 

Is this information for = public consumption?   If so, can I place it on idr wiki and = shepherd’s report.

 

If not, may I forward = the information to Alvaro so he can use it to pass this work through the = IESG.

 

Thanks,  Sue Hares =

 

From:= = UTTARO, JAMES [mailto:ju1738@att.com] =
Sent: Wednesday, April 8, 2020 10:04 AM
To: Susan = Hares; 'IDR List'
Subject: RE: [Idr] = draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call (3/30 = to 4/13)

 

Sue,

 

=

     &n= bsp;        Apologies I could not = attend today’s IDR meeting. As per our conversation last week, =  AT&T has deployed the following services that distribute = flowspec updates/rules from a centralized controller that depend on the = flowspec-oid technology specification. Note these are all on = demand.

 

=

a.      = Edge = Blocking

b.      = DDOS = Diversion

c.       = Traffic = Rate Limiting

 

=

Thanks,

     &n= bsp;        Jim = Uttaro

 

=

From: Idr = <idr-bounces@ietf.org> = On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 = 12:44 PM
To: 'IDR List' <idr@ietf.org>
Subject: = [Idr] draft-ietf-idr-bgp-flowspec-oid-11.txt - Working Group Last Call = (3/30 to 4/13)

 

This is a 2 = week WG LC for  draft-idr-bgp-flowspec-oid-1.txt.

You may find the draft at:

 

https://datatracker.ietf.org/doc/draft-ietf= -idr-bgp-flowspec-oid/

 

Based on our = discussion at the 3/30/2020 interim,

Most  Flow Specification implementations add this = feature.

 

1) draft authors will send a response to this email = with their IPR statements.

2) draft = authors will update the IDR wiki page

 

https://trac.ietf.org= /trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations=

 

3) The WG will run a 2 week WG last call discussion =

 

During this discussion please indicate: =

 

a) What deployments you know about

  (3rd party information about an = implementation is fine)

 

b) Are there = any issues with the implementations

 

c) Is this = specification ready for publication?

 

Cheerily, = Sue  Hares

 

 

------=_NextPart_000_0037_01D60DA2.93DEBF00-- From nobody Wed Apr 8 13:53:35 2020 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 2483E3A1736 for ; Wed, 8 Apr 2020 13:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-PoKMKzlkkD for ; Wed, 8 Apr 2020 13:53:29 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 053563A1731 for ; Wed, 8 Apr 2020 13:53:28 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id a32so330927pje.5 for ; Wed, 08 Apr 2020 13:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=L0/FZCilVGNsCYOLSCy/pvUbXMXhHzltaCX95+B45kc=; b=Go7RHK3f2maXuA0Lu46OjvIJObKQFQXV6MnkTHuZJ/wea1tb8kpF5SNC6dvkDitDV9 dalKWa2m+tM4FFxTezdP8NgS7zIbtVtbGvjBJ09XGHH/zdTPs6OJpLPdSRqf3+QyHSgl T7vledM8l+Rf40WA0T7L714gWSiPo17cKhIDSKI43s92mvPLpk9830Dr80PZaIDEoitR 0gtUtuEgq6Qi5xAaOaVfRGXwSewIYFb18rfJo2sDXYmU4cigce5MuEk0+RsY/qxqZLTr 3pudZtmrI+GyqdlxRLbqbZ0AzFAlh9mLFGgHgN1zr7YfpLZMdk/GO6TNFbzmJzdF12+O bT5g== 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:message-id:in-reply-to:references :subject:mime-version; bh=L0/FZCilVGNsCYOLSCy/pvUbXMXhHzltaCX95+B45kc=; b=K7NobVz44p6iI+NnrH1k8WJ2QTAdfG8SYz0av/gme9Zk20lap3Qd0bkB2Db2emoNlm 0tpZJq6BSQpXd55K8za/qGr4TVVzXsScQSBeAfVGAn0ivCWIZW2JLNi2ZcG+d0gmfgRG 34qwaV18UQprL6W3Q3Wamu0NvKSTNfXmOVnuhpfPa834f8HQEk0ER1ZKmKQMmm/emes3 TIQV+SyJnk3yeFDur+Cs1/0n0Fdhs2hvihP0KZuTU26wAwc8uNK7QRYqTYPf0BAhVN+g IyA1p1upHI2RGznNGTcdbU2l/sQB6r1NKR6HjDS2WpyWGoMUCiVwJG5j5jUMcVcEU0tJ Knmw== X-Gm-Message-State: AGi0PuY5R5HjOOIqRZN3Qzuq7xUyILFmMK82H5CWfpWGWNXbCRd2PYP0 tGB3CNd3XjtrbtIrfMCImoXNl2LS X-Google-Smtp-Source: APiQypInoXeyGfPCDjZMwgv64c+UVACms/hjz2Gu/xPcX3D7bOva4KEt2Dhuk7+WV46RFrM+Xo8S/w== X-Received: by 2002:a17:90b:8e:: with SMTP id bb14mr7703082pjb.13.1586379207446; Wed, 08 Apr 2020 13:53:27 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id 8sm17456383pfv.65.2020.04.08.13.53.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 13:53:26 -0700 (PDT) Date: Wed, 8 Apr 2020 13:53:20 -0700 From: Jeff Tantsura To: "Acee Lindem (acee)" , idr@ietf.org, Susan Hares Message-ID: In-Reply-To: <00c501d60dbf$26a17b40$73e471c0$@ndzh.com> References: <008901d60da2$74031370$5c093a50$@ndzh.com> <00c501d60dbf$26a17b40$73e471c0$@ndzh.com> X-Readdle-Message-ID: c6537b8b-b021-4e0c-b014-a47a54db29f7@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e8e39c5_7aa0799a_16f" Archived-At: Subject: Re: [Idr] status - incremental 4/8/2020 - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 20:53:33 -0000 --5e8e39c5_7aa0799a_16f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sue, Alvaro has submitted =C2=A0draft-ietf-idr-bgp-ls-segment-routing-msd-16 t= o IESG a few days ago. Cheers, Jeff On Apr 8, 2020, 9:03 AM -0700, Susan Hares , wrote: > Acee: > > My understanding is that the authors need to address the issues that Al= varo raised. =C2=A0=C2=A0=C2=A0=C2=A0See email on the subject on 2/21/201= 9. > > Keyur said he would get on it on 2/21.=C2=A0 Life may be challenged.=C2= =A0 =C2=A0=C2=A0The other option is to Ping Gunter or Sri.=C2=A0=C2=A0 I=E2= =80=99ll ping them again today. > > Maybe it will raise the urgency and they can deal with it while we are = offline > > Sue > > =46rom: Idr =5Bmailto:idr-bounces=40ietf.org=5D On Behalf Of Acee Linde= m (acee) > Sent: Wednesday, April 8, 2020 9:00 AM > To: Susan Hares; idr=40ietf.org > Subject: Re: =5BIdr=5D status - incremental 4/8/2020 - > > Hi Sue, > One clarification=E2=80=A6 > > =46rom: Idr on behalf of Susan Hares > Date: Wednesday, April 8, 2020 at 8:40 AM > To: IDR List > Subject: =5BIdr=5D status - incremental 4/8/2020 - > > IDR WG: > > A little status to read with your coffee this morning. =C2=A0=C2=A0We h= ave an interim at 13:00 UTC (9:00 EDT,=C2=A0 6:00 PDT, 21:00 Bejing time)= > > Please let me know if I=E2=80=99ve missed any updates. > > Cheers, Sue > > --------- > At IESG in IET=46 LC > 1) draft-ietf-idr-rfc5575bis-19.txt =E2=80=93 > =C2=A0=C2=A0=C2=A0=C2=A0Shepherd: John Scudder > =C2=A0=C2=A0=C2=A0 Status:=C2=A0 IET=46 LC ended, IESG telechat: 4/15 > =C2=A0=C2=A0=C2=A0=C2=A0IESG Publication request: 7/9/2019 > =C2=A0=C2=A0=C2=A02 =C2=A0AD Reviews =5B8/2-9/10/2019, =5B1/17-1/23/202= 0=5D > > 2) draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt > =C2=A0=C2=A0=C2=A0=C2=A0 =5BShepherd: Susan Hares=5D > =C2=A0=C2=A0=C2=A0=C2=A0 Status: =C2=A03rd round of AD revisions > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IESG Publication requested: =C2=A010/15/2= 019 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IET=46 WG LC:=C2=A0 6 days > > -------------- > AD review =E2=80=93 authors need to respond > 1) draft-ietf-idr-tunnel-encaps-14 - sent to IESG > =5BWaiting 47 days=5D > > So, this draft requires a response from the authors to Alvaro=3F It has= n=E2=80=99t gone to full IESG yet =E2=80=93 right=3F We have a couple LSR= drafts with a normative reference. > > Thanks, > Acee > > 2) draft-ietf-idr-capabilities-registry-change-05.txt > =5BWaiting 57 days=5D > ------------ > WG past WG LC =E2=80=93 stuck =C2=A0waiting for implementation reports = on wiki > =5Breported to have 2 implementations, but no details on wiki=5D > > 1) draft-ietf-idr-ext-opt-param > 2) draft-idr-eag-distribution-09.txt > --------- > Drafts stuck post WG LC =E2=80=93 waiting for minor edits > 1) draft-ietf-idr-rfc8203bis.05.txt =C2=A0- > ---- > =46low specification drafts in WG LC > > 1) Draft-ietf-idr-flow-spec-v6-10.txt > =C2=A0=C2=A0 Status: restarted =5B4/8 to 4/22=5D > =C2=A0=C2=A0 Status: IESG desires, but is it ready=3F > =C2=A0=C2=A0=C2=A0Needed:=C2=A0 implementation reports > > 2) draft-ietf-idr-bgp-flowspec-oid-11 > =C2=A0=C2=A0=C2=A0 Status: =C2=A03/13/ to 4/13 > =C2=A0=C2=A0=C2=A0=C2=A0Status: light response, please comment > =C2=A0=C2=A0=C2=A0=C2=A0Authors:=C2=A0 Please fill out implementation r= eport > > ----------- > WG Adoption calls: > > =C2=A0=C2=A0 1) Draft-hujun-idr-bgp-ipsec > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WG adoption:=C2=A0 3/30-4/13 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Shepherd: Susan Hares > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Comment: only 1 respons= e, heading toward =E2=80=9Cno consensus=E2=80=9D > > 2) draft-hujun-idr-bgp-ipsec-transport-mode > =C2=A0=C2=A0=C2=A0=C2=A0 WG Adoption: 3/30 =E2=80=93 4/13 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Shepherd: Susan Hares > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Comment: only 1 response, heading toward = =E2=80=9Cno consensus=E2=80=9D > > 3) draft-li-idr-sr-policy-path-mtu-03.txt > =C2=A0=C2=A0=C2=A0=C2=A0WG adoption: 3/30 =E2=80=93 4/13 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Shepherd: Susan Hares > =C2=A0=C2=A0=C2=A0=C2=A0Comment: Positive response: Heading toward WG A= doption > > Request for input: > ---------------------- > draft-scharf-tcpm-yang-tcp-04 > > Proposed WG LC drafts for flow-specification that were on hold: > ------------------------------------------- > =5BAuthors should contact chairs=5D > > 1) =C2=A0draft-ietf-idr-flowspec-interfaceset-05 =E2=80=93 > WG notes indicated this might go ahead without flow-specification v2 > > 2) draft-ietf-idr-flowspec-path-redirect-10 =E2=80=93 > WG discussion needs to occur on whether flowspecification > > > Proposed WG LCs (3/30 and 4/8) > ---------------- > 1) draft-ietf-idr-bgp-open-policy-08 =E2=80=93 on hold pending=C2=A0 re= vision -09 > 2) =C2=A0draft-ietf-idr-flowspec-l2vpn-13 =E2=80=93 in slides for 4/8 > > > Proposed Adoption calls > ----------------------- > draft-cl-idr-bgp-ext-com-registry-udpate-00.txt > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Idr mailing list > Idr=40ietf.org > https://www.ietf.org/mailman/listinfo/idr --5e8e39c5_7aa0799a_16f Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Sue,

Alvaro has submitted &=23160;draft-ietf-idr-bgp-ls-= segment-routing-msd-16 to IESG a few days ago.

Cheers,
Jeff
On Apr 8, 2020, 9:03 AM -0700, Susa= n Hares <shares=40ndzh.com>, wrote:

Acee:

&=23160;=

My under= standing is that the authors need to address the issues that Alvaro raise= d. &=23160;&=23160;&=23160;&=23160;See email on the subject on 2/21/2019.=

&=23160;=

Keyur sa= id he would get on it on 2/21.&=23160; Life may be challenged.&=23160; &=23= 160;&=23160;The other option is to Ping Gunter or Sri.&=23160;&=23160; I=E2= =80=99ll ping them again today.&=23160;&=23160;

&=23160;=

Maybe it= will raise the urgency and they can deal with it while we are offline

&=23160;=

Sue

&=23160;=

=46rom: Idr =5Bmailto:idr-bounces=40ietf.org=5D On Behalf Of A= cee Lindem (acee)
Sent: Wednesday, April 8, 2020 9:00 AM
To: Susan Hares; idr=40ietf.org
Subject: Re: =5BIdr=5D status - incremental 4/8/2020 -

&=23160;

Hi Sue,

One clarification=E2=80=A6

&=23160;

=46rom: Idr <idr-bounces=40ietf.org> on behal= f of Susan Hares <shares=40ndzh.com>
Date: Wednesday, April 8, 2020 at 8:40 AM
To: IDR List <idr=40ietf.org>
Subject: =5BIdr=5D status - incremental 4/8/2020 -

&=23160;

IDR WG:

&=23160;

A little status to read with your coffee this mornin= g. &=23160;&=23160;We have an interim at 13:00 UTC (9:00 EDT,&=23160; 6:0= 0 PDT, 21:00 Bejing time)

&=23160;

Please let me know if I=E2=80=99ve missed any update= s.

&=23160;

Cheers, Sue

&=23160;

---------

At IESG in IET=46 LC

1) draft-ietf-idr-rfc5575bis-19.txt =E2=80=93

&=23160;&=23160;&=23160;&=23160;Shepherd: John Scudder

&=23160;&=23160;&=23160; Status:&=23160; IET=46 LC ended, IESG telechat:= 4/15

&=23160;&=23160;&=23160;&=23160;IESG Publication request: 7/9/2019

&=23160;&=23160;&=23160;2 &=23160;AD Reviews =5B8/2-9/10/2019, =5B1/17-1= /23/2020=5D

&=23160;&=23160;&=23160;

2) draft= -ietf-idr-bgp-ls-segment-routing-msd-08.txt

&=23160;= &=23160;&=23160;&=23160; =5BShepherd: Susan Hares=5D

&=23160;= &=23160;&=23160;&=23160; Status: &=23160;3rd round of AD revis= ions &=23160;

&=23160;= &=23160;&=23160;&=23160;&=23160;IESG Publication requested: &=23160;10/15= /2019

&=23160;&=23160;&=23160;&=23160;&=23160;IET=46 = WG LC:&=23160; 6 days &=23160;

&=23160;

--------------<= /p>

AD review =E2=80= =93 authors need to respond

1) draft-ietf-idr-tun= nel-encaps-14 - sent to IESG

=5BWaiting 47 days=5D

&=23160;

So, this draft requires a response from the au= thors to Alvaro=3F It hasn=E2=80=99t gone to full IESG yet =E2=80=93 righ= t=3F We have a couple LSR drafts with a normative reference.

&=23160;

Thanks,

Acee

&=23160;=

2) draft= -ietf-idr-capabilities-registry-change-05.txt

=5BWaiting 57 d= ays=5D

------------

WG past WG LC =E2= =80=93 stuck &=23160;waiting for implementation reports on wiki

=5Breported to = have 2 implementations, but no details on wiki=5D

&=23160;

1) draft-ietf-idr-ext-opt-param

2) draft-idr-eag-distribution-09.txt

---------

Drafts stuck po= st WG LC =E2=80=93 waiting for minor edits

1) draft-ietf-idr-rfc8203bis.05.txt &=23160;-

----

=46low specification drafts in WG LC

&=23160;

1) Draft-ietf-idr-flow-spec-v6-10.txt

&=23160;= &=23160; Status: restarted =5B4/8 to 4/22=5D

&=23160;= &=23160; Status: IESG desires, but is it ready=3F

&=23160;= &=23160;&=23160;Needed:&=23160; implementation reports

&=23160;=

2) draft-ietf-idr-bgp-flowspec-oid-11

&=23160;&=23160= ;&=23160; Status: &=23160;3/13/ to 4/13

&=23160;&=23160= ;&=23160;&=23160;Status: light response, please comment

&=23160;&=23160= ;&=23160;&=23160;Authors:&=23160; Please fill out implementation report

&=23160;

-----------

WG Adoption calls:

&=23160;

&=23160;= &=23160; 1) Draft-hujun-idr-bgp-ipsec

&=23160;= &=23160;&=23160;&=23160;&=23160;&=23160; WG adoption:&=23160; 3/30-4/13

&=23160;= &=23160;&=23160;&=23160;&=23160;&=23160;&=23160; Shepherd: Susan Hares

&=23160;= &=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;Comment: only 1 r= esponse, heading toward =E2=80=9Cno consensus=E2=80=9D

&=23160;=

2) draft= -hujun-idr-bgp-ipsec-transport-mode

&=23160;= &=23160;&=23160;&=23160; WG Adoption: 3/30 =E2=80=93 4/13

&=23160;= &=23160;&=23160;&=23160;&=23160; Shepherd: Susan Hares

&=23160;= &=23160;&=23160;&=23160;&=23160;Comment: only 1 response, heading toward = =E2=80=9Cno consensus=E2=80=9D

&=23160;=

3) draft= -li-idr-sr-policy-path-mtu-03.txt

&=23160;= &=23160;&=23160;&=23160;WG adoption: 3/30 =E2=80=93 4/13

&=23160;= &=23160;&=23160;&=23160;&=23160;Shepherd: Susan Hares

&=23160;= &=23160;&=23160;&=23160;Comment: Positive response: Heading toward WG Ado= ption

&=23160;=

Request = for input:

--------= --------------

draft-sc= harf-tcpm-yang-tcp-04

&=23160;=

Proposed= WG LC drafts for flow-specification that were on hold:

--------= -----------------------------------

=5BAutho= rs should contact chairs=5D

&=23160;=

1) &=231= 60;draft-ietf-idr-flowspec-interfaceset-05 =E2=80=93

WG notes= indicated this might go ahead without flow-specification v2

&=23160;=

2) draft= -ietf-idr-flowspec-path-redirect-10 =E2=80=93

WG discu= ssion needs to occur on whether flowspecification

&=23160;=

&=23160;=

Proposed= WG LCs (3/30 and 4/8)

--------= --------

1) draft= -ietf-idr-bgp-open-policy-08 =E2=80=93 on hold pending&=23160; revision -= 09

2) &=231= 60;draft-ietf-idr-flowspec-l2vpn-13 =E2=80=93 in slides for 4/8

&=23160;=

&=23160;=

Proposed= Adoption calls &=23160;

--------= ---------------

draft-cl= -idr-bgp-ext-com-registry-udpate-00.txt

&=23160;=

&=23160;=

&=23160;

&=23160;

&=23160;

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Idr mailing list
Idr=40ietf.org
https://www.ietf.org/mailman/listinfo/idr
--5e8e39c5_7aa0799a_16f-- From nobody Wed Apr 8 17:13:06 2020 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 6AF1E3A1A5B for ; Wed, 8 Apr 2020 17:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5Eb6gIEk0LUa for ; Wed, 8 Apr 2020 17:13:03 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4e::708]) (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 235CE3A1A58 for ; Wed, 8 Apr 2020 17:13:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BEsZtemGCHT1/RIq4MV/9onKBi2j2rpL34lAsK3LITj8/vzcd0v1QsPX0R1RnP+4q4GuIyvVACqwcBZsLRsweWDnkUkpmGE9kbpYXw/RNYyW1qfHjijEqedNT3uYWR6B9j9Gs5A484jFZgHYfJhHcvsRkhVviO5MuJoXxR4RrO3x4ZNkqbJUCmYuxo0XvzbfHdLhtYrHjyzYXcd9VBuzPdMYJwWywtTA5b/lQtVWKW1FM6f/e4x/0zJ8d2nmHscYkG1qwHbDFfY6vksd8JeE43mHvVQQzhXrvcln8tulBtinkiEtzvzY+82RV6+W7dj5w03VWNigAfQ0rm135J+5eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ejedCkt+NdHFos17QKNrq/EMvBI8adVJ0SifxaY+cAM=; b=m0uzQ1aKXH0jA9VI3bOdejKKHmBPHaVfEz/nliRY5DbAvKyDkVzRlPorwuRUcrVAoYuQRIlQ5Eh/qvV18cdK7FUiMQvu9MJi9EenzqTTSwZTU2EgTOdqIg/8SkbLhUprNy0Le8ycEIaFxUzIUi/UGoJKp5qdV8Vai3dK2pdhxKcHLTBZ7I7/ZXgXK5i/CEgxSxIZlapE9iNX2YhxJ+cIDIl9J/mRVZ/G0nyCSrOkr4+Wg90gNzwjSr8Gll+RHhBbvrgQ+4sTZ+DFY3RaGur+gFSn9mjkLIfRzEIXNvRfii47gGe/cEc3Evl3KEuVc032NgokaOkO/21EtKxTOs94mQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ejedCkt+NdHFos17QKNrq/EMvBI8adVJ0SifxaY+cAM=; b=sw6bt6uBYa611OkncnynAyOYyna+IqFJaxzWqe91klp+PQFn9+BYcuNTa6JKa+xl/6qNxT1oh/RhIhUJzBm5qLs89yVdLhp44DKNpnq8/gZhVD61eqxVrARuHzQe7AsUMKlbcn/s3IO7xiYgXbF2tNlsInSsrK5gPsevO1BtrXE= Received: from BY5PR08MB6312.namprd08.prod.outlook.com (2603:10b6:a03:1f0::19) by BY5PR08MB6183.namprd08.prod.outlook.com (2603:10b6:a03:1e5::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.21; Thu, 9 Apr 2020 00:13:00 +0000 Received: from BY5PR08MB6312.namprd08.prod.outlook.com ([fe80::a078:d4f7:d478:a679]) by BY5PR08MB6312.namprd08.prod.outlook.com ([fe80::a078:d4f7:d478:a679%7]) with mapi id 15.20.2878.021; Thu, 9 Apr 2020 00:13:00 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Linda Dunbar , Susan Hares , 'IDR List' Thread-Topic: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Thread-Index: AdYJ88Fzwt+5o6y3SbatjJfErRQpEwEDTVmw Date: Thu, 9 Apr 2020 00:13:00 +0000 Message-ID: References: In-Reply-To: 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=jun.hu@nokia.com; x-originating-ip: [135.245.20.15] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 83e3457f-f64c-48f8-7f08-08d7dc1ac365 x-ms-traffictypediagnostic: BY5PR08MB6183: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR08MB6312.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(366004)(376002)(39860400002)(136003)(396003)(346002)(966005)(7696005)(316002)(64756008)(5660300002)(9686003)(2906002)(8936002)(66446008)(55016002)(8676002)(6506007)(76116006)(33656002)(66556008)(52536014)(110136005)(81166007)(66476007)(66946007)(86362001)(26005)(478600001)(53546011)(66574012)(186003)(81156014)(71200400001); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fxaEYlxZhUIsSyBHQFbMTEYBkhxcq7Qws/lBxvaItBImbiEl/gm3X3pd1z6vZgT3DQ9xQReG1ERy+KjZqsoK1p2yZt3XXumgmCMvoHydfcKBC6qwTHeB4tprbuVyByaEeR04mS4fEjp6AqHNv9XGLRmPj7iNMXgHrdbQxxAc7MGqBmewr4bIKeuj3D2CACMym/2twjNPueXDfauTpAO00zepvJ2gTnFvNN0Z1lqk2K+B2sWElpP66FebHs7XOxSRL3FsXdV9HwF4Xz78wtuJp2eJJoCj1ocVIG7SXvobAEs1Aipn9A1DPqh5hivXJuab1LMeu2nypFDiz9sn0L4b1uc30Dr6LM4MZXp6zZEZ+YQBQmTxEGeMt5n75kxjnuV4RcV5tIpJkY2UkimRNizRPOqL970mzt9LPRLnkvx+o4gXKBc5hjAv3GBEQ/608qkjELRiq8q5pyT3fzPHkq08WPcS9YHTOUtjwabpcBfc91owAyI6ISAwQbpgNPNiUxJ3dnsGFEx/fxBZffoTof4hIQ== x-ms-exchange-antispam-messagedata: SoHUsaAtjuulC19e+FoZMKivAkHVo1ZicEy3ZVsLGLaZ0SPvRA3vWuS4I+iGafv0cUyU0OXW2B/H7gooNV6GdpKBtLmTv17leplkFVMI5i4pP5pN5KCd4FmpKBuzTq8ko64bN4waNFXz44mjfnAOUA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR08MB6312D69C2994387B0F31109B95C10BY5PR08MB6312namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83e3457f-f64c-48f8-7f08-08d7dc1ac365 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 00:13:00.0170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9MBdUkQfc0cR3Fr33sR8OszvnLEof3URy69jjrWy6aRwQy1UlG0QtU+Hdm3zvOYdqNInfM5ifLYw9i9XW/r+FA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR08MB6183 Archived-At: Subject: Re: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 00:13:05 -0000 --_000_BY5PR08MB6312D69C2994387B0F31109B95C10BY5PR08MB6312namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for replying late, Pls see my answer in line From: Idr On Behalf Of Linda Dunbar Sent: Friday, April 3, 2020 1:24 PM To: Susan Hares ; 'IDR List' Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week= WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-= ipsec-transport-mode-00 (3/30 to 4/13/2020 Jun, Need a few clarify questions for your draft. 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running be= tween IPsec peers? [Hu Jun] yes 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKE= v2 with the speaker without any configuration from the administer? If Node = B can only establish IPsec IKEv2 with another node C, does it matter if the= Node B receives or not receives the BGP update from the C? [Hu Jun] it is up to the implementation, there are two options: * create the tunnel upon receiving BGP update * create tunnel only when router need to forward a packet to a= destination that need to be reached via IPsec tunnel either way works 1. How does the BGP UPDATE ease the IPsec configuration? Does it ease t= he configuration on the BGP UPDATE speaker? Or does it ease the configurati= on of the receiver? [Hu Jun] think of a simple case, where there are 3 routers: A , B and C, A = has subnet S behind it that require IPsec protection, if B or C need to for= ward a packet to S, it must be over an IPsec tunnel; so traditionally, you = would configure two tunnels on A: A->B and A->C, then you would also need t= o configure a tunnel B->A on B and a tunnel C->A on C, so in total, there a= re 4x tunnel configuration on 3 routers; but now with my draft, you just ne= ed to configure A to advertise a BGP update for S which include ipsec confi= g, there is no per-tunnel configuration on A, B or C. 1. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is = there still "Private Routing Instances"? [Hu Jun] the concept of public and private routing instance is to separate = trust network from un-trusted network; Typically, for security reason, you = want to separate trusted network from un-trusted network by using different= routing instance, for example, internet is un-trusted network, while an e= nterprise intranet is trusted network, they are different routing instance;= then an payload packet from the intranet is encapsulated into an IPsec tu= nnel, the result ESP tunnel packet is forwarded via internet. But public routing instance could same as private routing instance if you h= ave good reason to do so, there is nothing in protocol level prevent that On Page 3, the draft states that only "Local Tunnel Endpoint address, Publi= c Routing Instance and CHILD SA traffic selector address range" are adverti= sed by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the no= de? Or can be a specific Ingress or egress port of the node sending out the= BGP UPDATE? [Hu Jun] this total up to the operator, both loopback or a physical interfa= ce address could be used, but typically a loopback address is prefer for st= able reason Thank you very much. Linda Dunbar From: Idr > On Behalf Of = Susan Hares Sent: Monday, March 30, 2020 7:07 AM To: 'IDR List' > Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and= draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 This begins a 2 week WG adoption call for two drafts BGP provisioned IPSEC= infrastructure 1) draft-hujun-idr-bgp-ipsec-02.txt: BGP Provisioned IPSEC Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/ 2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt: BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec-transport-mode/<= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=3D02= %7C01%7Clinda.dunbar%40futurewei.com%7Cdb1e68b21c294ff7e40f08d7d4a2e5e4%7C0= fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637211668440604245&sdata=3DXROXZN= 5YTy5GQEToYyAkFNHx71%2B%2FXnln1QJjMzeRQ6I%3D&reserved=3D0> These drafts were presented at IETF 104 and IETF 105.. At IETF 105, there was a detailed discussion on the security issues. After IETF 105, the author modified his draft to take care of the Issues mentioned. Discussion during the WG Adoption should examine: 1) Has this draft addressed the necessary security issues to be adopted as IDR WG draft? 2) Is this useful generic IPSEC functionality for networks? The EVPN related to IPSEC continues in BESS. This draft is considered here as a general feature. 3) Are there any deployments of this draft? Stay safe and healthy... Sue --_000_BY5PR08MB6312D69C2994387B0F31109B95C10BY5PR08MB6312namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for replying late, Pls see my answer in line <= o:p>

 

From: Idr <idr-bounces@ietf.org> On = Behalf Of Linda Dunbar
Sent: Friday, April 3, 2020 1:24 PM
To: Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org= >
Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE:= 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-i= dr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

 

Jun,

 

Need a few clarify questions for your draft.

 

  1. Does  draft= -hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers= ?

[Hu Jun] yes

 

  1. Does receiving the IPsec BGP UPDATE triggers a node to start the &nbs= p;IKEv2 with the speaker without any configuration from the administer? If = Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the = BGP update from the C?

[Hu Jun] it is up to the implementation, there= are two options:

        1. create the tunnel upon receiving BGP update<= /li>
        2. create tunnel only when router need to forward a packet to = a destination that need to be reached via IPsec tunnel

either way works <= /i>

  1. How does the BGP UPDATE ease the IPsec configuration? Does  it e= ase the configuration on the BGP UPDATE speaker? Or does it ease the config= uration of the receiver?

[Hu Jun] think of a simple case, where there a= re 3 routers: A , B and C, A has subnet S behind it that require IPsec prot= ection, if B or C need to forward a packet to S, it must be over an IPsec t= unnel; so traditionally, you would configure two tunnels on A: A->B and A->C, then you would also need = to configure a tunnel B->A on B and a tunnel C->A on C, so in total, = there are 4x tunnel configuration on 3 routers; but now with my draft, you = just need to configure A to advertise a BGP update for S which include ipsec config, there is no per-tunnel configurat= ion on A, B or C.

  1. How to differentiate  Public Routing Instances?  

If the payload packet wi= thin the IPsec tunnel are simple IP forwarding, is there still “Priva= te Routing Instances”?

[Hu Jun] the concept of public and private rou= ting instance is to separate trust network from un-trusted network; Typical= ly, for security reason, you want to separate trusted network from un-trust= ed network by using different routing instance,  for example, internet is un-trusted network, while an ente= rprise intranet is trusted network, they are different routing instance; &n= bsp;then an payload packet from the intranet is encapsulated into an IPsec = tunnel, the result ESP tunnel packet is forwarded via internet.

But public routing instance could same as priv= ate routing instance if you have good reason to do so, there is nothing in = protocol level prevent that

On Page 3, the draft states that only “Local T= unnel Endpoint address, Public Routing Instance and CHILD SA traffic select= or address range” are advertised by the BGP.

Is the Local Tunnel Endp= oint address same as the LOOPBACK address of the node? Or can be a specific= Ingress or egress port of the node sending out the BGP UPDATE?

[Hu Jun] this total up to the operator, both l= oopback or a physical interface address could be used, but typically a loop= back address is prefer for stable reason

 

Thank you very much.

 

Linda Dunbar

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 7:07 AM
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.= txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020=

 

This begins a 2 week WG adoption call for  two = drafts BGP provisioned IPSEC infrastructure

 

1) draft-hujun-idr-bgp-ipsec-02.txt:

BGP Provisioned IPSEC Tunnel Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/<= o:p>

 

2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt:<= o:p>

BGP Provisioned IPsec Transport Mode Protected Tunne= l Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-= idr-bgp-ipsec-transport-mode/

 

These drafts were presented at IETF 104 and IETF 105= ..

At IETF 105, there was a detailed discussion on the = security issues.

After IETF 105, the author modified his draft to tak= e care of the

Issues mentioned. 

 

Discussion during the WG Adoption should examine:

1) Has this draft addressed the necessary security i= ssues to

    be adopted as IDR WG draft?<= o:p>

 

2) Is this useful generic IPSEC functionality for ne= tworks?

 

   The EVPN related to IPSEC continue= s in BESS.

   This draft is considered here as a= general feature.

 

3) Are there any deployments of this draft?

 

 

Stay safe and healthy… Sue

 

--_000_BY5PR08MB6312D69C2994387B0F31109B95C10BY5PR08MB6312namp_-- From nobody Wed Apr 8 18:27:57 2020 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 5903B3A1D03; Wed, 8 Apr 2020 18:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha3FFgMfy3oe; Wed, 8 Apr 2020 18:27:50 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 784943A1D01; Wed, 8 Apr 2020 18:27:50 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id i19so2184440ioh.12; Wed, 08 Apr 2020 18:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BqIQDjK5hazMlK5wx7TCMzTM8uHCHcf48mHgb2nMkx8=; b=UloNY7EHVGu/esWGcDxOXDbIXRWsr+5n+IsIr2c2ionwiKMI7nPsbt4be3TrcBB9/u bPTQKqhFCmrs99FMOyzqFaqmst4uIVdo4NhkvoKzK5LaB6i+MXd/6KURper57Q8taocm AHNnAY9O4viY7jjVIDNzkYq+Wz2lGbMJsdWYHMaU4DRdrOSQv6Uj0E8wAtJSk39d72iC v/EXg8rz3HTaarWUEgI+mRgV/ThxPk6Wof7yJSGMXDf/70APanPXmgAlVPIAAzbkOGDu inQTk2Yrw3D0FXxW0dtd48rTjLHNVFWoWCM9Nib9euJxv96LRgLD4HLcE7YTn1NWjTMW RySA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BqIQDjK5hazMlK5wx7TCMzTM8uHCHcf48mHgb2nMkx8=; b=bxFJc1QgFfaFxZp3/H6aSRwpctbY8K/HiUcs+U9NGavRObv9SjrTWnAkvSOf2zqv7Z nt9MVczxLbOqYaUc2MXISOyJmiQlEKC0VeHDZ8t3TwepMvUsMPNKh1YnzLOjXxjOXBGA Pj/gGcLRpUf4NAvGGKGvmd/+Yi04pGzUpG7kfJV2Zu7hP7jlAO6OYI2+qrbnqAHknrhL pyCd/4ake0HgeEKon/ImaEKM7ZqeQFaa4fpWhrOEnBuJAB0vgcwJyhcu2FDcewd7Itj3 C6NgGUOppO0g62baoDkW46lhHru44uiHWKS563dw5azxZbJLthHhyOLAzvzcqnARC/zo d8DA== X-Gm-Message-State: AGi0PuYzR4lmRJlBNjIE7Nr24TMfHlTTl7mKdhYEmAi20ySJoUMaSr+M 2/ZJEv2B7pwjq2x7mQXJ2oQjeL/BeJbBODRHOtIq/6KjB3L6Lw== X-Google-Smtp-Source: APiQypJ5Y/oeF7zs6qqRnZdUuSZIvhFB5ZJNe9D43yDN/ZaWNOAuZiKyYnLZh4nIIilCus7XRs21Afk2u8ic2vcbjDY= X-Received: by 2002:a02:8666:: with SMTP id e93mr425663jai.0.1586395669394; Wed, 08 Apr 2020 18:27:49 -0700 (PDT) MIME-Version: 1.0 References: <158629580378.13606.6350807287790835622@ietfa.amsl.com> <3A63035D-C0F3-4830-8EBF-8A99411A01C6@tix.at> In-Reply-To: <3A63035D-C0F3-4830-8EBF-8A99411A01C6@tix.at> From: Gyan Mishra Date: Wed, 8 Apr 2020 21:26:58 -0400 Message-ID: To: Christoph Loibl Cc: gen-art@ietf.org, last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000058fab005a2d1867a" Archived-At: Subject: Re: [Idr] [BULK] Genart last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 01:27:52 -0000 --00000000000058fab005a2d1867a Content-Type: text/plain; charset="UTF-8" Sorry about the typo in the Draft name specified was incorrect. Document: draft-ietf-rmcat-wireless-tests-08 - should be "draft-ietf-idr-rfc5575bis-20" Kind regards Gyan On Wed, Apr 8, 2020 at 3:36 AM Christoph Loibl wrote: > Hi Gyan, > > Thanks for the review. I will collect the results of all reviews and > comment on those later. I need to note that the reviewed document is > draft-ietf-idr-rfc5575bis-20 not rmcat-wireless-tests ;-) : > > On 07.04.2020, at 23:43, Gyan Mishra via Datatracker > wrote: > > Document: draft-ietf-rmcat-wireless-tests-08 > Reviewer: Gyan Mishra > Review Date: 2020-04-7 > IETF LC End Date: 2020-04-8 > IESG Telechat date: Not scheduled for a telechat > > Thanks, > > Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --00000000000058fab005a2d1867a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000058fab005a2d1867a-- From prvs=2366e023cc=aelsawaf.c@stc.com.sa Tue Apr 7 03:14:42 2020 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 84B453A1A7E for ; Tue, 7 Apr 2020 03:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQQ5PuDqIdFr for ; Tue, 7 Apr 2020 03:14:40 -0700 (PDT) Received: from ESGRYBM03.stc.com.sa (esgrybm03.stc.com.sa [212.118.156.88]) by ietfa.amsl.com (Postfix) with ESMTP id D91E43A1A7C for ; Tue, 7 Apr 2020 03:14:39 -0700 (PDT) X-AuditID: d4769c58-cc9ff7000000df62-11-5e8c528d1f5b From: Ahmed MostafaSaleh ElSawaf To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAGM7EUQ Date: Tue, 7 Apr 2020 10:14:17 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_f6d4e11833144e1f93418814076ee84astccomsa_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA5VUa1ATVxh1NwHDY3UJCXxEselWO4jKI0ENLVC1doRRq4Lj9AmGsEBq2GA2 QaFTi68qCKhFLY2C0OID1MKAWkYYW1NpFbHQ2iJipVYBlZcgIqUt0rsJ4FJ/dX/sfHO+e893 9txzVyQQ/0jIRFrGSBsYtY6ydxSelOwvmZMZnhHp19k/Q9V+sw1X/dPZLlyAhxYWDuKhBzuu 263E30nFgqLVxqQIbRzjGxKkZhi9UW2k5TE0qwmmIla/Ll9og7R6hqXk2phgKoCSJ+rUGjqB ZozBlDoxkWZiqBBH+XNPEFqmZeQ0o9HHaJm4YCosYsUclWpu4Bx/KmR1PC3XMrF6Q8Lacqf4 BxebBYlt722s6jwsSMU2r0rHHERABkBl3m0hV9uTKmhIr5rI1RIyCBp27RBwtSu5Hjry8gQ2 3AD1A9cwW62A3std1lpIToe8oRJUi0QEGQhFfy3mYDE5D4b2D9lztQM5H0pK+6zLMdINBmpO 4lwtIN2hqeUwbpNDQmFVncBWS+HB3ad2tjVrof6TzdaaIF3g8uctQtsaD7hwvFG4B3Mx86jM vC1m3hYbPhvyKx/Z2+pZcLSgQzBa1357F+fj+djEYkzyRsSS8LcXLfdT+rBGjY9Gn+DDqssw dPi/JB16qwIr7u/2sWCkCKOcCfO9tEixnTqJTU6wYDswEU7JiKX+4ZFi12h9THK8mo2PYk3R CVqWRUdNSYn2sIxI8aSxnsGko1lKQsSuRDAxBkebdOsQ0blVGXwiht7A6mgjyiI1jQjbgAa7 84awiVqNVm9io0wGnQUDkQDRyjLRIiJGnZxCG/S2YRZMg85ur0Am1ehRrBljlL9SEahQKJQK f/9A5f+DKXfihgppJONQutfRdCJtGJ1yAOWC8iSwCRMmiN0MdBy9MVarQ9L5dgARzn23C79t c8SdaD+3C/HyO1ZTPIlub9QYx8jz5UVi4W/ok2XjB463Bhc5cP44yiQsumO0QW0yIsfRbY1i 0XW1YFswkTPlYVMuZhPVCQjmq5YQTku50xpt2RS7Et0rEOo8ilrVehBS7gPHWHhKPYmGZKTU 7dkAvsoa7BgmulCd94VA1FtciN4D3FssZPQMLZtKrDmLtkq5rfEmZrypMnciiptJ8rpWhTI3 4kleeqR4Mq/BiUR0tefTx9M90ymTEwPcLo9xw/hS27EjOLoKQOQHr0Nnif6V//HLlXDkBDmP dGx2oVRy4XYaAa1uAXGVw0YpeGZNJRo5s6Rj5HwBiiMY+r0ccoSc+1/ikHOmH4e8rLN2sLOt dSLcb65zgJLhnU5QO5TrBBfNpc5QWNFCQM7vlZOh7KfPSBjMzHWBxs7vpPC04pIM+h4+kkHN tqopkNpT7wn9bVenQVrLthfgQfGvcijbm0FBVUEWhagGXoKf+7dPh8HNW70gu/WAF/xR2T4T Om81eYO56/4syEnL9oO0fd1+cKJjp7KdSxb+LFno9/9cshqid3HJGmmNJku1KY1L1gg6kqy5 HDjGMi5Z8zZZkzU2gO+WLBX3niTMbVX+CSl32HeXLKq7U9f4zcdbB1+LPXvNdfYHfa+U3/Nc /JDa0nved41Pg8jBXLFMtzh0KHc5XqosgtPON0+E+B6rGqz3Mi+In7kmOEX7IXWlrLQ3PSmg a+GhrJrHdZKmTW63l/VdedQ8vF6UpSQ/LYCLkeHJPySkH/zEMuPG9VtTZtdWe3dF4bu/PtZ7 fEN4tamsNc436nFzwe2aorCVCpVlR1tmz6ma7O6GJLvT0fvl3/slN0F+eZbfXumpxx1/D+wu PrpC9ZFX4PDw0uUvs5d6Vi/Z516bvSfkRJVDa7Vwxtb5bkrBV5Kjr163PHE98/6breV9RWu3 hw7YB+BT7XqUx1MoIRuv9vcWGFj1vxq0dCfhBwAA Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 07:01:08 -0000 --_000_f6d4e11833144e1f93418814076ee84astccomsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dears I believe it is valid use case , I add my voice to support the adoption The adoption of SR is increase within SP and PMTU is an important and Major= topics that should be handled in right way For below question 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? The problem statement is clear , and the answer Yes. It is vital requirement= to have a right encapsulation for SRv6 without take in the consideration th= e underneath environment. 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. No Concern Thanks BR Ahmed El Sawaf From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 3:36 PM To: 'IDR List' Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week= WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03= .txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_f6d4e11833144e1f93418814076ee84astccomsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dears

 

I believe it is valid u= se case , I add my voice to support the adoption

 

The adoption of SR is i= ncrease within SP and PMTU is an important and Major topics that should be h= andled in right way

 

For below question 

 

1) Is there a need for this mechanism in networks usi= ng

        MPLS-= SR or SR-V6 and SR policy?

 

The problem statement i= s clear , and the answer Yes. It is vital requirement to have a right encaps= ulation for SRv6 without take in the consideration the underneath environmen= t.

 

 

2) Are there any error handling issues besides what i= s being

     Taken care of in RFC775= 2bis-03.txt

 

 

3) Do you think this draft is ready to be adopted?

     In this category, pleas= e list any concerns you have

     regarding adoption.  Th= is category can include

     general concerns about= BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  &= nbsp;

 
No Concern 

 


 


 


Thanks 

 


 




 


 


BR

Ahmed El Sawaf




 






From: Idr [mailto:idr-bounces@ietf.org] On=
 Behalf Of
Susan Hares

Sent: Monday, March 30, 2020 3:36 PM

To: 'IDR List' <idr@ietf.org>

Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt -=
 2 Week WG adoption call (3/30 - 4/13)






 


This begins a 2 week WG adoption call for draft-li-id=
r-sr-policy-path-mtu-03.txt



 


You can view this draft at: 


https://datatracker.ietf.org/doc/draft-li-idr-sr-po=
licy-path-mtu/


 


This draft distributes path maximum transmission unit=
 for the



SR policy via BGP.  


 


Any discussion regarding on whether one desires =



SR Policy should be clearly distinguished from the 


Technical discussions on the mechanisms to pass SR po=
licy MTU.



 


The questions for the people to discuss on this draft=
 are: 



 


1) Is there a need for this mechanism in networks usi=
ng 



        MPLS-=
SR or SR-V6 and SR policy? 


 


 


2) Are there any error handling issues besides what i=
s being



     Taken care of in RFC775=
2bis-03.txt


 


3) Do you think this draft is ready to be adopted? 


     In this category, pleas=
e list any concerns you have


     regarding adoption.  Th=
is category can include 


     general concerns about=
 BGP-LS, MPLS-SR, 


    SR-V6, and SR-Policy.  &=
nbsp;


 


Cheers, Sue Hares  


 


 


 


 


 

The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_f6d4e11833144e1f93418814076ee84astccomsa_-- From nobody Thu Apr 9 00:05:15 2020 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 D805A3A0C5B for ; Thu, 9 Apr 2020 00:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW8t7PIIMcRa for ; Thu, 9 Apr 2020 00:05:11 -0700 (PDT) Received: from ESGRYBM03.stc.com.sa (esgrybm03.stc.com.sa [212.118.156.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD3A3A09D8 for ; Thu, 9 Apr 2020 00:05:10 -0700 (PDT) X-AuditID: d4769c58-cafff7000000df62-bb-5e8ec9252c50 From: Ahmed MostafaSaleh ElSawaf To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAGM7EUQAF7Y6MA= Date: Thu, 9 Apr 2020 07:04:55 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_c15b3e8406a74433ab6c39a5087f29b4stccomsa_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA5VUa1ATVxRmN4SswJU1PHKJonG1I74QEjqCA7ZqrQ9G64DTodUGk7CS1LCJ 2QTBOpWqFdHKKFKLqPgCH0GEonYEoQq+UUZFwRfSOiDFBF90kNLx0bssj0V/NT92znznnu98 +c65lxBJK4GcMDBW2sJojJSbu+tRn5+LJ350JUMdfNUZGOZ40IKHvW5zuH6Kz87L68Jn73Te ES/Av07FIrQaa1KMIYGZNDVCwzAmq8ZKK+JpVhdJxSycoZjGQwYTw1IKQ3wkFUopzEaNjk6k GWskpTGbaSaemuqu+OAXgY4ZGAXN6EzxBiYhkpoT88XEsLCPwyeGUFMX6mmFgVlqsiQuOe6h r7hUJzY3qZMv7coUpWKO6I3YIAKSofB8Wa0bF7uRYbB+Y7mEi33ICFi/KU3Exd7kcujMzRXx uAXe6LyF8fEUWOpswjdiBOFKjoYPakdwMCDDYXH7QwkHS8nJ8EgBzsEY6Qc7q492xyJSBu83 78F5BSTMK78u4mNf+KTprZg/swSm1zglPOUQeGVHsyt/xh9WHr7rugUjcwRUOYKSHEEJj0+A e0+3u/HxeHhwn1PUG18724QL8b2YxI75zIyZFf3V9HnBqiDWqgvSmRKDWE0JhuZ9O2lX7CnM 3vEsqAojCYzyBDl/paulYk0Sm5JYhaVhBE7JQVRItFrqrTXFp+g1rD6OtWkTDSyLpkv5gupz GWrp4L6cxWakWcoHjDyPYNAHa23GZYjo9YUMIRFDr2CNtBWtHzUclBk3q6UyQRPWbNAZTDY2 zmYxVmGQECHaqDXoEIjXpKykLSa+WRWmQ+PaKpL76kxokxlrXIhKGa5UKlXKkJBw1f+DKRm4 kYk0kglooZfRtJm29HbZjuZPBQDMxcVF6mehE+jkpQYjki60A4Lll1D1EGGad0QGHGWbEK8w 021KAHg2DiUGMAp8GQmSb6O/LB/YcKA1ODGI88dd7sOia0VbNDYrchxd0DgW3dAqbA1GeFL+ vHIpa9YkIlio2gdc41SD3hSv2Bu0cqP17EW71fqDBu5oH4tAaQAQm5BSv/4GQpXV2CGMqLyQ u19EvLTnoW8n95W6MiaGlg8DygJU6suV6m3MQFPlMnCG60kKst0K5X7AJQslvAQJTiSiizW/ R9evU64AOFflP6CZUKoDy8fRVYBgb+QyNEv0PL7nlzcovcg505Ph7ZKCfRzo0QN2uwUB7F6H Hkxg1jDeLN8+cqEAZT6Gnpc6d5jdegCH2Sc7cJib8ZsYZr6rkMANLY8lsLXx+iBY9G6DB7z2 ZrcHPJ9T7AnzTjUDmP3HaS9YcvMXEnZt3j0E3m075wvfnrosh38/b5fD6nXlQ2HqixsBsKOl ZjhMb143Aj6x1ylgydafKFi+L4NCVJ2jYG3Hj6Nh1w9rA+G2x9sD4aPTjrGw7eH9cTDnaet4 mJ2+LRimZz0LdnCbhfdvFnrxP9iseu0mbrN6Ur2bFctu5jarB+3ZLA8O7GMZsFndKb/+BkK3 5Kn48C2NhtVFk8EYkWrar59bkvcUL2rUTlcttBdWHiHIKbPfNcydKSl9+nx+/ou5/h2LX9QW nmCSo+p32+bjY9MO7Wko+Kcl+t6XRa9GrDqr3/mmLWt/Q3hIuexAyo7196oXE6krti8qnHli nT22ZPAZd8eawzL9d//+Xlr+MqbiwUmv+1HOwjkt8+q87EcPfJ+a9uabNdkNXaFzD05Qalt8 ZSu17qMeyl5JgiZltw9NUpePWXvuWErUlElDn1Z89smM0ENnL5csqL4zzbnrTLg4p8DEzEop Cj8mBs7LNXU3DXkXA1XzzGX5305W3HqUf/v4hurVmbh0/SLr2FV2y3r1n1tqrqoam0dmEZQr q9eEjBNZWM1/JPL34dQHAAA= Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 07:05:14 -0000 --_000_c15b3e8406a74433ab6c39a5087f29b4stccomsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dears I believe it is valid use case , I add my voice to support the adoption The adoption of SR is increase within SP and PMTU is an important and Major= topics that should be handled in right way For below question 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? The problem statement is clear , and the answer Yes. It is vital requirement= to have a right encapsulation for SRv6 without take in the consideration th= e underneath environment. 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. No Concern Thanks BR Ahmed El Sawaf From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 3:36 PM To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week= WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03= .txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_c15b3e8406a74433ab6c39a5087f29b4stccomsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dears

 

I believe it is valid u= se case , I add my voice to support the adoption

 

The adoption of SR is i= ncrease within SP and PMTU is an important and Major topics that should be h= andled in right way

 

For below question 

 

1) Is there a need for this mechanism in networks usi= ng

        MPLS-= SR or SR-V6 and SR policy?

 

The problem statement i= s clear , and the answer Yes. It is vital requirement to have a right encaps= ulation for SRv6 without take in the consideration the underneath environmen= t.

 

 

2) Are there any error handling issues besides what i= s being

     Taken care of in RFC775= 2bis-03.txt

 

 

3) Do you think this draft is ready to be adopted?

     In this category, pleas= e list any concerns you have

     regarding adoption.  Th= is category can include

     general concerns about= BGP-LS, MPLS-SR,

    SR-V6, and SR-Policy.  &= nbsp;

 
No Concern 

 


 


 


Thanks 

 


 




 


 


BR

Ahmed El Sawaf




 






From: Idr [mailto:idr-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Monday, March 30, 2020 3:36 PM

To: 'IDR List' <idr@ietf.org&g=
t;

Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt -=
 2 Week WG adoption call (3/30 - 4/13)






 


This begins a 2 week WG adoption call for draft-li-id=
r-sr-policy-path-mtu-03.txt



 


You can view this draft at: 


https://datatracker.ietf.org/doc/draft-li-idr-sr-po=
licy-path-mtu/


 


This draft distributes path maximum transmission unit=
 for the



SR policy via BGP.  


 


Any discussion regarding on whether one desires =



SR Policy should be clearly distinguished from the 


Technical discussions on the mechanisms to pass SR po=
licy MTU.



 


The questions for the people to discuss on this draft=
 are: 



 


1) Is there a need for this mechanism in networks usi=
ng 



        MPLS-=
SR or SR-V6 and SR policy? 


 


 


2) Are there any error handling issues besides what i=
s being



     Taken care of in RFC775=
2bis-03.txt


 


3) Do you think this draft is ready to be adopted? 


     In this category, pleas=
e list any concerns you have


     regarding adoption.  Th=
is category can include 


     general concerns about=
 BGP-LS, MPLS-SR, 


    SR-V6, and SR-Policy.  &=
nbsp;


 


Cheers, Sue Hares  


 


 


 


 


 

The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_c15b3e8406a74433ab6c39a5087f29b4stccomsa_-- From nobody Thu Apr 9 00:59:12 2020 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 5CBCE3A0E03; Thu, 9 Apr 2020 00:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WGwZZd-VIQHK; Thu, 9 Apr 2020 00:59:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4C33A0E02; Thu, 9 Apr 2020 00:59:09 -0700 (PDT) Received: from lhreml715-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4D1BDDE4345114867F16; Thu, 9 Apr 2020 08:59:07 +0100 (IST) Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 9 Apr 2020 08:59:07 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 9 Apr 2020 08:59:06 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.59]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Thu, 9 Apr 2020 15:58:45 +0800 From: "Chengli (Cheng Li)" To: Aijun Wang CC: "Ketan Talaulikar (ketant)" , "Susan Hares" , IDR List , SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aD///KXAP/+ep1Q Date: Thu, 9 Apr 2020 07:58:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029ADF67dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 07:59:11 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB029ADF67dggeml529mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWlqdW4sDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBwbGVhc2Ugc2VlIG15 IHJlcGx5IGlubGluZS4NCg0KQmVzdCByZWdhcmRzLA0KQ2hlbmcNCg0KRnJvbTogQWlqdW4gV2Fu ZyBbbWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY25dDQpTZW50OiBUaHVyc2RheSwgQXBy aWwgOSwgMjAyMCAxMjowOCBBTQ0KVG86IENoZW5nbGkgKENoZW5nIExpKSA8Y2hlbmdsaTEzQGh1 YXdlaS5jb20+DQpDYzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50PTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPjsgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT47IElEUiBM aXN0IDxpZHJAaWV0Zi5vcmc+OyBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbSWRyXSBXRyBBZG9wdGlvbiAtIGRyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1tdHUt MDMudHh0IC0gMiBXZWVrIFdHIGFkb3B0aW9uIGNhbGwgKDMvMzAgLSA0LzEzKQ0KDQpIaSwgQ2hl bmc6DQpJIGFtIGNvbnNpZGVyaW5nIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW9zOg0KV2hlbiB0aGUg c2l6ZSBvZiBzb21lIHBhY2tldHMgb2Ygb25lIGZsb3cgYXJlIHNtYWxsIGFuZCBkbyBub3QgZXhj ZWVkIHRoZSBQTVRVIHZhbHVlLCB0aGV5IGFyZSBlbmNhcHN1bGF0ZWQgdXBvbiB0aGUgY29ycmVz cG9uZGluZyBTUiBwb2xpY3kgYW5kIHdpbGwgYmUgdHJhbnNmZXJyZWQgYWNjb3JkaW5nIHRvIHRo ZSBhcHBvaW50ZWQgcGF0aCBhcyBleHBlY3RlZC4NCkJ1dCBob3cgYWJvdXQgb3RoZXIgbGFyZ2Vy IHBhY2tldHMgd2l0aGluIHRoZSBzYW1lIGZsb3c/IFdpbGwgdGhleSBiZSBkcm9wcGVkIG9yIHRy YW5zZmVycmVkIHZpYSBvdGhlciBub24tU1IgcGF0aD8gSWYgc28sIHdpbGwgdGhlIFNSIGluZmx1 ZW5jZSB0aGUgZmxvd+KAmXMgaml0dGVyPw0KDQpbQ2hlbmddIFRoZSBQVE1VIGlzIHRoZSBtaW5p bXVtIHZhbHVlIG9mIHRoZSBNVFUgb2YgTGlua3MgYWxvbmcgdGhlIHBhdGggaWRlbnRpZmllZCBi eSB0aGUgU0lEIGxpc3QuIFRoZXJlZm9yZSwgdGhlIHZhbHVlIG9mIFBNVFUgZGVzY3JpYmVzIHRo ZSBsYXJnZXN0IHNpemUgb2YgdGhlIHBhY2tldCB0byBiZSBzZW50IGFsb25nIHRoZSBTUiBwYXRo LCBpbmNsdWRpbmcgdGhlIFNSIG92ZXJoZWFkLiBJZiB0aGUgcmVjZWl2ZWQgcGFja2V0IGlzIGxh cmdlciB0aGFuIHRoZSBQTVRVIOKAkyBvdmVyaGVhZCwgaXQgd2lsbCBiZSBkcm9wcGVkIG9yIGZy YWdtZW50ZWQuIEl0IGlzIHNpbWlsYXIgdG8gUlNWUC1URSBNUExTLiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMzIwOSNzZWN0aW9uLTIuNg0KDQoNClBNVFUgZm9yIHRoZSBwYXRoIGlz IG9uZSB1c2VmdWwgaW5mb3JtYXRpb24gYnV0IEkgdGhpbmsgY3VycmVudCBkcmFmdCBoYXMgbm90 IGVsYWJvcmF0ZSBob3cgdG8gdXNlIGl0IGluIGRpZmZlcmVudCBzaXR1YXRpb25zLg0KW0NoZW5n XSBXaWxsIGFkZCB0ZXh0IHRvIHNwZWNpZnkgaG93IHRvIGhhbmRsZSB0aGUgdmFsdWUgb24gdGhl IGluZ3Jlc3Mgbm9kZS4NCg0KV2l0aG91dCBTUiwgd2UgY2FuIHRlbGwgdGhlIGN1c3RvbWVyIHRo ZSBNVFUgb2YgdGhlIG5ldHdvcmsuIEJ1dCB3aXRoIFNSLCB0aGUgbmV0d29yayBNVFUgd2lsbCBi ZSBjaGFuZ2VkIGJhc2VkIG9uIHRoZSBwYXRoIGxlbmd0aC4gQ29uc2lkZXJpbmcgdGhpcywgbWF5 YmUgdGhlIFBNVFUgdGhhdCBkZXRlY3RlZCBieSB0aGUgaG9zdCB3aWxsIGJlIG1vcmUgY29udmlu Y2libGU/DQpbQ2hlbmddIEhvd2V2ZXIsIHRoZSBob3N0IGNhbiBub3QgZGV0ZWN0IHRoZSByZWFs IFBNVFUgb2YgdGhlIG5ldHdvcmssIGJlY2F1c2UgaXQgY2FuIG5vdCBiZSBhd2FyZSBvZiB0aGUg b3ZlcmhlYWQgb2YgdGhlIFNSIGFuZCBvdGhlcnMsIGl0IHdpbGwgZ2V0IHRoZSBtaW5pbXVtIHZh bHVlIG9mIHRoZSBMaW5rIE1UVSwgYnV0LCB0aGUgcmVhbGx5IFBNVFUgc2hvdWxkIGJlIHRoZSBQ TVRVIOKAkyBOIChTUiBvdmVyaGVhZCBvciBvdGhlciBvdmVyaGVhZCkuDQoNCkhvcGUgSSBoYXZl IGFuc3dlcmVkIHlvdXIgcXVlc3Rpb25zLiBUaGFuayB5b3UgYWdhaW4hDQoNCkFpanVuIFdhbmcN CkNoaW5hIFRlbGVjb20NCg0KDQpPbiBBcHIgOCwgMjAyMCwgYXQgMTc6MDcsIENoZW5nbGkgKENo ZW5nIExpKSA8Y2hlbmdsaTEzQGh1YXdlaS5jb208bWFpbHRvOmNoZW5nbGkxM0BodWF3ZWkuY29t Pj4gd3JvdGU6DQrvu78NCkhpIEtldGFuLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBjb21tZW50 cywgYW5kIHNvcnJ5IGZvciBteSBkZWxheSwgcGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUuDQoN ClRoYW5rcywNCkNoZW5nDQoNCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpDQpTZW50OiBGcmlkYXks IEFwcmlsIDMsIDIwMjAgNDoxOCBQTQ0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208 bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+OyAnSURSIExpc3QnIDxpZHJAaWV0Zi5vcmc8bWFpbHRv OmlkckBpZXRmLm9yZz4+DQpDYzogU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkcl0gV0cgQWRvcHRpb24gLSBkcmFmdC1s aS1pZHItc3ItcG9saWN5LXBhdGgtbXR1LTAzLnR4dCAtIDIgV2VlayBXRyBhZG9wdGlvbiBjYWxs ICgzLzMwIC0gNC8xMykNCg0KSGVsbG8sDQoNCkkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgZm9yIHRo ZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgYW5kIHNvbWUgZGlzY3Vzc2lvbiBwb2ludHMgZm9yIHRo ZSBXRy4NCg0KMSkgICAgICBXaGF0IGlzIHByZWNpc2VseSB0aGUgZGVmaW5pdGlvbiBvZiB0aGlz IOKAnHBhdGggTVRV4oCdIGZvciBhbiBTUiBQb2xpY3k/IEkgYW0gZ3Vlc3NpbmcgdGhhdCBpdCBp bmNsdWRlcyBhbGwgdGhlIGxhYmVscy9TSURzIHRoYXQgYXJlIHVzZWQgZm9yIHRoZSBTUiBwYXRo Pw0KW0NoZW5nXSBZZXMsIFRoZSBQYXRoIE1UVSBkZXNjcmliZXMgdGhlIGxhcmdlc3Qgc2l6ZSBv ZiB0aGUgcGFja2V0LCBpbmNsdWRpbmcgdGhlIG92ZXJoZWFkIG9mIExhYmVscy9TSURzL0lQdjYg aGVhZGVyL1NSSCBhbmQgb3RoZXJzLiBXaGVuIGVuY2Fwc3VsYXRpbmcgYSBwYWNrZXQsIHRoZSBs ZW5ndGggb2YgdGhlIHBheWxvYWQoaW5uZXIgSVAgcGFja2V0IG9yIHNvbWV0aGluZyBlbHNlKSBz aG91bGQgYmUgbGVzcyB0aGFuIHRoZSBQTVRVIG1pbnVzIHRoZSBvdmVyaGVhZCBvZiBTSUQgTGlz dC9TUkgvIEZSUiBvdmVyaGVhZCBhbmQgQmluZGluZyBTSUQgb3ZlcmhlYWQsIGJ1dCBpdCBpcyBh IGltcGxlbWVudGF0aW9uIGNob2ljZS4NCg0KMikgICAgICBXaGlsZSBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMzIwOSNzZWN0aW9uLTIuNiBkZWZpbmVzIOKAnHBhdGggTVRV4oCdIGZv ciBSU1ZQLVRFIExTUHMsIGl0IGRvZXMgZGVzY3JpYmUgdGhlIHByb2NlZHVyZXMgZm9yIHRoZSBz YW1lIGZvciBoYW5kbGluZyBJUCBwYWNrZXRzL3BheWxvYWRzIG9uIHRoZSBoZWFkZW5kLiBJdCBk b2VzIG5vdCBjb3ZlciB0aGUgc2NlbmFyaW9zIHdoZXJlIHRoZSBpbmNvbWluZyBwYWNrZXRzIG1h eSBiZSB0aGVtc2VsdmVzIGxhYmVsbGVkLg0KW0NoZW5nXVdlbGwsIEkgbWF5IG1pc3VuZGVyc3Rh bmQgdGhlIHRleHQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyMDkjc2VjdGlv bi0yLjYsIGJ1dCBJIHRoaW5rIGl0IGNvdmVycyB0aGUgc2NlbmFyaW9zIHdoZXJlIHRoZSBpbmNv bWluZyBwYWNrZXRzIG1heSBiZSB0aGVtc2VsdmVzIGxhYmVsbGVkLiBJIG1heSBiZSB3cm9uZy4N Cg0KICAg4oCcDQogICBUaGUgZm9sbG93aW5nIGFsZ29yaXRobSBhcHBsaWVzIHRvIGFsbCB1bmxh YmVsZWQgSVAgZGF0YWdyYW1zIGFuZCB0bw0KICAgYW55IGxhYmVsZWQgcGFja2V0cyB3aGljaCB0 aGUgbm9kZSBrbm93cyB0byBiZSBJUCBkYXRhZ3JhbXMsIHRvIHdoaWNoDQogICBsYWJlbHMgbmVl ZCB0byBiZSBhZGRlZCBiZWZvcmUgZm9yd2FyZGluZy4gIEZvciBsYWJlbGVkIHBhY2tldHMgdGhl DQogICBib3R0b20gb2Ygc3RhY2sgaXMgZm91bmQsIHRoZSBJUCBoZWFkZXIgZXhhbWluZWQuDQoN Cg0KICAgVXNpbmcgdGhlIHRlcm1pbm9sb2d5IGRlZmluZWQgaW4gWzU8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzMyMDkjcmVmLTU+XSwgYW4gTFNSIE1VU1QgZXhlY3V0ZSB0aGUNCg0K ICAgZm9sbG93aW5nIGFsZ29yaXRobToNCg0KDQoNCiAgIDEuIExldCBOIGJlIHRoZSBudW1iZXIg b2YgYnl0ZXMgaW4gdGhlIGxhYmVsIHN0YWNrIChpLmUsIDQgdGltZXMgdGhlDQoNCiAgICAgIG51 bWJlciBvZiBsYWJlbCBzdGFjayBlbnRyaWVzKSBpbmNsdWRpbmcgbGFiZWxzIHRvIGJlIGFkZGVk IGJ5DQoNCiAgICAgIHRoaXMgbm9kZS4NCiAgICAgICDigJwNCg0KMykgICAgICBTaG91bGRu4oCZ dCB0aGUgY29uY2VwdCBvZiDigJxwYXRoIE1UVeKAnSBmb3IgU1IgUG9saWNpZXMgYW5kIGl0c+KA mSBhcHBsaWNhYmlsaXR5IGFuZCBvcGVyYXRpb25zIGJlIGZpcnN0IGRlZmluZWQgaW4gYSAoU3By aW5nIFdHPykgZG9jdW1lbnQgYmVmb3JlIHdlIGludHJvZHVjZSBpdHMgc2lnbmFsbGluZyBhc3Bl Y3RzIGluIHByb3RvY29scyBsaWtlIEJHUD8gTm90ZSB0aGF0IHN1Y2ggYSBkb2N1bWVudCB3b3Vs ZCBicmluZyBpbiByZXF1aXJlbWVudHMgYW5kIGd1aWRlbGluZXMgZm9yIGhvdyB0aGUgdmFsdWUg aXMgZ29pbmcgdG8gYmUgY29tcHV0ZWQgYW5kIGl04oCZcyB1c2FnZSBmb3IgZGlmZmVyZW50IHN0 ZWVyaW5nIG1lY2hhbmlzbXMgb3ZlciBTUiBQb2xpY2llcy4NCltDaGVuZ10gVGhpcyBpcyBhIHJl YWxseSBzbWFsbCBidXQgdXNlZnVsIGFuZCBzdHJhaWdodCBmb3J3YXJkIGV4dGVuc2lvbnMsIGl0 IG1pZ2h0IG5vdCBuZWVkIHRvIHdyaXRlIGEgZHJhZnQgdG8gZGVzY3JpYmUgdGhlIHJlcXVpcmVt ZW50IGluc3RlYWQgb2YgYWRkaW5nIHRleHQgaW4gdGhlIGN1cnJlbnQgU1IgcG9saWN5IGFyY2hp dGVjdHVyZSBkcmFmdCBvciBpdCBjdXJyZW50IGRvY3VtZW50Lg0KDQoNCg0KNCkgICAgICBGaW5h bGx5LCBzcGVjaWZpYyB0byB0aGUgcHJvcG9zZWQgZW5jb2RpbmcgaGVyZSwgd291bGQgdGhpcyDi gJxwYXRoIE1UVeKAnSBub3QgYmUgbW9yZSBzdWl0YWJsZSBvbiB0aGUgQ1AgbGV2ZWwgc2luY2Ug ZWFjaCBTTCBtYXkgaGF2ZSBkaWZmZXJlbnQgc2l6ZSBsYWJlbCBzdGFjayBhbmQgZGlmZmVyZW50 IHBhdGhzIGFuZCBvbmUgZG9lcyBub3Qga25vdyB3aGljaCBTTCB3b3VsZCBiZSBwaWNrZWQgZm9y IGEgcGFydGljdWxhciBmbG93PyBTbyBtYXkgYmUgdGhlIGxvd2VzdCB2YWx1ZSBjb21wdXRlZCBm b3IgYWxsIFNMcyBpcyB3aGF0IGdldHMgYXBwbGllZCB0byB0aGUgcGFja2V0cyBhdCB0aGUgQ1Ag KGkuZS4gU1IgUG9saWN5KSBsZXZlbD8NCltDaGVuZ10gWW91IGFyZSBjb3JyZWN0LiBUaGUgUE1U VSBpcyBkZWZpbmVkIGZvciBTSUQgTGlzdC4gV2hlbiB3ZSB0YWxrIGFib3V0IFBhdGggTVRVIGZv ciBTUiBwb2xpY3ksIGl0IENBTiBiZSB0aGUgbG93ZXN0IHZhbHVlIG9mIHRoZSBQTVRVIG9mIFNJ RCBsaXN0cy4gQnV0IGRvIHdlIG5lZWQgdGhpcyB2YWx1ZT8gSWYgd2UgbmVlZCwgdGhlbiB0aGUg bm9kZSBjYW4gY29tcHV0ZSBpdCBiYXNlZCBvbiBQTVRVcy4NCg0KDQoNCg0KVGhhbmtzLA0KS2V0 YW4NCg0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KU2VudDogMzAgTWFyY2ggMjAy MCAxODowNg0KVG86ICdJRFIgTGlzdCcgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3Jn Pj4NClN1YmplY3Q6IFtJZHJdIFdHIEFkb3B0aW9uIC0gZHJhZnQtbGktaWRyLXNyLXBvbGljeS1w YXRoLW10dS0wMy50eHQgLSAyIFdlZWsgV0cgYWRvcHRpb24gY2FsbCAoMy8zMCAtIDQvMTMpDQoN ClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWxpLWlkci1z ci1wb2xpY3ktcGF0aC1tdHUtMDMudHh0DQoNCllvdSBjYW4gdmlldyB0aGlzIGRyYWZ0IGF0Og0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktaWRyLXNyLXBvbGljeS1w YXRoLW10dS8NCg0KVGhpcyBkcmFmdCBkaXN0cmlidXRlcyBwYXRoIG1heGltdW0gdHJhbnNtaXNz aW9uIHVuaXQgZm9yIHRoZQ0KU1IgcG9saWN5IHZpYSBCR1AuDQoNCkFueSBkaXNjdXNzaW9uIHJl Z2FyZGluZyBvbiB3aGV0aGVyIG9uZSBkZXNpcmVzDQpTUiBQb2xpY3kgc2hvdWxkIGJlIGNsZWFy bHkgZGlzdGluZ3Vpc2hlZCBmcm9tIHRoZQ0KVGVjaG5pY2FsIGRpc2N1c3Npb25zIG9uIHRoZSBt ZWNoYW5pc21zIHRvIHBhc3MgU1IgcG9saWN5IE1UVS4NCg0KVGhlIHF1ZXN0aW9ucyBmb3IgdGhl IHBlb3BsZSB0byBkaXNjdXNzIG9uIHRoaXMgZHJhZnQgYXJlOg0KDQoxKSBJcyB0aGVyZSBhIG5l ZWQgZm9yIHRoaXMgbWVjaGFuaXNtIGluIG5ldHdvcmtzIHVzaW5nDQogICAgICAgIE1QTFMtU1Ig b3IgU1ItVjYgYW5kIFNSIHBvbGljeT8NCg0KMikgQXJlIHRoZXJlIGFueSBlcnJvciBoYW5kbGlu ZyBpc3N1ZXMgYmVzaWRlcyB3aGF0IGlzIGJlaW5nDQogICAgIFRha2VuIGNhcmUgb2YgaW4gUkZD Nzc1MmJpcy0wMy50eHQNCg0KMykgRG8geW91IHRoaW5rIHRoaXMgZHJhZnQgaXMgcmVhZHkgdG8g YmUgYWRvcHRlZD8NCiAgICAgSW4gdGhpcyBjYXRlZ29yeSwgcGxlYXNlIGxpc3QgYW55IGNvbmNl cm5zIHlvdSBoYXZlDQogICAgIHJlZ2FyZGluZyBhZG9wdGlvbi4gIFRoaXMgY2F0ZWdvcnkgY2Fu IGluY2x1ZGUNCiAgICAgZ2VuZXJhbCBjb25jZXJucyBhYm91dCBCR1AtTFMsIE1QTFMtU1IsDQog ICAgU1ItVjYsIGFuZCBTUi1Qb2xpY3kuDQoNCkNoZWVycywgU3VlIEhhcmVzDQoNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWls aW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== --_000_C7C2E1C43D652C4E9E49FE7517C236CB029ADF67dggeml529mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg 6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoxMzczNTc4ODI0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotOTkxNzcyMzc2IDEwNzQzMzE2NjUgMTA3NDMzMTY3MyAx MDc0MzMxNjc1IDEwNzQzMzE2NjMgMTA3NDMzMTY3MyAxMDc0MzMxNjc1IDEwNzQzMzE2NjMgMTA3 NDMzMTY3MyAxMDc0MzMxNjc1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoi JTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEFpanVuLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+TWFueSB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMsIHBsZWFz ZSBzZWUgbXkgcmVwbHkgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFpanVuIFdhbmcgW21haWx0bzp3 YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuXSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFw cmlsIDksIDIwMjAgMTI6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IENoZW5nbGkgKENoZW5nIExpKSAm bHQ7Y2hlbmdsaTEzQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBLZXRhbiBUYWxhdWxp a2FyIChrZXRhbnQpICZsdDtrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBT dXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OzsgSURSIExpc3QgJmx0O2lkckBpZXRm Lm9yZyZndDs7IFNQUklORyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW0lkcl0gV0cgQWRvcHRpb24gLSBkcmFmdC1saS1pZHItc3ItcG9saWN5LXBh dGgtbXR1LTAzLnR4dCAtIDIgV2VlayBXRyBhZG9wdGlvbiBjYWxsICgzLzMwIC0gNC8xMyk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBDaGVuZzo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYW0gY29uc2lkZXJpbmcgdGhlIGZvbGxvd2luZyBzY2VuYXJpb3M6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVu IHRoZSBzaXplIG9mIHNvbWUgcGFja2V0cyBvZiBvbmUgZmxvdyBhcmUgc21hbGwgYW5kIGRvIG5v dCBleGNlZWQgdGhlIFBNVFUgdmFsdWUsIHRoZXkgYXJlIGVuY2Fwc3VsYXRlZCB1cG9uIHRoZSBj b3JyZXNwb25kaW5nIFNSIHBvbGljeSBhbmQgd2lsbCBiZSB0cmFuc2ZlcnJlZCBhY2NvcmRpbmcg dG8gdGhlIGFwcG9pbnRlZCBwYXRoIGFzIGV4cGVjdGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGhvdyBhYm91dCBvdGhlciBs YXJnZXIgcGFja2V0cyB3aXRoaW4gdGhlIHNhbWUgZmxvdz8gV2lsbCB0aGV5IGJlIGRyb3BwZWQg b3IgdHJhbnNmZXJyZWQgdmlhIG90aGVyIG5vbi1TUiBwYXRoPyBJZiBzbywgd2lsbCB0aGUgU1Ig aW5mbHVlbmNlIHRoZSBmbG934oCZcyBqaXR0ZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPltDaGVuZ10gVGhlIFBUTVUgaXMgdGhlIG1pbmltdW0gdmFsdWUgb2YgdGhlIE1UVSBvZiBM aW5rcyBhbG9uZyB0aGUgcGF0aCBpZGVudGlmaWVkIGJ5IHRoZSBTSUQgbGlzdC4gVGhlcmVmb3Jl LCB0aGUgdmFsdWUgb2YgUE1UVSBkZXNjcmliZXMgdGhlIGxhcmdlc3Qgc2l6ZSBvZiB0aGUgcGFj a2V0IHRvIGJlIHNlbnQgYWxvbmcgdGhlIFNSIHBhdGgsIGluY2x1ZGluZw0KIHRoZSBTUiBvdmVy aGVhZC4gSWYgdGhlIHJlY2VpdmVkIHBhY2tldCBpcyBsYXJnZXIgdGhhbiB0aGUgUE1UVSDigJMg b3ZlcmhlYWQsIGl0IHdpbGwgYmUgZHJvcHBlZCBvciBmcmFnbWVudGVkLiBJdCBpcyBzaW1pbGFy IHRvIFJTVlAtVEUgTVBMUy4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMzIwOSNzZWN0aW9uLTIuNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzMyMDkjc2VjdGlvbi0yLjY8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBNVFUgZm9yIHRoZSBwYXRoIGlzIG9uZSB1c2VmdWwgaW5mb3Jt YXRpb24gYnV0IEkgdGhpbmsgY3VycmVudCBkcmFmdCBoYXMgbm90IGVsYWJvcmF0ZSBob3cgdG8g dXNlIGl0IGluIGRpZmZlcmVudCBzaXR1YXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltDaGVuZ10gV2ls bCBhZGQgdGV4dCB0byBzcGVjaWZ5IGhvdyB0byBoYW5kbGUgdGhlIHZhbHVlIG9uIHRoZSBpbmdy ZXNzIG5vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaXRob3V0IFNSLCB3ZSBjYW4gdGVsbCB0aGUgY3VzdG9tZXIgdGhlIE1U VSBvZiB0aGUgbmV0d29yay4gQnV0IHdpdGggU1IsIHRoZSBuZXR3b3JrIE1UVSB3aWxsIGJlIGNo YW5nZWQgYmFzZWQgb24gdGhlIHBhdGggbGVuZ3RoLiBDb25zaWRlcmluZyB0aGlzLCBtYXliZSB0 aGUgUE1UVSB0aGF0IGRldGVjdGVkIGJ5IHRoZSBob3N0IHdpbGwgYmUgbW9yZSBjb252aW5jaWJs ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5bQ2hlbmddIEhvd2V2ZXIsIHRoZSBob3N0IGNhbiBub3QgZGV0ZWN0IHRoZSBy ZWFsIFBNVFUgb2YgdGhlIG5ldHdvcmssIGJlY2F1c2UgaXQgY2FuIG5vdCBiZSBhd2FyZSBvZiB0 aGUgb3ZlcmhlYWQgb2YgdGhlIFNSIGFuZCBvdGhlcnMsIGl0IHdpbGwgZ2V0IHRoZSBtaW5pbXVt IHZhbHVlIG9mIHRoZSBMaW5rIE1UVSwgYnV0LCB0aGUgcmVhbGx5IFBNVFUgc2hvdWxkDQogYmUg dGhlIFBNVFUg4oCTIE4gKFNSIG92ZXJoZWFkIG9yIG90aGVyIG92ZXJoZWFkKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhvcGUgSSBoYXZlIGFuc3dlcmVkIHlvdXIgcXVl c3Rpb25zLiBUaGFuayB5b3UgYWdhaW4hPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BaWp1biBX YW5nPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hpbmEgVGVs ZWNvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBBcHIgOCwgMjAyMCwgYXQgMTc6MDcs IENoZW5nbGkgKENoZW5nIExpKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoZW5nbGkxM0BodWF3ZWku Y29tIj5jaGVuZ2xpMTNAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7vu78g PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBLZXRhbiw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1hbnkgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz LCBhbmQgc29ycnkgZm9yIG15IGRlbGF5LCBwbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Q2hlbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWRyIFs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPktldGFuIFRhbGF1bGlrYXIgKGtldGFudCk8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBBcHJpbCAzLCAyMDIwIDQ6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzICZs dDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0 OzsgJ0lEUiBMaXN0JyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFNQUklORyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtJZHJdIFdHIEFkb3B0aW9uIC0gZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRo LW10dS0wMy50eHQgLSAyIFdlZWsgV0cgYWRvcHRpb24gY2FsbCAoMy8zMCAtIDQvMTMpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IZWxsbyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5JIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGZvciB0aGUgYXV0aG9ycyBvZiB0 aGlzIGRyYWZ0IGFuZCBzb21lIGRpc2N1c3Npb24gcG9pbnRzIGZvciB0aGUgV0cuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldoYXQgaXMgcHJlY2lzZWx5IHRoZSBkZWZp bml0aW9uIG9mIHRoaXMg4oCccGF0aCBNVFXigJ0gZm9yIGFuIFNSIFBvbGljeT8gSSBhbSBndWVz c2luZyB0aGF0IGl0IGluY2x1ZGVzIGFsbCB0aGUgbGFiZWxzL1NJRHMgdGhhdCBhcmUgdXNlZCBm b3IgdGhlIFNSIHBhdGg/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PltDaGVuZ10gWWVzLCBUaGUgUGF0aCBNVFUgZGVzY3JpYmVzIHRoZSBsYXJnZXN0IHNpemUgb2Yg dGhlIHBhY2tldCwgaW5jbHVkaW5nIHRoZSBvdmVyaGVhZCBvZiBMYWJlbHMvU0lEcy9JUHY2IGhl YWRlci9TUkggYW5kIG90aGVycy4gV2hlbiBlbmNhcHN1bGF0aW5nIGEgcGFja2V0LCB0aGUgbGVu Z3RoIG9mIHRoZQ0KIHBheWxvYWQoaW5uZXIgSVAgcGFja2V0IG9yIHNvbWV0aGluZyBlbHNlKSBz aG91bGQgYmUgbGVzcyB0aGFuIHRoZSBQTVRVIG1pbnVzIHRoZSBvdmVyaGVhZCBvZiBTSUQgTGlz dC9TUkgvIEZSUiBvdmVyaGVhZCBhbmQgQmluZGluZyBTSUQgb3ZlcmhlYWQsIGJ1dCBpdCBpcyBh IGltcGxlbWVudGF0aW9uIGNob2ljZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUlO IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1JTiIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaGlsZQ0KPC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjA5I3NlY3Rpb24tMi42Ij48c3BhbiBs YW5nPSJFTi1JTiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyMDkjc2VjdGlvbi0y LjY8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUlOIj4gZGVmaW5lcyDigJxwYXRoIE1UVeKAnSBm b3IgUlNWUC1URSBMU1BzLCBpdCBkb2VzIGRlc2NyaWJlIHRoZSBwcm9jZWR1cmVzIGZvciB0aGUg c2FtZSBmb3IgaGFuZGxpbmcNCiBJUCBwYWNrZXRzL3BheWxvYWRzIG9uIHRoZSBoZWFkZW5kLiBJ dCBkb2VzIG5vdCBjb3ZlciB0aGUgc2NlbmFyaW9zIHdoZXJlIHRoZSBpbmNvbWluZyBwYWNrZXRz IG1heSBiZSB0aGVtc2VsdmVzIGxhYmVsbGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5bQ2hlbmddV2VsbCwgSSBtYXkgbWlzdW5kZXJzdGFuZCB0aGUgdGV4dCBp bjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj4NCjwvc3Bhbj48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIwOSNzZWN0aW9uLTIuNiI+PHNwYW4g bGFuZz0iRU4tSU4iPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjA5I3NlY3Rpb24t Mi42PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LCBidXQgSSB0aGluayBp dCBjb3ZlcnMgdGhlIHNjZW5hcmlvcyB3aGVyZSB0aGUgaW5jb21pbmcgcGFja2V0cyBtYXkgYmUg dGhlbXNlbHZlcyBsYWJlbGxlZC4NCiBJIG1heSBiZSB3cm9uZy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1JTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyDigJw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dpbmcgYWxnb3JpdGhtIGFwcGxpZXMgdG8gYWxsIHVubGFi ZWxlZCBJUCBkYXRhZ3JhbXMgYW5kIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbnkgbGFiZWxl ZCBwYWNrZXRzIHdoaWNoIHRoZSBub2RlIGtub3dzIHRvIGJlIElQIGRhdGFncmFtcywgdG8gd2hp Y2g8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGxhYmVscyBuZWVkIHRvIGJlIGFkZGVkIGJlZm9yZSBm b3J3YXJkaW5nLiZuYnNwOyBGb3IgbGFiZWxlZCBwYWNrZXRzIHRoZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgYm90dG9tIG9mIHN0YWNrIGlzIGZvdW5kLCB0aGUgSVAgaGVhZGVyIGV4YW1pbmVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO1VzaW5nIHRoZSB0ZXJtaW5vbG9neSBkZWZpbmVkIGlu IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIwOSNyZWYtNSIgdGl0 bGU9IiZxdW90O01QTFMgTGFiZWwgU3RhY2sgRW5jb2RpbmcmcXVvdDsiPjU8L2E+XSwgYW4gTFNS IE1VU1QgZXhlY3V0ZSB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZm9sbG93aW5nIGFsZ29yaXRobTo8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgMS4gTGV0IE4gYmUgdGhlIG51bWJlciBvZiBieXRlcyBpbiB0aGUgbGFiZWwg c3RhY2sgKGkuZSwgNCB0aW1lcyB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbnVt YmVyIG9mIGxhYmVsIHN0YWNrIGVudHJpZXMpIGluY2x1ZGluZyBsYWJlbHMgdG8gYmUgYWRkZWQg Ynk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBub2RlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A74oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gbGFuZz0iRU4tSU4iPlNob3VsZG7igJl0IHRoZSBjb25jZXB0IG9mIOKAnHBhdGggTVRV 4oCdIGZvciBTUiBQb2xpY2llcyBhbmQgaXRz4oCZIGFwcGxpY2FiaWxpdHkgYW5kIG9wZXJhdGlv bnMgYmUgZmlyc3QgZGVmaW5lZCBpbiBhIChTcHJpbmcgV0c/KSBkb2N1bWVudCBiZWZvcmUgd2Ug aW50cm9kdWNlIGl0cyBzaWduYWxsaW5nIGFzcGVjdHMgaW4gcHJvdG9jb2xzIGxpa2UgQkdQPyBO b3RlIHRoYXQgc3VjaA0KIGEgZG9jdW1lbnQgd291bGQgYnJpbmcgaW4gcmVxdWlyZW1lbnRzIGFu ZCBndWlkZWxpbmVzIGZvciBob3cgdGhlIHZhbHVlIGlzIGdvaW5nIHRvIGJlIGNvbXB1dGVkIGFu ZCBpdOKAmXMgdXNhZ2UgZm9yIGRpZmZlcmVudCBzdGVlcmluZyBtZWNoYW5pc21zIG92ZXIgU1Ig UG9saWNpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltDaGVu Z10gVGhpcyBpcyBhIHJlYWxseSBzbWFsbCBidXQgdXNlZnVsIGFuZCBzdHJhaWdodCBmb3J3YXJk IGV4dGVuc2lvbnMsIGl0IG1pZ2h0IG5vdCBuZWVkIHRvIHdyaXRlIGEgZHJhZnQgdG8gZGVzY3Jp YmUgdGhlIHJlcXVpcmVtZW50IGluc3RlYWQgb2YgYWRkaW5nIHRleHQgaW4gdGhlIGN1cnJlbnQg U1IgcG9saWN5DQogYXJjaGl0ZWN0dXJlIGRyYWZ0IG9yIGl0IGN1cnJlbnQgZG9jdW1lbnQuICZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1mYW1pbHk6 5a6L5L2TIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZv bnQtZmFtaWx5OuWui+S9kyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tSU4i IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQpPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLUlOIj5G aW5hbGx5LCBzcGVjaWZpYyB0byB0aGUgcHJvcG9zZWQgZW5jb2RpbmcgaGVyZSwgd291bGQgdGhp cyDigJxwYXRoIE1UVeKAnSBub3QgYmUgbW9yZSBzdWl0YWJsZSBvbiB0aGUgQ1AgbGV2ZWwgc2lu Y2UgZWFjaCBTTCBtYXkgaGF2ZSBkaWZmZXJlbnQgc2l6ZSBsYWJlbCBzdGFjayBhbmQgZGlmZmVy ZW50IHBhdGhzIGFuZCBvbmUgZG9lcyBub3Qga25vdyB3aGljaCBTTCB3b3VsZA0KIGJlIHBpY2tl ZCBmb3IgYSBwYXJ0aWN1bGFyIGZsb3c/IFNvIG1heSBiZSB0aGUgbG93ZXN0IHZhbHVlIGNvbXB1 dGVkIGZvciBhbGwgU0xzIGlzIHdoYXQgZ2V0cyBhcHBsaWVkIHRvIHRoZSBwYWNrZXRzIGF0IHRo ZSBDUCAoaS5lLiBTUiBQb2xpY3kpIGxldmVsPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5bQ2hlbmddIFlvdSBhcmUgY29ycmVjdC4gVGhlIFBNVFUgaXMgZGVmaW5l ZCBmb3IgU0lEIExpc3QuIFdoZW4gd2UgdGFsayBhYm91dCBQYXRoIE1UVSBmb3IgU1IgcG9saWN5 LCBpdCBDQU4gYmUgdGhlIGxvd2VzdCB2YWx1ZSBvZiB0aGUgUE1UVSBvZiBTSUQgbGlzdHMuIEJ1 dCBkbyB3ZSBuZWVkIHRoaXMgdmFsdWU/DQogSWYgd2UgbmVlZCwgdGhlbiB0aGUgbm9kZSBjYW4g Y29tcHV0ZSBpdCBiYXNlZCBvbiBQTVRVcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+S2V0YW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBJZHIgJmx0OzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9y ZyI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdXNh biBIYXJlczxicj4NCjxiPlNlbnQ6PC9iPiAzMCBNYXJjaCAyMDIwIDE4OjA2PGJyPg0KPGI+VG86 PC9iPiAnSURSIExpc3QnICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbSWRyXSBXRyBBZG9wdGlvbiAtIGRy YWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1tdHUtMDMudHh0IC0gMiBXZWVrIFdHIGFkb3B0aW9u IGNhbGwgKDMvMzAgLSA0LzEzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBhZG9w dGlvbiBjYWxsIGZvciBkcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1LTAzLnR4dA0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjYW4gdmlldyB0aGlzIGRyYWZ0IGF0OiA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1tdHUvIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1 LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBkaXN0cmlidXRlcyBwYXRo IG1heGltdW0gdHJhbnNtaXNzaW9uIHVuaXQgZm9yIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TUiBwb2xpY3kgdmlhIEJHUC4mbmJzcDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFueSBkaXNjdXNzaW9uIHJlZ2FyZGluZyBvbiB3aGV0aGVyIG9uZSBkZXNpcmVz IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U1IgUG9saWN5IHNob3VsZCBi ZSBjbGVhcmx5IGRpc3Rpbmd1aXNoZWQgZnJvbSB0aGUgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UZWNobmljYWwgZGlzY3Vzc2lvbnMgb24gdGhlIG1lY2hhbmlzbXMgdG8g cGFzcyBTUiBwb2xpY3kgTVRVLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVzdGlv bnMgZm9yIHRoZSBwZW9wbGUgdG8gZGlzY3VzcyBvbiB0aGlzIGRyYWZ0IGFyZTogPG86cD4NCjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MSkgSXMgdGhlcmUgYSBuZWVkIGZvciB0aGlzIG1lY2hhbmlzbSBp biBuZXR3b3JrcyB1c2luZyA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TVBMUy1TUiBv ciBTUi1WNiBhbmQgU1IgcG9saWN5PyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgQXJlIHRo ZXJlIGFueSBlcnJvciBoYW5kbGluZyBpc3N1ZXMgYmVzaWRlcyB3aGF0IGlzIGJlaW5nDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1Rha2VuIGNhcmUgb2YgaW4gUkZDNzc1MmJpcy0wMy50eHQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MykgRG8geW91IHRoaW5rIHRoaXMgZHJhZnQgaXMgcmVhZHkgdG8gYmUgYWRvcHRl ZD8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtJbiB0aGlzIGNhdGVnb3J5LCBwbGVhc2UgbGlzdCBhbnkgY29uY2VybnMg eW91IGhhdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyByZWdhcmRpbmcgYWRvcHRpb24uJm5ic3A7IFRoaXMgY2F0ZWdvcnkgY2Fu IGluY2x1ZGUgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtnZW5lcmFsIGNvbmNlcm5zIGFib3V0IEJHUC1MUywgTVBMUy1T UiwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtTUi1WNiwgYW5kIFNSLVBvbGljeS4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNoZWVycywgU3VlIEhhcmVzICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CB029ADF67dggeml529mbxchi_-- From nobody Thu Apr 9 03:57:45 2020 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 525073A078C; Thu, 9 Apr 2020 03:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InKIBMU111l9; Thu, 9 Apr 2020 03:57:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E743A0788; Thu, 9 Apr 2020 03:57:32 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 437806D51A448E103686; Thu, 9 Apr 2020 11:57:29 +0100 (IST) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 9 Apr 2020 11:57:28 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.59]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Thu, 9 Apr 2020 18:57:17 +0800 From: "Chengli (Cheng Li)" To: "Ketan Talaulikar (ketant)" , Susan Hares , 'IDR List' CC: SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aAABGXt8AAr5fhg Date: Thu, 9 Apr 2020 10:57:16 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029AE2ADdggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 10:57:35 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB029AE2ADdggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thanks for your reply, please see my reply inline. Cheng From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Wednesday, April 8, 2020 7:37 PM To: Chengli (Cheng Li) ; Susan Hares ; 'IDR List' Cc: SPRING WG Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Cheng, Please check inline below. From: Chengli (Cheng Li) = > Sent: 08 April 2020 14:36 To: Ketan Talaulikar (ketant) >; = Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Many thanks for your comments, and sorry for my delay, please see my reply = inline. Thanks, Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (keta= nt) Sent: Friday, April 3, 2020 4:18 PM To: Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hello, I have a few questions for the authors of this draft and some discussion po= ints for the WG. 1) What is precisely the definition of this "path MTU" for an SR Polic= y? I am guessing that it includes all the labels/SIDs that are used for the= SR path? [Cheng] Yes, The Path MTU describes the largest size of the packet, includi= ng the overhead of Labels/SIDs/IPv6 header/SRH and others. [KT] Here, "path" is the SR path and the SR path is specified by a label st= ack. So the "payload" over the SR path does not include the SID List use to= construct the path itself, right? Or do you mean that the "path MTU" is th= e lowest MTU value of all paths over which packet steered over the SR Polic= y may go over? [Cheng] The path here is the SR path specified by a SID list. The PMTU is = the lowest MTU value of the MTU of the Links along the path identified by t= he SID list. It is the largest size of the packet to be sent along the SR p= ath (SID List), so it can include the payload, overhead of SR, FRR and may = be Binding SID (an Binding SID will introduce a new IPv6 encapsulation or a= new SRH). When encapsulating a packet, the length of the payload(inner IP packet or s= omething else) should be less than the PMTU minus the overhead of SID List/= SRH/ FRR overhead and Binding SID overhead, but it is a implementation choi= ce. [KT] Here a "path MTU" object is being defined. It is to be calculated by a= component X and communicated over BGP protocol to a node/component Y. IMHO= we cannot leave such things to implementation aspects - this attribute sho= uld be clearly specified so that both X and Y have the same understanding o= f what it means and how it is to be used. [Cheng] Well, as I mention above, this value is the largest value of the MT= U of links along the path. This value can be calculated very precisely. How= ever, when we encapsulate the packet, how long the payload can be, it depe= nds on the implementation. For example, device A can encapsulate M byte, and M =3D P= MTU - A(overhead of SR) - B (FRR overhead), and the FRR overhead may be 40= Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on t= he policy. But you may be right, we can calculate the TRUE PMTU on X = (Controller, etc.) , and send it to the device, and the device will use it = as the longest length of the Payload, that will be fine. We can discuss abo= ut this. 2) While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path= MTU" for RSVP-TE LSPs, it does describe the procedures for the same for ha= ndling IP packets/payloads on the headend. It does not cover the scenarios = where the incoming packets may be themselves labelled. [Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rf= c3209#section-2.6, but I think it covers the scenarios where the incoming p= ackets may be themselves labelled. I may be wrong. " The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined. Using the terminology defined in [5], an LSR MUST execute the following algorithm: 1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node. " [KT] May be I misunderstood your proposal then. It seems that the authors w= ant the headend to perform the behavior described in RFC3209 Sec 2.6 for SR= Policies, then please specify the same with normative language. How would = this work for SRv6? This way the WG can review and understand what the prop= osal is. Note that we can also have a label stack introduced during transit= due to something like TI-LFA. [Cheng] Yes, that is what I mentioned above, some overhead will be introduc= ed like FRR/TI-LFA. Will add the text to specify how to do it in SRv6. 3) Shouldn't the concept of "path MTU" for SR Policies and its' applic= ability and operations be first defined in a (Spring WG?) document before w= e introduce its signalling aspects in protocols like BGP? Note that such a = document would bring in requirements and guidelines for how the value is go= ing to be computed and it's usage for different steering mechanisms over SR= Policies. [Cheng] This is a really small but useful and straight forward extensions, = it might not need to write a draft to describe the requirement instead of a= dding text in the current SR policy architecture draft or it current docume= nt. [KT] It is not about the size of the document, but the clear and normative = specification of behaviors being introduced - both for the node calculating= this value and for the headend for how it is supposed to handle this. My w= orry is that there is devil in the details here and operational aspects on = how exactly this will work. I am not against this work. I only ask the auth= ors to document the behaviors associated with this in a Spring WG document = so the WG can review all that is entailed by the proposal. It is somewhat s= imilar to how Path Segment was introduced - I would suggest to start with a= fresh draft using much of the content from this BGP document plus other cl= arifications as discussed in this email thread. Once the "Path MTU" for SR Policy is properly specified, the BGP SRTE encod= ing is actually trivial by simply referring to its base draft. The same may= be also specified via PCEP or a Yang model. [Cheng] Agree with your proposal. We should specify the be= havior clearer. The question is that do we need to write a new draft in SPR= ING to describe it ? or describe it in the BGP draft directly? Or add text = in the existing SR policy architecture draft? We can discuss this. But for = sure, will add text to specify this part. 4) Finally, specific to the proposed encoding here, would this "path M= TU" not be more suitable on the CP level since each SL may have different s= ize label stack and different paths and one does not know which SL would be= picked for a particular flow? So may be the lowest value computed for all = SLs is what gets applied to the packets at the CP (i.e. SR Policy) level? [Cheng] You are correct. The PMTU is defined for SID List. When we talk abo= ut Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID li= sts. But do we need this value? If we need, then the node can compute it ba= sed on PMTUs. [KT] Sure. I think these are details and we can leave them aside for now. M= y main concerns are the previous comments. Thanks, Ketan Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 30 March 2020 18:06 To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_C7C2E1C43D652C4E9E49FE7517C236CB029AE2ADdggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

 

Thanks for your reply,= please see my reply inline.

 

Cheng

 

 

 

From: Ketan Talaulikar (ketant) [mailto:ketan= t@cisco.com]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) <chengli13@huawei.com>; Susan Hares <= ;shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Cheng,

 

Please check inline below.

 

From: Chengli (Cheng Li) <chengli13@huawei.com>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Ketan,

 

Many thanks for your c= omments, and sorry for my delay, please see my reply inline.

 

Thanks,

Cheng

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.c= om>; 'IDR List' <idr@ietf.org= >
Cc: SPRING WG <spring@ietf.org= >
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hello,

 

I have a few questions for the authors of this draft and some discuss= ion points for the WG.

 

1)      What is precisely the definition of this “path MTU̶= 1; for an SR Policy? I am guessing that it includes all the labels/SIDs tha= t are used for the SR path?

[Cheng] Yes, The Path MTU describes the largest size of the packet, = including the overhead of Labels/SIDs/IPv6 header/SRH and others.

[KT] Here, “path” is the SR path a= nd the SR path is specified by a label stack. So the “payload” = over the SR path does not include the SID List use to construct the path it= self, right? Or do you mean that the “path MTU” is the lowest MTU value of all paths over which packet steered over the SR Policy may go= over?

 

[Cheng] The path here = is the SR path specified by a SID list.  The PMTU is the lowest MTU value of t= he MTU of the Links along the path identified by the SID l= ist. It is the largest size of the packet to be sent along the SR path (SID= List), so it can include the payload, overhead of SR, FRR and may be Bindi= ng SID (an Binding SID will introduce a new IPv6 encapsulation or a new SRH).

 

When encapsulating a packet, the length of the payload(inner IP pack= et or something else) should be less than the PMTU minus the overhead of SI= D List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation choice.

[KT] Here a “path MTU” object is being defined. It = is to be calculated by a component X and communicated over BGP protocol to = a node/component Y. IMHO we cannot leave such things to implementation aspects – this attribute should be clearly specifi= ed so that both X and Y have the same understanding of what it means and ho= w it is to be used.

 

[Cheng]= Well, as I mention above, this value is the largest value of the MTU of li= nks along the path. This value can be calculated very precisely. However, w= hen we encapsulate the packet, how long  the payload can be, it depends on the implementation.

 &= nbsp;           &nbs= p;   For example, device A can encapsulate M byte, and M =3D=   PMTU –  A(overhead of SR) – B (FRR overhead), and t= he FRR overhead may be 40 Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on the policy. 

 &= nbsp;           &nbs= p;   

 &= nbsp;           &nbs= p;   But you may be right, we can calculate the TRUE PMTU on= X (Controller, etc.) , and send it to the device, and the device will use = it as the longest length of the Payload, that will be fine. We can discuss about this.

 

 

 

2)      While https://tools.ietf.org/html/rfc3209#section-2.6 defines “path MTU” for RSVP-TE LSPs, it does = describe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where = the incoming packets may be themselves labelled.

[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the scenarios where the i= ncoming packets may be themselves labelled. I may be wrong.

 

   “

   The following algorithm applies t= o all unlabeled IP datagrams and to

   any labeled packets which the nod= e knows to be IP datagrams, to which

   labels need to be added before fo= rwarding.  For labeled packets the

   bottom of stack is found, the IP = header examined.

 

   Using the terminology defined in [5], an LSR MUST execute the

   following algorithm:


 


   1. Let N be the number of bytes in the label stack =
(i.e, 4 times the


      number of label stack entries) in=
cluding labels to be added by


      this node.

       “


[KT] May be I misunderstood your proposal then=
. It seems that the authors want the headend to perform the behavior descri=
bed in RFC3209 Sec 2.6 for SR Policies, then please specify the same with n=
ormative language. How would this
 work for SRv6? This way the WG can review and understand what the proposal=
 is. Note that we can also have a label stack introduced during transit due=
 to something like TI-LFA.


 


[Cheng] Yes, that is w=
hat I mentioned above, some overhead will be introduced like FRR/TI-LFA.&nb=
sp; Will add the text to specify how to do it in SRv6.



 


 



3)     
Shouldn’t the con=
cept of “path MTU” for SR Policies and its’ applicability=
 and operations be first defined in a (Spring WG?) document before we intro=
duce its signalling aspects in protocols like BGP? Note that
 such a document would bring in requirements and guidelines for how the val=
ue is going to be computed and it’s usage for different steering mech=
anisms over SR Policies.


[Cheng] This is a really small but useful and straight forward exten=
sions, it might not need to write a draft to describe the requirement inste=
ad of adding text in the current SR policy
 architecture draft or it current document.  


[KT] It is not about the size of the document,=
 but the clear and normative specification of behaviors being introduced &#=
8211; both for the node calculating this value and for the headend for how =
it is supposed to handle this. My worry
 is that there is devil in the details here and operational aspects on how =
exactly this will work. I am not against this work. I only ask the authors =
to document the behaviors associated with this in a Spring WG document so t=
he WG can review all that is entailed
 by the proposal. It is somewhat similar to how Path Segment was introduced=
 – I would suggest to start with a fresh draft using much of the cont=
ent from this BGP document plus other clarifications as discussed in this e=
mail thread.


 


Once the “Path MTU” for SR Policy =
is properly specified, the BGP SRTE encoding is actually trivial by simply =
referring to its base draft. The same may be also specified via PCEP or a Y=
ang model.


 


 &=
nbsp;           &nbs=
p;   [Cheng] Agree with your proposal. We should specify the beha=
vior clearer. The question is that do we need to write a new draft in SPRIN=
G to describe it ? or describe it in the BGP
 draft directly? Or add text in the existing SR policy architecture draft? =
We can discuss this. But for sure, will add text to specify this part.=



&n=
bsp;


 



4)     
Finally, specific to th=
e proposed encoding here, would this “path MTU” not be more sui=
table on the CP level since each SL may have different size label stack and=
 different paths and one does not know which SL
 would be picked for a particular flow? So may be the lowest value computed=
 for all SLs is what gets applied to the packets at the CP (i.e. SR Policy)=
 level?


[Cheng] You are correct. The PMTU is defined for SID List. When we t=
alk about Path MTU for SR policy, it CAN be the lowest value of the PMTU of=
 SID lists. But do we need this value?
 If we need, then the node can compute it based on PMTUs.=



[KT] Sure. I think these are details and we ca=
n leave them aside for now. My main concerns are the previous comments.


 


Thanks,


Ketan<=
/span>


 


Thanks,


Ketan


 


 






From: Idr <idr-bounces@ietf.org>
On Behalf Of Susan Hares

Sent: 30 March 2020 18:06

To: 'IDR List' <idr@ietf.org&=
gt;

Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt =
- 2 Week WG adoption call (3/30 - 4/13)






 


This begins a 2 week WG adoption call for draft-li-i=
dr-sr-policy-path-mtu-03.txt



 


You can view this draft at: 


https://datatracker.ietf.org/doc/draft-li-idr-sr-=
policy-path-mtu/


 


This draft distributes path maximum transmission uni=
t for the



SR policy via BGP.  


 


Any discussion regarding on whether one desires 


SR Policy should be clearly distinguished from the <=
o:p>


Technical discussions on the mechanisms to pass SR p=
olicy MTU.



 


The questions for the people to discuss on this draf=
t are: 



 


1) Is there a need for this mechanism in networks us=
ing 



        MPLS=
-SR or SR-V6 and SR policy? 


 


2) Are there any error handling issues besides what =
is being



     Taken care of in RFC77=
52bis-03.txt


 


3) Do you think this draft is ready to be adopted? <=
o:p>


     In this category, plea=
se list any concerns you have


     regarding adoption.  T=
his category can include 


     general concerns about=
 BGP-LS, MPLS-SR, 


    SR-V6, and SR-Policy.  =
 


 


Cheers, Sue Hares  


 


 


 


 


 
--_000_C7C2E1C43D652C4E9E49FE7517C236CB029AE2ADdggeml529mbxchi_-- From nobody Thu Apr 9 04:33:28 2020 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 5B7A03A0895; Thu, 9 Apr 2020 04:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=WbfpePlG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bSI7A0PT 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 9n1-vxERdW7D; Thu, 9 Apr 2020 04:33:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBAB3A088F; Thu, 9 Apr 2020 04:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42982; q=dns/txt; s=iport; t=1586431999; x=1587641599; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T0LNlmMV8ZRz46KO0a5wQmqugCJYwvHVNKcxLFVlZFM=; b=WbfpePlGvOni+HHCn0clRlFUDIwsMhtS7KksDkXPL9epBc2fjUmUqZ47 SNhcSWBYB1ytg1dwku5a0C3UMPOwKXFqkPeld/uuH6H2uzOGOEtuI9VB0 dzVqxMargkWY6H3+VFQD1lz3OOp5iIqH13kAjX6qmf/NaAcPBRw6VJRVg c=; IronPort-PHdr: =?us-ascii?q?9a23=3ArtPhvB2FTWm0QydnsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQCkDnJfj2Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAACCB49e/5NdJa1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBaQQBAQELAYEkLyQsBWxYIAQLKgqHWAOKa4JfgQGXH4E?= =?us-ascii?q?uFIEQA1QKAQEBDAEBIwoCBAEBhEQCgg0kNgcOAgMBAQsBAQUBAQECAQUEbYV?= =?us-ascii?q?WDIVwAQEBAQMSCxATAQE3AQ8CAQgRAQMBASEBAgQHMhQDBggBAQQBDQUIGoM?= =?us-ascii?q?FgX5NAy4BDqUOAoE5iGKCJ4J/AQEFgUZBg0YYgg4DBoE4AYUiDYcDGoFBP4E?= =?us-ascii?q?QAUOCGDU+gmcBAQIBAYEsAQwGASMkBwmDDoIsjgAODYh7ikGOcHsKgj+HB3G?= =?us-ascii?q?PYYJQiEGPFYFwhGCKZokrkD+CTQIEAgQFAg4BAQWBWQgqZ3BwFTuCaVAYDZE?= =?us-ascii?q?iCQMXFYM7hRSFQXQCgSeLW4E0AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,362,1580774400"; d="scan'208,217";a="755213886" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2020 11:32:44 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 039BWgQj002205 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Apr 2020 11:32:42 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 06:32:42 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 07:32:41 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 9 Apr 2020 06:32:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XIL507rqDmYJBsd21Dj6AEf3e5TE7uqeQfyqLJxq2l63o42ngIncfAT6xUqh+c9wbyBpgdWXeey8riR99MH4BFOmb+1C+L3JjD9Bw/mHRapECKehLTDtfh0qsXtaGdM6HegbyJ8dqq7w7lThiHjDsGqWitjwkzinD44GPdFHe1b3ZMWIjD5LNjNQC8AxLCfv4OcZ88nEM/i5FhchvSWpV0ZVq17+VPz9i2L+DvR4p9Wr/FpNYUeYnj2DSkI02qhH2q1DsgdTQMHd/VCe/4kjw95LBiv7hJgIQwbG87wn9q8udIUIual0Fbkx2d+QQpIZdSPqYyM7EzhGAmbgNygyxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GsbcyeLHiD2e8fDEmC9BE4mApN6sAhyOR7IiRDSkf84=; b=CkkgGYQLMZAEW53ahdJWQvycDXvYuQO2b0xo3ZUt1Xig/Lwrn8NFqeSbT1Q2UWYXzpETi0XsOZmTiG3SluXIDN3oQR55LX8+xejTZLo7xHYkHqIgiGib4lu/shXyyE2fwwKYSFw23pwX5p6paXg13PAlIjWQJGODB2FCIE4llRjARhxFHiKVUycd+KfXDnzswRuVwsFmv1uDMLPRXgczgcgl3/GOhYSJublFEJ1OI7xSifeeRhD0/xnPXg0/raiLTED5QBfbau8CTFuy2e5kfiMnka3INEnWwFsnjTss7W2IQn6EzC6V4eR/Pq0fHgZZTqyRDHffbu0/t4yp2x+ZkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GsbcyeLHiD2e8fDEmC9BE4mApN6sAhyOR7IiRDSkf84=; b=bSI7A0PTQvyEKWiJkR8Iq+7ZDhNRAZH9i6tJTNGpflouYrxPP9GPLdXwW6FdTATdb95Be8920AgsaUvyv6/YzL0EOSysyaaXVhIOdhYvrplrXy7cVim1Gq1RRHQTu0lobWiFbsTxBEQnHPru8AbeDsrM2Ssu+V5KUJfVxEsXZxk= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4699.namprd11.prod.outlook.com (2603:10b6:303:54::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Thu, 9 Apr 2020 11:32:40 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::dc3d:f0de:21ec:cf87]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::dc3d:f0de:21ec:cf87%7]) with mapi id 15.20.2878.022; Thu, 9 Apr 2020 11:32:40 +0000 From: "Ketan Talaulikar (ketant)" To: "Chengli (Cheng Li)" , Susan Hares , "'IDR List'" CC: SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aAABGXt8AAr5fhgAAcgLvA= Date: Thu, 9 Apr 2020 11:32:40 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [72.163.220.21] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1fce8624-5035-4b04-8e9a-08d7dc79b66e x-ms-traffictypediagnostic: MW3PR11MB4699: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(366004)(346002)(478600001)(8936002)(66476007)(186003)(64756008)(26005)(81156014)(76116006)(9686003)(7696005)(66556008)(316002)(9326002)(6506007)(8676002)(110136005)(55016002)(2906002)(66446008)(66946007)(4326008)(5660300002)(53546011)(52536014)(966005)(33656002)(81166007)(86362001)(71200400001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sFGd27oeggCYIS5cscMr9tY2NCvTjcn3W91ZeS9oRacBfskpssSLhgB9BJuc3b8VWmHsqXH4sj0Lmt388DSeHe3XdGWgVpWvctz8XdSo+0imKsYmDq8t6RBVpL+RIHe5dsvPbot3CibcCxXz6YX8OtbPSDtr08y3PmTynfQKa5m2VNm2RPO1zdQBUaAhbDKq+0r55pW+y0pOqOz4q7JmC7Aes4Lh+gZR++2WWepVQcQ4z1vE6g6yXp0Pp3sUN7tXYLktHQbv9fdEE2RK5Mrr2aNnt2IpkzF08UelKdWbvfwxYU0Hu2jIUUS0viypJnbXxHbIm7M7j2D0PxaNuvtMH/V1EJlvi7i7p/By+CLKa3G6CoFF0rWb0fKHjj9StJRImTZqgOhR7XbWWBlpsiwt3DvuVYd7L1QNA+gYjbss++l7a/ShTQ5Dleo7ma2p9Hp3P5fM+Iyt5TVoMju7yJoStuXcpK+f/8z0AekdE3URV3RQ0hw//NnxmjF5N0GXvwOE0+1Ox3gt1Z3zEqTmxjE7yA== x-ms-exchange-antispam-messagedata: ZbgrtVI/jtt9dIYa/+fcutuvMMIz9yyDXJ8Xr0eFVyQifrrTkWke6zwcEG7Wcw9zeiSn/HOxNgeehklL+XRJAoSfsCqygJvkphBMWkIDha1o9L7lxGj6mgAw4vDNEs9vP5iLSB2+mrXjRQIB2ibv6Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570379D753DF2BB47696219C1C10MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1fce8624-5035-4b04-8e9a-08d7dc79b66e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 11:32:40.5330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VoFRxnDmLxrLDgJ+pYCdJt0wqgZlajjY8xUTsjvOxxEIhm/ePIpm2nznG6m5da1ZfOFDmmEec0I+Ee37RF75RQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4699 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 11:33:23 -0000 --_000_MW3PR11MB4570379D753DF2BB47696219C1C10MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Cheng, Thanks for your responses and clarifications. They help get a better unders= tanding for what exactly the authors wish to specify for "Path MTU" for SR = Policy. Will look forward to normative text with description of computation= and behaviours expected from both the entity computing this Path MTU value= and it's handling on the headend. I would request description text in the = draft instead of a normative reference to RFC3209. That said, I still don't believe this belongs to an IDR document. The draft= -li-idr-sr-policy-path-mtu should limit itself to the BGP encodings. I woul= d suggest to move the specification of SR Policy Path MTU into a new draft = positioned in the Spring WG. That IMHO would be the right way to progress t= his work. Thanks, Ketan From: Chengli (Cheng Li) Sent: 09 April 2020 16:27 To: Ketan Talaulikar (ketant) ; Susan Hares ; 'IDR List' Cc: SPRING WG Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Thanks for your reply, please see my reply inline. Cheng From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Wednesday, April 8, 2020 7:37 PM To: Chengli (Cheng Li) >;= Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Cheng, Please check inline below. From: Chengli (Cheng Li) = > Sent: 08 April 2020 14:36 To: Ketan Talaulikar (ketant) >; = Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Many thanks for your comments, and sorry for my delay, please see my reply = inline. Thanks, Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (keta= nt) Sent: Friday, April 3, 2020 4:18 PM To: Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hello, I have a few questions for the authors of this draft and some discussion po= ints for the WG. 1. What is precisely the definition of this "path MTU" for an SR Policy?= I am guessing that it includes all the labels/SIDs that are used for the S= R path? [Cheng] Yes, The Path MTU describes the largest size of the packet, includi= ng the overhead of Labels/SIDs/IPv6 header/SRH and others. [KT] Here, "path" is the SR path and the SR path is specified by a label st= ack. So the "payload" over the SR path does not include the SID List use to= construct the path itself, right? Or do you mean that the "path MTU" is th= e lowest MTU value of all paths over which packet steered over the SR Polic= y may go over? [Cheng] The path here is the SR path specified by a SID list. The PMTU is = the lowest MTU value of the MTU of the Links along the path identified by t= he SID list. It is the largest size of the packet to be sent along the SR p= ath (SID List), so it can include the payload, overhead of SR, FRR and may = be Binding SID (an Binding SID will introduce a new IPv6 encapsulation or a= new SRH). When encapsulating a packet, the length of the payload(inner IP packet or s= omething else) should be less than the PMTU minus the overhead of SID List/= SRH/ FRR overhead and Binding SID overhead, but it is a implementation choi= ce. [KT] Here a "path MTU" object is being defined. It is to be calculated by a= component X and communicated over BGP protocol to a node/component Y. IMHO= we cannot leave such things to implementation aspects - this attribute sho= uld be clearly specified so that both X and Y have the same understanding o= f what it means and how it is to be used. [Cheng] Well, as I mention above, this value is the largest value of the MT= U of links along the path. This value can be calculated very precisely. How= ever, when we encapsulate the packet, how long the payload can be, it depe= nds on the implementation. For example, device A can encapsulate M byte, and M =3D P= MTU - A(overhead of SR) - B (FRR overhead), and the FRR overhead may be 40= Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on t= he policy. But you may be right, we can calculate the TRUE PMTU on X = (Controller, etc.) , and send it to the device, and the device will use it = as the longest length of the Payload, that will be fine. We can discuss abo= ut this. 1. While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path M= TU" for RSVP-TE LSPs, it does describe the procedures for the same for hand= ling IP packets/payloads on the headend. It does not cover the scenarios wh= ere the incoming packets may be themselves labelled. [Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rf= c3209#section-2.6, but I think it covers the scenarios where the incoming p= ackets may be themselves labelled. I may be wrong. " The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined. Using the terminology defined in [5], an LSR MUST execute the following algorithm: 1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node. " [KT] May be I misunderstood your proposal then. It seems that the authors w= ant the headend to perform the behavior described in RFC3209 Sec 2.6 for SR= Policies, then please specify the same with normative language. How would = this work for SRv6? This way the WG can review and understand what the prop= osal is. Note that we can also have a label stack introduced during transit= due to something like TI-LFA. [Cheng] Yes, that is what I mentioned above, some overhead will be introduc= ed like FRR/TI-LFA. Will add the text to specify how to do it in SRv6. 1. Shouldn't the concept of "path MTU" for SR Policies and its' applicab= ility and operations be first defined in a (Spring WG?) document before we = introduce its signalling aspects in protocols like BGP? Note that such a do= cument would bring in requirements and guidelines for how the value is goin= g to be computed and it's usage for different steering mechanisms over SR P= olicies. [Cheng] This is a really small but useful and straight forward extensions, = it might not need to write a draft to describe the requirement instead of a= dding text in the current SR policy architecture draft or it current docume= nt. [KT] It is not about the size of the document, but the clear and normative = specification of behaviors being introduced - both for the node calculating= this value and for the headend for how it is supposed to handle this. My w= orry is that there is devil in the details here and operational aspects on = how exactly this will work. I am not against this work. I only ask the auth= ors to document the behaviors associated with this in a Spring WG document = so the WG can review all that is entailed by the proposal. It is somewhat s= imilar to how Path Segment was introduced - I would suggest to start with a= fresh draft using much of the content from this BGP document plus other cl= arifications as discussed in this email thread. Once the "Path MTU" for SR Policy is properly specified, the BGP SRTE encod= ing is actually trivial by simply referring to its base draft. The same may= be also specified via PCEP or a Yang model. [Cheng] Agree with your proposal. We should specify the be= havior clearer. The question is that do we need to write a new draft in SPR= ING to describe it ? or describe it in the BGP draft directly? Or add text = in the existing SR policy architecture draft? We can discuss this. But for = sure, will add text to specify this part. 1. Finally, specific to the proposed encoding here, would this "path MTU= " not be more suitable on the CP level since each SL may have different siz= e label stack and different paths and one does not know which SL would be p= icked for a particular flow? So may be the lowest value computed for all SL= s is what gets applied to the packets at the CP (i.e. SR Policy) level? [Cheng] You are correct. The PMTU is defined for SID List. When we talk abo= ut Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID li= sts. But do we need this value? If we need, then the node can compute it ba= sed on PMTUs. [KT] Sure. I think these are details and we can leave them aside for now. M= y main concerns are the previous comments. Thanks, Ketan Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 30 March 2020 18:06 To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_MW3PR11MB4570379D753DF2BB47696219C1C10MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Cheng,=

&nbs= p;

Thanks fo= r your responses and clarifications. They help get a better understanding f= or what exactly the authors wish to specify for “Path MTU” for = SR Policy. Will look forward to normative text with description of computation and behaviours expected from both the entity co= mputing this Path MTU value and it’s handling on the headend. I would= request description text in the draft instead of a normative reference to = RFC3209.

&nbs= p;

That said= , I still don’t believe this belongs to an IDR document. The draft-li= -idr-sr-policy-path-mtu should limit itself to the BGP encodings. I would s= uggest to move the specification of SR Policy Path MTU into a new draft positioned in the Spring WG. That IMHO would be = the right way to progress this work.

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: Chengli (Cheng Li) <chengli13@huawei.com>
Sent: 09 April 2020 16:27
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares = <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Keta= n,

&n= bsp;

Thanks = for your reply, please see my reply inline.

&n= bsp;

Cheng

&n= bsp;

&n= bsp;

&n= bsp;

From: Ketan Talaulikar (ketant) [= mailto:ketant@cisco.com]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) <c= hengli13@huawei.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Cheng,=

&nbs= p;

Please ch= eck inline below.

&nbs= p;

From: Chengli (Cheng Li) <= chengli13@huawei.com>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Keta= n,

&n= bsp;

Many th= anks for your comments, and sorry for my delay, please see my reply inline.=

&n= bsp;

Thanks,=

Cheng

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.c= om>; 'IDR List' <idr@ietf.org= >
Cc: SPRING WG <spring@ietf.org= >
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hello,

&nbs= p;

I have a = few questions for the authors of this draft and some discussion points for = the WG.

&nbs= p;

  1. What is precisely the definition of this “p= ath MTU” for an SR Policy? I am guessing that it includes all the lab= els/SIDs that are used for the SR path?

[Cheng] Yes, The Path MTU describes the largest size = of the packet, including the overhead of Labels/SIDs/IPv6 header/SRH and ot= hers.

[KT] Here, “path= 221; is the SR path and the SR path is specified by a label stack. So the &= #8220;payload” over the SR path does not include the SID List use to = construct the path itself, right? Or do you mean that the “path MTU” is the lowest MTU value of all paths over which packet steered = over the SR Policy may go over?

&n= bsp;

[Cheng]= The path here is the SR path specified by a SID list.  The PMTU is the lowest MTU value of t= he MTU of the Links along the path identified by the SID list. It is the la= rgest size of the packet to be sent along the SR path (SID List), so it can= include the payload, overhead of SR, FRR and may be Binding SID (an Binding SID will introduce a new IPv6 encap= sulation or a new SRH).

<= o:p> 

When encapsulating a packet, the length of the payloa= d(inner IP packet or something else) should be less than the PMTU minus the= overhead of SID List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation choice.

[KT= ] Here a “path MTU” object is being defined. It is to be calcul= ated by a component X and communicated over BGP protocol to a node/componen= t Y. IMHO we cannot leave such things to implementation aspects – this attribute should be clearly specified so that both X = and Y have the same understanding of what it means and how it is to be used= .

 

[Cheng] Well, as I men= tion above, this value is the largest value of the MTU of links along the p= ath. This value can be calculated very precisely. However, when we encapsul= ate the packet, how long  the payload can be, it depends on the implementation.

   &nbs= p;            &= nbsp;For example, device A can encapsulate M byte, and M =3D  PMTU = 211;  A(overhead of SR) – B (FRR overhead), and the FRR overhead= may be 40 Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on the policy. 

   &nbs= p;            &= nbsp;

   &nbs= p;            &= nbsp;But you may be right, we can calculate the TRUE PMTU on X (Controller,= etc.) , and send it to the device, and the device will use it as the longe= st length of the Payload, that will be fine. We can discuss about this.

 

 

 

  1. While https://tools.ietf.org/html/rfc3209#secti= on-2.6 defines “path MTU” for RSVP-TE LSPs, i= t does describe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where = the incoming packets may be themselves labelled.

[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#secti= on-2.6, but I think it covers the = scenarios where the incoming packets may be themselves labelled. I may be wrong.

 

   “=

   The following algo= rithm applies to all unlabeled IP datagrams and to

   any labeled packet= s which the node knows to be IP datagrams, to which

   labels need to be = added before forwarding.  For labeled packets the

   bottom of stack is= found, the IP header examined.

 

   Using the terminology defined in [5], an LSR MUST execute the
   following algorithm:
 
   1. Let N be the number of bytes in t=
he label stack (i.e, 4 times the
      number of label st=
ack entries) including labels to be added by
      this node.

     &= nbsp; “

[KT] May be I misundersto= od your proposal then. It seems that the authors want the headend to perfor= m the behavior described in RFC3209 Sec 2.6 for SR Policies, then please sp= ecify the same with normative language. How would this work for SRv6? This way the WG can review and understand wh= at the proposal is. Note that we can also have a label stack introduced dur= ing transit due to something like TI-LFA.

&n= bsp;

[Cheng]= Yes, that is what I mentioned above, some overhead will be introduced like= FRR/TI-LFA.  Will add the text to specify how to do it in SRv6.

&n= bsp;

&n= bsp;

  1. Shouldn’t t= he concept of “path MTU” for SR Policies and its’ applica= bility and operations be first defined in a (Spring WG?) document before we= introduce its signalling aspects in protocols like BGP? Note that such a document would bring in requirements and guidelines for how th= e value is going to be computed and it’s usage for different steering= mechanisms over SR Policies.

[Cheng] This is a really small but useful and straigh= t forward extensions, it might not need to write a draft to describe the re= quirement instead of adding text in the current SR policy architecture draft or it current document.  

[KT] It is not about the = size of the document, but the clear and normative specification of behavior= s being introduced – both for the node calculating this value and for= the headend for how it is supposed to handle this. My worry is that there is devil in the details here and operational = aspects on how exactly this will work. I am not against this work. I only a= sk the authors to document the behaviors associated with this in a Spring W= G document so the WG can review all that is entailed by the proposal. It is somewhat similar to how Path S= egment was introduced – I would suggest to start with a fresh draft u= sing much of the content from this BGP document plus other clarifications a= s discussed in this email thread.

 <= /i>

Once the “Path MTU&= #8221; for SR Policy is properly specified, the BGP SRTE encoding is actual= ly trivial by simply referring to its base draft. The same may be also spec= ified via PCEP or a Yang model.

 

   &nbs= p;             = [Cheng] Agree with your proposal. We should specify the behavior clearer. T= he question is that do we need to write a new draft in SPRING to describe i= t ? or describe it in the BGP draft directly? Or add text in the existing SR policy architecture draft? We can discuss t= his. But for sure, will add text to specify this part.

 

 

  1. Finally, specific= to the proposed encoding here, would this “path MTU” not be mo= re suitable on the CP level since each SL may have different size label sta= ck and different paths and one does not know which SL would be picked for a particular flow? So may be the lowest value compu= ted for all SLs is what gets applied to the packets at the CP (i.e. SR Poli= cy) level?

[Cheng] You are correct. The PMTU is defined for SID = List. When we talk about Path MTU for SR policy, it CAN be the lowest value= of the PMTU of SID lists. But do we need this value? If we need, then the node can compute it based on PMTUs.<= /o:p>

[KT] Sure. I think these = are details and we can leave them aside for now. My main concerns are the p= revious comments.

 <= /i>

Thanks,

Ketan=

&nbs= p;

Thanks,

Ketan

&n= bsp;

&nbs= p;

From: Idr <idr-bounces@iet= f.org> On Behalf Of Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

    SR-V6, = and SR-Policy.   

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_MW3PR11MB4570379D753DF2BB47696219C1C10MW3PR11MB4570namp_-- From nobody Thu Apr 9 04:41:53 2020 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 47D753A090D; Thu, 9 Apr 2020 04:41:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158643250722.20996.2687173728603121972@ietfa.amsl.com> Reply-To: Yoav Nir Date: Thu, 09 Apr 2020 04:41:47 -0700 Archived-At: Subject: [Idr] Secdir last call review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 11:41:48 -0000 Reviewer: Yoav Nir Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This one is ready, and the Security Considerations section is remarkably well-written. From nobody Thu Apr 9 07:57:53 2020 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 C14893A091E; Thu, 9 Apr 2020 07:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXaFuT6Zumeq; Thu, 9 Apr 2020 07:57:46 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4B73A091B; Thu, 9 Apr 2020 07:57:46 -0700 (PDT) Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 983CCF384B567B9BD407; Thu, 9 Apr 2020 15:57:43 +0100 (IST) Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 9 Apr 2020 15:57:42 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme754-chm.china.huawei.com (10.3.19.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 9 Apr 2020 22:57:40 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1713.004; Thu, 9 Apr 2020 22:57:40 +0800 From: "Dongjie (Jimmy)" To: "Ketan Talaulikar (ketant)" , "Chengli (Cheng Li)" , Susan Hares , 'IDR List' CC: SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aAABGXt8AAr5fhgAAcgLvAABpa7IA== Date: Thu, 9 Apr 2020 14:57:39 +0000 Message-ID: <85087faee80c4c16aacacbb1022bb2d9@huawei.com> References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.208.192] Content-Type: multipart/alternative; boundary="_000_85087faee80c4c16aacacbb1022bb2d9huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:57:50 -0000 --_000_85087faee80c4c16aacacbb1022bb2d9huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, After reading the discussion between you and Cheng, my understanding is tha= t you are converging on the technical parts, and some additional descriptio= n would help. As for where such description belongs to, IMO it depends on whether it is a= bout generic path MTU computation and headend manipulation (similar to the = RSVP-TE case), or it would introduce additional SR specific behaviors. In t= he former case, maybe it is fine to add that description into this draft. I= f it is the latter case, maybe it is suitable to be described in a SPRING d= ocument. Hope this helps. Best regards, Jie From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ketan Talaulikar= (ketant) Sent: Thursday, April 9, 2020 7:33 PM To: Chengli (Cheng Li) ; Susan Hares ; 'IDR List' Cc: SPRING WG Subject: Re: [spring] [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-0= 3.txt - 2 Week WG adoption call (3/30 - 4/13) Hi Cheng, Thanks for your responses and clarifications. They help get a better unders= tanding for what exactly the authors wish to specify for "Path MTU" for SR = Policy. Will look forward to normative text with description of computation= and behaviours expected from both the entity computing this Path MTU value= and it's handling on the headend. I would request description text in the = draft instead of a normative reference to RFC3209. That said, I still don't believe this belongs to an IDR document. The draft= -li-idr-sr-policy-path-mtu should limit itself to the BGP encodings. I woul= d suggest to move the specification of SR Policy Path MTU into a new draft = positioned in the Spring WG. That IMHO would be the right way to progress t= his work. Thanks, Ketan From: Chengli (Cheng Li) = > Sent: 09 April 2020 16:27 To: Ketan Talaulikar (ketant) >; = Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Thanks for your reply, please see my reply inline. Cheng From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Wednesday, April 8, 2020 7:37 PM To: Chengli (Cheng Li) >;= Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Cheng, Please check inline below. From: Chengli (Cheng Li) = > Sent: 08 April 2020 14:36 To: Ketan Talaulikar (ketant) >; = Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Many thanks for your comments, and sorry for my delay, please see my reply = inline. Thanks, Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (keta= nt) Sent: Friday, April 3, 2020 4:18 PM To: Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hello, I have a few questions for the authors of this draft and some discussion po= ints for the WG. 1) What is precisely the definition of this "path MTU" for an SR Polic= y? I am guessing that it includes all the labels/SIDs that are used for the= SR path? [Cheng] Yes, The Path MTU describes the largest size of the packet, includi= ng the overhead of Labels/SIDs/IPv6 header/SRH and others. [KT] Here, "path" is the SR path and the SR path is specified by a label st= ack. So the "payload" over the SR path does not include the SID List use to= construct the path itself, right? Or do you mean that the "path MTU" is th= e lowest MTU value of all paths over which packet steered over the SR Polic= y may go over? [Cheng] The path here is the SR path specified by a SID list. The PMTU is = the lowest MTU value of the MTU of the Links along the path identified by t= he SID list. It is the largest size of the packet to be sent along the SR p= ath (SID List), so it can include the payload, overhead of SR, FRR and may = be Binding SID (an Binding SID will introduce a new IPv6 encapsulation or a= new SRH). When encapsulating a packet, the length of the payload(inner IP packet or s= omething else) should be less than the PMTU minus the overhead of SID List/= SRH/ FRR overhead and Binding SID overhead, but it is a implementation choi= ce. [KT] Here a "path MTU" object is being defined. It is to be calculated by a= component X and communicated over BGP protocol to a node/component Y. IMHO= we cannot leave such things to implementation aspects - this attribute sho= uld be clearly specified so that both X and Y have the same understanding o= f what it means and how it is to be used.. [Cheng] Well, as I mention above, this value is the largest value of the MT= U of links along the path. This value can be calculated very precisely. How= ever, when we encapsulate the packet, how long the payload can be, it depe= nds on the implementation. For example, device A can encapsulate M byte, and M =3D P= MTU - A(overhead of SR) - B (FRR overhead), and the FRR overhead may be 40= Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on t= he policy. But you may be right, we can calculate the TRUE PMTU on X = (Controller, etc.) , and send it to the device, and the device will use it = as the longest length of the Payload, that will be fine. We can discuss abo= ut this. 2) While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path= MTU" for RSVP-TE LSPs, it does describe the procedures for the same for ha= ndling IP packets/payloads on the headend. It does not cover the scenarios = where the incoming packets may be themselves labelled. [Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rf= c3209#section-2.6, but I think it covers the scenarios where the incoming p= ackets may be themselves labelled. I may be wrong. " The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined. Using the terminology defined in [5], an LSR MUST execute the following algorithm: 1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node. " [KT] May be I misunderstood your proposal then. It seems that the authors w= ant the headend to perform the behavior described in RFC3209 Sec 2.6 for SR= Policies, then please specify the same with normative language. How would = this work for SRv6? This way the WG can review and understand what the prop= osal is. Note that we can also have a label stack introduced during transit= due to something like TI-LFA. [Cheng] Yes, that is what I mentioned above, some overhead will be introduc= ed like FRR/TI-LFA. Will add the text to specify how to do it in SRv6. 3) Shouldn't the concept of "path MTU" for SR Policies and its' applic= ability and operations be first defined in a (Spring WG?) document before w= e introduce its signalling aspects in protocols like BGP? Note that such a = document would bring in requirements and guidelines for how the value is go= ing to be computed and it's usage for different steering mechanisms over SR= Policies. [Cheng] This is a really small but useful and straight forward extensions, = it might not need to write a draft to describe the requirement instead of a= dding text in the current SR policy architecture draft or it current docume= nt. [KT] It is not about the size of the document, but the clear and normative = specification of behaviors being introduced - both for the node calculating= this value and for the headend for how it is supposed to handle this. My w= orry is that there is devil in the details here and operational aspects on = how exactly this will work. I am not against this work. I only ask the auth= ors to document the behaviors associated with this in a Spring WG document = so the WG can review all that is entailed by the proposal. It is somewhat s= imilar to how Path Segment was introduced - I would suggest to start with a= fresh draft using much of the content from this BGP document plus other cl= arifications as discussed in this email thread. Once the "Path MTU" for SR Policy is properly specified, the BGP SRTE encod= ing is actually trivial by simply referring to its base draft. The same may= be also specified via PCEP or a Yang model. [Cheng] Agree with your proposal. We should specify the be= havior clearer. The question is that do we need to write a new draft in SPR= ING to describe it ? or describe it in the BGP draft directly? Or add text = in the existing SR policy architecture draft? We can discuss this. But for = sure, will add text to specify this part. 4) Finally, specific to the proposed encoding here, would this "path M= TU" not be more suitable on the CP level since each SL may have different s= ize label stack and different paths and one does not know which SL would be= picked for a particular flow? So may be the lowest value computed for all = SLs is what gets applied to the packets at the CP (i.e. SR Policy) level? [Cheng] You are correct. The PMTU is defined for SID List. When we talk abo= ut Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID li= sts. But do we need this value? If we need, then the node can compute it ba= sed on PMTUs. [KT] Sure. I think these are details and we can leave them aside for now. M= y main concerns are the previous comments. Thanks, Ketan Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 30 March 2020 18:06 To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_85087faee80c4c16aacacbb1022bb2d9huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

 

After reading the discussion between you and Cheng, my understand= ing is that you are converging on the technical parts, and some additional = description would help.

 

As for where such description belongs to, IMO it depends on wheth= er it is about generic path MTU computation and headend manipulation (simil= ar to the RSVP-TE case), or it would introduce additional SR specific behaviors. In the former case, maybe it is fine to = add that description into this draft. If it is the latter case, maybe it is= suitable to be described in a SPRING document.

 

Hope this helps.

 

Best regards,

Jie

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, April 9, 2020 7:33 PM
To: Chengli (Cheng Li) <chengli13@huawei.com>; Susan Hares <= ;shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] [Idr] WG Adoption - draft-li-idr-sr-policy-pat= h-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Cheng,

 

Thanks for your responses and clarifications. They help get a better = understanding for what exactly the authors wish to specify for “Path = MTU” for SR Policy. Will look forward to normative text with description of computation and behaviours expected from both the= entity computing this Path MTU value and it’s handling on the headen= d. I would request description text in the draft instead of a normative ref= erence to RFC3209.

 

That said, I still don’t believe this belongs to an IDR documen= t. The draft-li-idr-sr-policy-path-mtu should limit itself to the BGP encod= ings. I would suggest to move the specification of SR Policy Path MTU into a new draft positioned in the Spring WG. That I= MHO would be the right way to progress this work.

 

Thanks,

Ketan

 

From: Chengli (Cheng Li) <= chengli13@huawei.com>
Sent: 09 April 2020 16:27
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Keta= n,

&n= bsp;

Thanks = for your reply, please see my reply inline.

&n= bsp;

Cheng

&n= bsp;

&n= bsp;

&n= bsp;

From: Ketan Talaulikar (ketant) [= mailto:ketant@cisco.com]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) <c= hengli13@huawei.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Cheng,

 

Please check inline below.

 

From: Chengli (Cheng Li) <= chengli13@huawei.com>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Keta= n,

&n= bsp;

Many th= anks for your comments, and sorry for my delay, please see my reply inline.=

&n= bsp;

Thanks,=

Cheng

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.c= om>; 'IDR List' <idr@ietf.org= >
Cc: SPRING WG <spring@ietf.org= >
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hello,

 

I have a few questions for the authors of this draft and some discuss= ion points for the WG.

 

1)      What is precisely the definition of this “path MTU̶= 1; for an SR Policy? I am guessing that it includes all the labels/SIDs tha= t are used for the SR path?

[Cheng] Yes, The Path MTU describes the largest size = of the packet, including the overhead of Labels/SIDs/IPv6 header/SRH and ot= hers.

[KT] Here, “path= 221; is the SR path and the SR path is specified by a label stack. So the &= #8220;payload” over the SR path does not include the SID List use to = construct the path itself, right? Or do you mean that the “path MTU” is the lowest MTU value of all paths over which packet steered = over the SR Policy may go over?

&n= bsp;

[Cheng]= The path here is the SR path specified by a SID list.  The PMTU is the lowest MTU value of t= he MTU of the Links along the path identified by the SID list. It is the la= rgest size of the packet to be sent along the SR path (SID List), so it can= include the payload, overhead of SR, FRR and may be Binding SID (an Binding SID will introduce a new IPv6 encap= sulation or a new SRH).

<= o:p> 

When encapsulating a packet, the length of the payloa= d(inner IP packet or something else) should be less than the PMTU minus the= overhead of SID List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation choice.

[KT] Here a “path MTU” object is being defined. It = is to be calculated by a component X and communicated over BGP protocol to = a node/component Y. IMHO we cannot leave such things to implementation aspects – this attribute should be clearly specifi= ed so that both X and Y have the same understanding of what it means and ho= w it is to be used..

 

[Cheng]= Well, as I mention above, this value is the largest value of the MTU of li= nks along the path. This value can be calculated very precisely. However, w= hen we encapsulate the packet, how long  the payload can be, it depends on the implementation.

 &= nbsp;           &nbs= p;   For example, device A can encapsulate M byte, and M =3D=   PMTU –  A(overhead of SR) – B (FRR overhead), and t= he FRR overhead may be 40 Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on the policy. 

 &= nbsp;           &nbs= p;   

 &= nbsp;           &nbs= p;   But you may be right, we can calculate the TRUE PMTU on= X (Controller, etc.) , and send it to the device, and the device will use = it as the longest length of the Payload, that will be fine. We can discuss about this.

 

 

 

2)      While https://tools.ietf.org/html/rfc3209#secti= on-2.6 defines “path MTU”= ; for RSVP-TE LSPs, it does describe the procedures for the same for handling IP packets/payloads on the headend. It does not = cover the scenarios where the incoming packets may be themselves labelled.<= /span>=

[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#secti= on-2.6, but I think it covers the = scenarios where the incoming packets may be themselves labelled. I may be wrong.

 

   “=

   The following algo= rithm applies to all unlabeled IP datagrams and to

   any labeled packet= s which the node knows to be IP datagrams, to which

   labels need to be = added before forwarding.  For labeled packets the

   bottom of stack is= found, the IP header examined.

 

   Using the terminology defined in [5], an LSR MUST execute the
   following algorithm:
 
   1. Let N be the number of bytes in t=
he label stack (i.e, 4 times the
      number of label st=
ack entries) including labels to be added by
      this node.

     &= nbsp; “

[KT] May be I misundersto= od your proposal then. It seems that the authors want the headend to perfor= m the behavior described in RFC3209 Sec 2.6 for SR Policies, then please sp= ecify the same with normative language. How would this work for SRv6? This way the WG can review and understand wh= at the proposal is. Note that we can also have a label stack introduced dur= ing transit due to something like TI-LFA.

&n= bsp;

[Cheng]= Yes, that is what I mentioned above, some overhead will be introduced like= FRR/TI-LFA.  Will add the text to specify how to do it in SRv6.

&n= bsp;

&n= bsp;

3)      Shouldn’t the con= cept of “path MTU” for SR Policies and its’ applicability= and operations be first defined in a (Spring WG?) document before we intro= duce its signalling aspects in protocols like BGP? Note that such a document would bring in requirements and guidelines for how the val= ue is going to be computed and it’s usage for different steering mech= anisms over SR Policies.

[Cheng] This is a really small but useful and straigh= t forward extensions, it might not need to write a draft to describe the re= quirement instead of adding text in the current SR policy architecture draft or it current document.  

[KT] It is not about the = size of the document, but the clear and normative specification of behavior= s being introduced – both for the node calculating this value and for= the headend for how it is supposed to handle this. My worry is that there is devil in the details here and operational = aspects on how exactly this will work. I am not against this work. I only a= sk the authors to document the behaviors associated with this in a Spring W= G document so the WG can review all that is entailed by the proposal. It is somewhat similar to how Path S= egment was introduced – I would suggest to start with a fresh draft u= sing much of the content from this BGP document plus other clarifications a= s discussed in this email thread.

 <= /i>

Once the “Path MTU&= #8221; for SR Policy is properly specified, the BGP SRTE encoding is actual= ly trivial by simply referring to its base draft. The same may be also spec= ified via PCEP or a Yang model.

 

 &= nbsp;           &nbs= p;   [Cheng] Agree with your proposal. We should specify the beha= vior clearer. The question is that do we need to write a new draft in SPRIN= G to describe it ? or describe it in the BGP draft directly? Or add text in the existing SR policy architecture draft? = We can discuss this. But for sure, will add text to specify this part.=

&n= bsp;

 

4)      Finally, specific to th= e proposed encoding here, would this “path MTU” not be more sui= table on the CP level since each SL may have different size label stack and= different paths and one does not know which SL would be picked for a particular flow? So may be the lowest value computed= for all SLs is what gets applied to the packets at the CP (i.e. SR Policy)= level?

[Cheng] You are correct. The PMTU is defined for SID = List. When we talk about Path MTU for SR policy, it CAN be the lowest value= of the PMTU of SID lists. But do we need this value? If we need, then the node can compute it based on PMTUs.<= /o:p>

[KT] Sure. I think these = are details and we can leave them aside for now. My main concerns are the p= revious comments.

 <= /i>

Thanks,

Ketan

 

Thanks,

Ketan

&n= bsp;

 

From: Idr <idr-bounces@iet= f.org> On Behalf Of Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

    SR-V6, = and SR-Policy.   

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_85087faee80c4c16aacacbb1022bb2d9huaweicom_-- From nobody Thu Apr 9 07:59:46 2020 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 57E033A0924 for ; Thu, 9 Apr 2020 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTEVk4OmxTkC for ; Thu, 9 Apr 2020 07:59:43 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969C23A0921 for ; Thu, 9 Apr 2020 07:59:43 -0700 (PDT) Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 360A2160E7420F20CC44 for ; Thu, 9 Apr 2020 15:59:42 +0100 (IST) Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Thu, 9 Apr 2020 15:59:41 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 9 Apr 2020 22:59:39 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1713.004; Thu, 9 Apr 2020 22:59:39 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , 'IDR List' Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAG3UV1A Date: Thu, 9 Apr 2020 14:59:39 +0000 Message-ID: <8d0f405452c7486890634f36c7137368@huawei.com> References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.208.192] Content-Type: multipart/alternative; boundary="_000_8d0f405452c7486890634f36c7137368huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:59:45 -0000 --_000_8d0f405452c7486890634f36c7137368huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, Yes, I support the adoption of this document. Please find my replies to the questions inline: From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 30, 2020 8:36 PM To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? Yes, it is a useful feature for SR policy. 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt Not aware of additional issues. 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Yes, it is in the right direction and ready for adoption. Best regards, Jie Cheers, Sue Hares --_000_8d0f405452c7486890634f36c7137368huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

Yes, I support the adoption of this document.

 

Please find my replies to the questions inline:=

 

From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt = - 2 Week WG adoption call (3/30 - 4/13)

 

This begins a 2 week WG adoptio= n call for draft-li-idr-sr-policy-path-mtu-03.txt

 

You can view this draft at:

https://datatracker.ietf.org= /doc/draft-li-idr-sr-policy-path-mtu/

 

This draft distributes path max= imum transmission unit for the

SR policy via BGP.  <= /o:p>

 

Any discussion regarding on whe= ther one desires

SR Policy should be clearly dis= tinguished from the

Technical discussions on the me= chanisms to pass SR policy MTU.

 

The questions for the people to= discuss on this draft are:

 

1) Is there a need for this mec= hanism in networks using

     &= nbsp;  MPLS-SR or SR-V6 and SR policy?

 

Yes, it is a useful feature for SR policy.

 

2) Are there any error handling= issues besides what is being

     T= aken care of in RFC7752bis-03.txt

 

Not aware of additional issues.

 

3) Do you think this draft is r= eady to be adopted?

     I= n this category, please list any concerns you have

     regard= ing adoption.  This category can include

     g= eneral concerns about BGP-LS, MPLS-SR,

SR-= V6, and SR-Policy.   

 

Yes, it is in the right direction and ready for adoption.

 

Best regards,

Jie

 

 

Cheers, Sue Hares  

 

 

 

 

 

--_000_8d0f405452c7486890634f36c7137368huaweicom_-- From nobody Thu Apr 9 09:46:57 2020 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 2F0553A0C4C for ; Thu, 9 Apr 2020 09:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 sdMcObGl5dfE for ; Thu, 9 Apr 2020 09:46:53 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2115.outbound.protection.outlook.com [40.107.243.115]) (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 BF2EC3A0C47 for ; Thu, 9 Apr 2020 09:46:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YZywoQos0wIlNr2SAWxf3PeVRboHlqR+bp2e7UoO1L5laz4fH61XA6cRPB0p2K7mIg2FFZ7Hrjwr8uSgRIQ0EAE+rtTSdckNpXxkDWXxBK1UULpn8styIX5VJU+hBcX0/Tc0g7UA8cpkhX24rLhec+8vev0+MNgJrnYZl+VilwsOSPyDvhrNtPiKlazDAq8rOo01qDWKYh2BFTvP7gdl5dD+/i/6xgLslx+APBwpGXQy6v/70yXlpCZZlshFsw031pBcH2J+eFWrRJQkxq19/ajI4b13FuCvHVwozYQGnIIJSMnvGsC+t+RLNxEu8gQR7siWMcJSNjYG7O2A/+ERpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H7PkmUyZxrh53vxNk7eGOtfFAprEBOAbS5YKz/5SRzU=; b=nPxH6P7xovYJRqdM8PvkRJDhecIm50BDCO3vX4VGI+NOyhDzGZIEaVwQeloHwLYxl7e88Pi9WtJRPnTFb2R6POS2pImYH5oaoY+Ph1hhM2hcfFU0HQCFvSJi1fc9k4YZ2QFaI1pXbVAtiLPBvoefxPnolEKjI8GsVtOZWlYbv2B4WL0keQCeF2x6aCs/0v0bKQDxky8xIpah621B7dOW9vJfdzqN/T5HAuhzjwr/d9Jc0coxR4olM+qkuOAFmDwLgwamgJ4j6w1lRWxsYwYReGfLRm+q41Ol395eSfT5hVYvBv/DKX42VZIrh0FVENd0PBT/+H55aW7zhuHRMJGJPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H7PkmUyZxrh53vxNk7eGOtfFAprEBOAbS5YKz/5SRzU=; b=UQTARFoXY37npiU7zpytwcEdOupU/KSY5XdR+WEG9D5yKBdVzV91Y7GQq+REbD00jL4AkjBnDFoYEn5tNuEFBb8X1x3qgHDYq1ftnEMam00ulKHoUHJgkP7QGWueLsgjNna8Gzyw0pnx2RCjOI0YxW5bytQecm0BPzKgfDfSEJo= Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB2205.namprd13.prod.outlook.com (2603:10b6:301:34::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Thu, 9 Apr 2020 16:46:49 +0000 Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945%3]) with mapi id 15.20.2900.012; Thu, 9 Apr 2020 16:46:49 +0000 From: Linda Dunbar To: "Hu, Jun (Nokia - US/Mountain View)" , Susan Hares , 'IDR List' Thread-Topic: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Thread-Index: AQHWDgOk/hmrdED3fU+qtmLracM/U6hw+RzA Date: Thu, 9 Apr 2020 16:46:49 +0000 Message-ID: References: In-Reply-To: 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=linda.dunbar@futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db8616bc-beb2-4764-cf58-08d7dca59937 x-ms-traffictypediagnostic: MWHPR1301MB2205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1301MB2096.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(136003)(396003)(39840400004)(376002)(346002)(366004)(186003)(33656002)(44832011)(66446008)(26005)(86362001)(71200400001)(2906002)(76116006)(66476007)(66946007)(66556008)(64756008)(66574012)(81166007)(8676002)(81156014)(110136005)(8936002)(53546011)(6506007)(7696005)(55016002)(966005)(9686003)(316002)(296002)(52536014)(5660300002)(478600001); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kzjzp2UEfzCqz5asyve7PIEKVU5pJw0EAlisIfHjGDuoAui/0Ttg8MfAj3nvAtvqCiQ8ahZiv2KG7VKXkclrdyZdxG6W0co8k+D5pnBQWDzQoGafncUqogwaT90xG9ZBH7UYqu2qm30RapEJMkyBcqeRPbPPK0hk2Vq7/qgody6mUbJyJQ3eiCR17AUKZzDwLoZt3I/8/6CZquAzVQjS8szkCdiKtzKeNVl3m+XBzV+0kfIRww0iYTsEteim/xlGWfD5OwpNps1kC+4Q9d0eJc2Z1DCOfhyx7PXwtRtgFwRmIj1szOVJRiKHxH3HgNyvFop5qWOckbeKSQV67/XFsnOYFLMdmSLcFLLCxfLC3c7z2wfOlzboXc9L3XBfQKzmJuHuDS2090mg95p3fBSmx+TKRffCIyxgUiJ4YLEAF3LUYFxGioyjeQn0nLWYVt0JAbhKGMGskDAdVjoBZgK/caEwtIqz3vfI2lyWnfZe8/3I0rH2AFRseqrXrU8D3rev61x8UhlrJu2PHv8myZgpgg== x-ms-exchange-antispam-messagedata: bJkV6B/Bii7eh3lyDd6c+wW8QsCcqNRk656nubb9pFCLCTrhIoRDYg8h7zDyMcIuh+psKlgTetT2BuaFNZTOhNfiEE3Cr7hwoYLahEeQM+03BUMQh2lJttDVP1Lap8dZSTVWNNWoad3/BXai+5fr+A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR1301MB20968DD059BB7F59D6FFD31D85C10MWHPR1301MB2096_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: db8616bc-beb2-4764-cf58-08d7dca59937 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 16:46:49.4000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EgyEeddE2shqi6hqg5FkZgDMM4MNTo9bOgraZSBMAgybocyUPnNoT9bEEC1NB8OlhRt/bOOanQOeXMM4LB+NWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB2205 Archived-At: Subject: Re: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 16:46:55 -0000 --_000_MWHPR1301MB20968DD059BB7F59D6FFD31D85C10MWHPR1301MB2096_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jun, your Section 2.3 IPsec Configuration Tag Sub-TLV has Certificate trust-anc= hor: CA-1 and Certificate trust-anchor: CA-2 Why need two Trust Anchors (CA-1 & CA-2)? What are expected actions for a node receiving this information? If the re= ceiver has different trust anchor, should the receiver do more validation? What are the expected actions for receiver upon receiving the local/remote= Traffic selector protocol, local/remote Traffic selector port range? For your example, what if the subnet S behind A only needs to be encrypted = to B, but not to C because A<->C has VPN connected. What should C do with t= he received IPsec UPDATE? For a network with hundreds of nodes, what do the= y do with the received UPDATE? a simple case, where there are 3 routers: A , B and C, A has subnet S behin= d it that require IPsec protection, if B or C need to forward a packet to S= , it must be over an IPsec tunnel; Thank you, Linda Dunbar From: Hu, Jun (Nokia - US/Mountain View) Sent: Wednesday, April 8, 2020 7:13 PM To: Linda Dunbar ; Susan Hares ; 'IDR List' Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 = Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-= bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Sorry for replying late, Pls see my answer in line From: Idr > On Behalf Of = Linda Dunbar Sent: Friday, April 3, 2020 1:24 PM To: Susan Hares >; 'IDR List' > Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week= WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-= ipsec-transport-mode-00 (3/30 to 4/13/2020 Jun, Need a few clarify questions for your draft. 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running be= tween IPsec peers? [Hu Jun] yes 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKE= v2 with the speaker without any configuration from the administer? If Node = B can only establish IPsec IKEv2 with another node C, does it matter if the= Node B receives or not receives the BGP update from the C? [Hu Jun] it is up to the implementation, there are two options: * create the tunnel upon receiving BGP update * create tunnel only when router need to forward a packet to a= destination that need to be reached via IPsec tunnel either way works 1. How does the BGP UPDATE ease the IPsec configuration? Does it ease t= he configuration on the BGP UPDATE speaker? Or does it ease the configurati= on of the receiver? [Hu Jun] think of a simple case, where there are 3 routers: A , B and C, A = has subnet S behind it that require IPsec protection, if B or C need to for= ward a packet to S, it must be over an IPsec tunnel; so traditionally, you = would configure two tunnels on A: A->B and A->C, then you would also need t= o configure a tunnel B->A on B and a tunnel C->A on C, so in total, there a= re 4x tunnel configuration on 3 routers; but now with my draft, you just ne= ed to configure A to advertise a BGP update for S which include ipsec confi= g, there is no per-tunnel configuration on A, B or C. 1. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is = there still "Private Routing Instances"? [Hu Jun] the concept of public and private routing instance is to separate = trust network from un-trusted network; Typically, for security reason, you = want to separate trusted network from un-trusted network by using different= routing instance, for example, internet is un-trusted network, while an e= nterprise intranet is trusted network, they are different routing instance;= then an payload packet from the intranet is encapsulated into an IPsec tu= nnel, the result ESP tunnel packet is forwarded via internet. But public routing instance could same as private routing instance if you h= ave good reason to do so, there is nothing in protocol level prevent that On Page 3, the draft states that only "Local Tunnel Endpoint address, Publi= c Routing Instance and CHILD SA traffic selector address range" are adverti= sed by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the no= de? Or can be a specific Ingress or egress port of the node sending out the= BGP UPDATE? [Hu Jun] this total up to the operator, both loopback or a physical interfa= ce address could be used, but typically a loopback address is prefer for st= able reason Thank you very much. Linda Dunbar From: Idr > On Behalf Of = Susan Hares Sent: Monday, March 30, 2020 7:07 AM To: 'IDR List' > Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and= draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 This begins a 2 week WG adoption call for two drafts BGP provisioned IPSEC= infrastructure 1) draft-hujun-idr-bgp-ipsec-02.txt: BGP Provisioned IPSEC Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/ 2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt: BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec-transport-mode/<= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=3D02= %7C01%7Clinda.dunbar%40futurewei.com%7C867befd7c8f14a9f2b9708d7dc1ac510%7C0= fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637219879863945672&sdata=3DKUP1Cd= 05vEX6ZfJlzbA8gROpgktmvT1WeWS2ifaAA%2Bw%3D&reserved=3D0> These drafts were presented at IETF 104 and IETF 105.. At IETF 105, there was a detailed discussion on the security issues. After IETF 105, the author modified his draft to take care of the Issues mentioned. Discussion during the WG Adoption should examine: 1) Has this draft addressed the necessary security issues to be adopted as IDR WG draft? 2) Is this useful generic IPSEC functionality for networks? The EVPN related to IPSEC continues in BESS. This draft is considered here as a general feature. 3) Are there any deployments of this draft? Stay safe and healthy... Sue --_000_MWHPR1301MB20968DD059BB7F59D6FFD31D85C10MWHPR1301MB2096_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jun,

 

your Section 2.3 IPsec Configuration Tag Sub-TLV has=  Certificate trust-anchor: CA-1 and Certificate trust-anchor: CA-2

 

Why need two Trust Anchors (CA-1 & CA-2)? <= /o:p>

What are expected actions for a node receiving this = information?  If the receiver has different trust anchor, should the r= eceiver do more validation?

 

What are the expected actions for receiver upon rece= iving the  local/remote Traffic selector protocol, local/remote Traffi= c selector port range?

 

For your example, what if the subnet S behind A only= needs to be encrypted to B, but not to C because A<->C has VPN conne= cted. What should C do with the received IPsec UPDATE? For a network with h= undreds of nodes, what do they do with the received UPDATE?

 

a simple case, wher= e there are 3 routers: A , B and C, A has subnet S behind it that require I= Psec protection, if B or C need to forward a packet to S, it must be over a= n IPsec tunnel;

 

Thank you,

 

Linda Dunbar

 

From: Hu, Jun (Nokia - US/Mountain View) <= jun.hu@nokia.com>
Sent: Wednesday, April 8, 2020 7:13 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; Susan Hares <= ;shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was= RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-huj= un-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

 

Sorry for replying late, Pls see my answer in line <= o:p>

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Linda Dunbar
Sent: Friday, April 3, 2020 1:24 PM
To: Susan Hares <shares@ndzh.c= om>; 'IDR List' <idr@ietf.org= >
Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE:= 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-i= dr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

 

Jun,

 

Need a few clarify questions for your draft.

 

  1. Does  draft= -hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers= ?

[Hu Jun] yes

 

  1. Does receiving the IPsec BGP UPDATE triggers a node to start the &nbs= p;IKEv2 with the speaker without any configuration from the administer? If = Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the = BGP update from the C?

[Hu Jun] it is up to the implementation, there= are two options:

        1. create the tunnel upon receiving BGP update<= /li>
        2. create tunnel only when router need to forward a packet to = a destination that need to be reached via IPsec tunnel

either way works <= /i>

  1. How does the BGP UPDATE ease the IPsec configuration? Does  it e= ase the configuration on the BGP UPDATE speaker? Or does it ease the config= uration of the receiver?

[Hu Jun] think of a simple case, where there a= re 3 routers: A , B and C, A has subnet S behind it that require IPsec prot= ection, if B or C need to forward a packet to S, it must be over an IPsec t= unnel; so traditionally, you would configure two tunnels on A: A->B and A->C, then you would also need = to configure a tunnel B->A on B and a tunnel C->A on C, so in total, = there are 4x tunnel configuration on 3 routers; but now with my draft, you = just need to configure A to advertise a BGP update for S which include ipsec config, there is no per-tunnel configurat= ion on A, B or C.

  1. How to differentiate  Public Routing Instances?  

If the payload packet wi= thin the IPsec tunnel are simple IP forwarding, is there still “Priva= te Routing Instances”?

[Hu Jun] the concept of public and private rou= ting instance is to separate trust network from un-trusted network; Typical= ly, for security reason, you want to separate trusted network from un-trust= ed network by using different routing instance,  for example, internet is un-trusted network, while an ente= rprise intranet is trusted network, they are different routing instance; &n= bsp;then an payload packet from the intranet is encapsulated into an IPsec = tunnel, the result ESP tunnel packet is forwarded via internet.

But public routing instance could same as priv= ate routing instance if you have good reason to do so, there is nothing in = protocol level prevent that

On Page 3, the draft states that only “Local T= unnel Endpoint address, Public Routing Instance and CHILD SA traffic select= or address range” are advertised by the BGP.

Is the Local Tunnel Endp= oint address same as the LOOPBACK address of the node? Or can be a specific= Ingress or egress port of the node sending out the BGP UPDATE?

[Hu Jun] this total up to the operator, both l= oopback or a physical interface address could be used, but typically a loop= back address is prefer for stable reason

 

Thank you very much.

 

Linda Dunbar

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 7:07 AM
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.= txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020=

 

This begins a 2 week WG adoption call for  two = drafts BGP provisioned IPSEC infrastructure

 

1) draft-hujun-idr-bgp-ipsec-02.txt:

BGP Provisioned IPSEC Tunnel Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/<= /a>

 

2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt:<= o:p>

BGP Provisioned IPsec Transport Mode Protected Tunne= l Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-id= r-bgp-ipsec-transport-mode/

 

These drafts were presented at IETF 104 and IETF 105= ..

At IETF 105, there was a detailed discussion on the = security issues.

After IETF 105, the author modified his draft to tak= e care of the

Issues mentioned. 

 

Discussion during the WG Adoption should examine:

1) Has this draft addressed the necessary security i= ssues to

    be adopted as IDR WG draft?<= o:p>

 

2) Is this useful generic IPSEC functionality for ne= tworks?

 

   The EVPN related to IPSEC continue= s in BESS.

   This draft is considered here as a= general feature.

 

3) Are there any deployments of this draft?

 

 

Stay safe and healthy… Sue

 

--_000_MWHPR1301MB20968DD059BB7F59D6FFD31D85C10MWHPR1301MB2096_-- From nobody Thu Apr 9 10:26:25 2020 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 AFBBE3A0CB0 for ; Thu, 9 Apr 2020 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 9aYyl9h9i6jb for ; Thu, 9 Apr 2020 10:26:20 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20722.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8a::722]) (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 0F8EF3A0CB6 for ; Thu, 9 Apr 2020 10:26:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LE6rXSAKOG1UybUM3R/fnGP+xec3LOblFiH9rXq869xwkKxx0zPi5iQ2rT6xFlpNB4JSHC4drpZjRVQV25WDABe2vcqfXP+mxv6eiZDFb5nYtL69ol/wVomkgLqbHYQcLTFHU2VgIEJNT5IkQaGVPBHgEIt0M7b8oc7P+ID5TZInQY9v30+p7H+4v5q1Xqlr59ciGw71hJydfj0d0NCLJua8eEUqjDUxHV97qkKWWp+SxDqfPVoxLMQ5H/xsCP972VouIJnL0vp2vNKbhhPTODZikhRPhymksXsnR85Tls4S3Y4g4qH6lk7s43br65lubQ4spqqiwzYEhtAjURn9FA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0MbUqMXLT01YFZQ08irfK4lud4BfdHrG0axah8bh9H4=; b=gY0cukpDvXqhRhoVcHgf4jn+xb/RgYqy8Bphush1f2yNpmj/19qJAijr3IXXiIU9D8B6Abb/4ZSTNlUsCpt4Ko75vWhDIUUq3nk/hjzuGzpsXiBpcp5omFXLGxa+fkbV7iBoOmreboamoRiaPZIpR00elh+GAnBsHt7Q1Og5yL7tIgsuubK+EcHP50W33fGgedOsl0dSnKSBF/JCFQ72XymeI77cX9ck1mayFB/J6GFsiLSsgLWt9vhjKaceXtb7vH2hf/c1QeK7ECZlvbIoAvsNyHrX8Zg7ZinwOLTRRkq2mVtlWN89sxztdjnMCxq29q+5+edf+LcSXgicz6Hj8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0MbUqMXLT01YFZQ08irfK4lud4BfdHrG0axah8bh9H4=; b=rQ9VxJfFaGjlnfR5uPtq+ABDJcoVE+iTPDUkV4I7AJMKX8ejm3F9HhzQTDK6OBY9M+asRnAAfzWMDCGN6QaXY5Pn4f2B+L/aW0dcctCfGMyskjefQxbdNjDuVch8gl2CgNAWzWml8dac5c8gGfoeYHNu83IIjl611pv5kP+UbkE= Received: from BY5PR08MB6312.namprd08.prod.outlook.com (2603:10b6:a03:1f0::19) by BY5PR08MB6375.namprd08.prod.outlook.com (2603:10b6:a03:1e7::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Thu, 9 Apr 2020 17:26:17 +0000 Received: from BY5PR08MB6312.namprd08.prod.outlook.com ([fe80::a078:d4f7:d478:a679]) by BY5PR08MB6312.namprd08.prod.outlook.com ([fe80::a078:d4f7:d478:a679%7]) with mapi id 15.20.2878.021; Thu, 9 Apr 2020 17:26:17 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Linda Dunbar , Susan Hares , 'IDR List' Thread-Topic: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Thread-Index: AdYJ88Fzwt+5o6y3SbatjJfErRQpEwEDTVmwACNf6YAAADZZwA== Date: Thu, 9 Apr 2020 17:26:17 +0000 Message-ID: References: In-Reply-To: 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=jun.hu@nokia.com; x-originating-ip: [135.245.20.15] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1c5b16fd-1f73-4eac-0be7-08d7dcab1cd5 x-ms-traffictypediagnostic: BY5PR08MB6375: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR08MB6312.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(136003)(346002)(376002)(366004)(396003)(39860400002)(66446008)(7696005)(76116006)(66556008)(81156014)(53546011)(52536014)(5660300002)(26005)(66946007)(81166007)(8936002)(64756008)(71200400001)(6506007)(66476007)(8676002)(9686003)(33656002)(86362001)(966005)(478600001)(316002)(110136005)(66574012)(2906002)(55016002)(186003); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3GXuQ6Jm0OV5lJakam6ykpM55XFnGkhD65Gf3Xi7AETxl+qygYYP4xpXfuNoDuurV8Es4w5/a/XXNmNB+2B4FzFsoQD3LXG4CvRzaISvYBYKutRF75ObYhvXiE5P+J44c4hBknChpLzp+I6+y2SaWwgunm+dGozJXp2ugR2iPUrkQyBlGV5eKscviklm/rFgVDq2LnGHLRfXbD4Us/m2IQe8L3nWrF7lo/8wfjAM5gz0kKSORFv6F98tiAN6xvnoq5alcafkOcA/5RJj6gdpcBC/Yd/RjrAizD4a1dXVWjLiWTabgJdm/2IVLxLYC9aWGwoMewtBXNxIAQ0agm4cB7btfnr2c2NQ9Aq5oIKiHFCPaf8oFzJtDoI2SyszSgYX1yNcCdHeU6wVPJ9//OnY9TYe3DQNQ2c3i8Gw/bDkdHqGaO84lfbIJVvMq6nnHhcNrQnmlK1z4K3tyc/Y2SVh2Mfv8fF1Q+6IPIz4AzesRq2Vg/hPIfRqjJWlaEfxG7fwO0hKTmE8z0uPsusKKqHwUg== x-ms-exchange-antispam-messagedata: wPjCWSI9KE/jsrVUZYuIf+Y+E0IgfeNtONdRmB7e9rkvitmI6RG3pV68gJoKdxK/pYczV9GZpzeuRZ7gsYXb4v7sBBoBLr5RYi7hWrTtzpc0b0sj7zB2Z30hTVDegMuk/SjILJ9Pkb7mbjdrrPEzeQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR08MB6312EA69C769DD993CFC88B695C10BY5PR08MB6312namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c5b16fd-1f73-4eac-0be7-08d7dcab1cd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 17:26:17.6421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NuRuOYoVaAiEhz2qG49r184mhthNRpQqW3gwWLnn7O1X+4KLHH5CqUW67pkBorCZLOi1+dG3xDXcTePY0pJJDQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR08MB6375 Archived-At: Subject: Re: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 17:26:24 -0000 --_000_BY5PR08MB6312EA69C769DD993CFC88B695C10BY5PR08MB6312namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pls see my comments in line From: Linda Dunbar Sent: Thursday, April 9, 2020 9:47 AM To: Hu, Jun (Nokia - US/Mountain View) ; Susan Hares ; 'IDR List' Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 = Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-= bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Jun, your Section 2.3 IPsec Configuration Tag Sub-TLV has Certificate trust-anc= hor: CA-1 and Certificate trust-anchor: CA-2 Why need two Trust Anchors (CA-1 & CA-2)? [Hu Jun] this is just an example to show IPsec configuration tag could be m= apped to different configs; for example, lets say you have two subnets belo= ngs to two type of services, each has different trust-anchor; What are expected actions for a node receiving this information? If the re= ceiver has different trust anchor, should the receiver do more validation? [Hu Jun] the IPsec configuration tag represents a set of IPsec configuratio= n for receiver to use for creating the IPsec tunnel; for example router B r= eceived a BGP update for subnet S, which contains an IPsec config tag value= T1, and T1 is mapping to a set of IPsec config include trust-anchor CA-1, = B then need to use a certificate issued by CA-1 as its credential for IPse= c tunnel authentication What are the expected actions for receiver upon receiving the local/remote= Traffic selector protocol, local/remote Traffic selector port range? [Hu Jun] same as above, these are all required Ipse config that receiver ne= ed to use for creating IPsec tunnel to reach the subnet S For your example, what if the subnet S behind A only needs to be encrypted = to B, but not to C because A<->C has VPN connected. What should C do with t= he received IPsec UPDATE? For a network with hundreds of nodes, what do the= y do with the received UPDATE? a simple case, where there are 3 routers: A , B and C, A has subnet S behin= d it that require IPsec protection, if B or C need to forward a packet to S= , it must be over an IPsec tunnel; [Hu Jun] if IPsec only need between A and B, then assume subnet behind B is= S2, then in the ipsec tunnel TLV of tunnel-encap attr of BGP update for S,= A could include a Remote Prefix sub-TLV as S2, this means this Ipsec tunne= l requirement is only required between subnet S <-> S2; Thank you, Linda Dunbar From: Hu, Jun (Nokia - US/Mountain View) > Sent: Wednesday, April 8, 2020 7:13 PM To: Linda Dunbar >; Susan Hares >; 'IDR List' > Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 = Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-= bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 Sorry for replying late, Pls see my answer in line From: Idr > On Behalf Of = Linda Dunbar Sent: Friday, April 3, 2020 1:24 PM To: Susan Hares >; 'IDR List' > Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week= WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-= ipsec-transport-mode-00 (3/30 to 4/13/2020 Jun, Need a few clarify questions for your draft. 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running be= tween IPsec peers? [Hu Jun] yes 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKE= v2 with the speaker without any configuration from the administer? If Node = B can only establish IPsec IKEv2 with another node C, does it matter if the= Node B receives or not receives the BGP update from the C? [Hu Jun] it is up to the implementation, there are two options: * create the tunnel upon receiving BGP update * create tunnel only when router need to forward a packet to a= destination that need to be reached via IPsec tunnel either way works 1. How does the BGP UPDATE ease the IPsec configuration? Does it ease t= he configuration on the BGP UPDATE speaker? Or does it ease the configurati= on of the receiver? [Hu Jun] think of a simple case, where there are 3 routers: A , B and C, A = has subnet S behind it that require IPsec protection, if B or C need to for= ward a packet to S, it must be over an IPsec tunnel; so traditionally, you = would configure two tunnels on A: A->B and A->C, then you would also need t= o configure a tunnel B->A on B and a tunnel C->A on C, so in total, there a= re 4x tunnel configuration on 3 routers; but now with my draft, you just ne= ed to configure A to advertise a BGP update for S which include ipsec confi= g, there is no per-tunnel configuration on A, B or C. 1. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is = there still "Private Routing Instances"? [Hu Jun] the concept of public and private routing instance is to separate = trust network from un-trusted network; Typically, for security reason, you = want to separate trusted network from un-trusted network by using different= routing instance, for example, internet is un-trusted network, while an e= nterprise intranet is trusted network, they are different routing instance;= then an payload packet from the intranet is encapsulated into an IPsec tu= nnel, the result ESP tunnel packet is forwarded via internet. But public routing instance could same as private routing instance if you h= ave good reason to do so, there is nothing in protocol level prevent that On Page 3, the draft states that only "Local Tunnel Endpoint address, Publi= c Routing Instance and CHILD SA traffic selector address range" are adverti= sed by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the no= de? Or can be a specific Ingress or egress port of the node sending out the= BGP UPDATE? [Hu Jun] this total up to the operator, both loopback or a physical interfa= ce address could be used, but typically a loopback address is prefer for st= able reason Thank you very much. Linda Dunbar From: Idr > On Behalf Of = Susan Hares Sent: Monday, March 30, 2020 7:07 AM To: 'IDR List' > Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and= draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 This begins a 2 week WG adoption call for two drafts BGP provisioned IPSEC= infrastructure 1) draft-hujun-idr-bgp-ipsec-02.txt: BGP Provisioned IPSEC Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/ 2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt: BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec-transport-mode/<= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=3D02= %7C01%7Clinda.dunbar%40futurewei.com%7C867befd7c8f14a9f2b9708d7dc1ac510%7C0= fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637219879863945672&sdata=3DKUP1Cd= 05vEX6ZfJlzbA8gROpgktmvT1WeWS2ifaAA%2Bw%3D&reserved=3D0> These drafts were presented at IETF 104 and IETF 105.. At IETF 105, there was a detailed discussion on the security issues. After IETF 105, the author modified his draft to take care of the Issues mentioned. Discussion during the WG Adoption should examine: 1) Has this draft addressed the necessary security issues to be adopted as IDR WG draft? 2) Is this useful generic IPSEC functionality for networks? The EVPN related to IPSEC continues in BESS. This draft is considered here as a general feature. 3) Are there any deployments of this draft? Stay safe and healthy... Sue --_000_BY5PR08MB6312EA69C769DD993CFC88B695C10BY5PR08MB6312namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pls see my comments in line

 

From: Linda Dunbar <linda.dunbar@futurewei= .com>
Sent: Thursday, April 9, 2020 9:47 AM
To: Hu, Jun (Nokia - US/Mountain View) <jun.hu@nokia.com>; Sus= an Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was= RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-huj= un-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

 

Jun,

 

your Section 2.3 IPsec Configuration Tag Sub-TLV has=  Certificate trust-anchor: CA-1 and Certificate trust-anchor: CA-2

 

Why need two Trust Anchors (CA-1 & CA-2)? <= /o:p>

[Hu Jun] this is just an example to show IPsec= configuration tag could be mapped to different configs; for example, lets = say you have two subnets belongs to two type of services, each has differen= t trust-anchor;

What are expected actions for a node receiving this = information?  If the receiver has different trust anchor, should the r= eceiver do more validation?

 

[Hu Jun] the IPsec configuration tag represent= s a set of IPsec configuration for receiver to use for creating the IPsec t= unnel; for example router B received a BGP update for subnet S, which conta= ins an IPsec config tag value T1, and T1 is mapping to a set of IPsec config include trust-anchor CA-1, &nbs= p;B then need to use a certificate issued by CA-1 as its credential for IPs= ec tunnel authentication

What are the expected actions for receiver upon rece= iving the  local/remote Traffic selector protocol, local/remote Traffi= c selector port range?

[Hu Jun] same as above, these are all required= Ipse config that receiver need to use for creating IPsec tunnel to reach t= he subnet S

 

For your example, what if the subnet S behind A only= needs to be encrypted to B, but not to C because A<->C has VPN conne= cted. What should C do with the received IPsec UPDATE? For a network with h= undreds of nodes, what do they do with the received UPDATE?

 

a simple case, wher= e there are 3 routers: A , B and C, A has subnet S behind it that require I= Psec protection, if B or C need to forward a packet to S, it must be over a= n IPsec tunnel;

[Hu Jun] if IPsec only need between A and B, t= hen assume subnet behind B is S2, then in the ipsec tunnel TLV of tunnel-en= cap attr of BGP update for S, A could include a Remote Prefix sub-TLV as S2= , this means this Ipsec tunnel requirement is only required between subnet S <-> S2;

 

Thank you,

 

Linda Dunbar

 

From: Hu, Jun (Nokia - US/Mountain View) <= jun.hu@nokia.com>
Sent: Wednesday, April 8, 2020 7:13 PM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was= RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-huj= un-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

 

Sorry for replying late, Pls see my answer in line <= o:p>

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Linda Dunbar
Sent: Friday, April 3, 2020 1:24 PM
To: Susan Hares <shares@ndzh.c= om>; 'IDR List' <idr@ietf.org= >
Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE:= 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-i= dr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

 

Jun,

 

Need a few clarify questions for your draft.

 

  1. Does  draft= -hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers= ?

[Hu Jun] yes

 

  1. Does receiving the IPsec BGP UPDATE triggers a node to start the &nbs= p;IKEv2 with the speaker without any configuration from the administer? If = Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the = BGP update from the C?

[Hu Jun] it is up to the implementation, there= are two options:

        1. create the tunnel upon receiving BGP update<= /li>
        2. create tunnel only when router need to forward a packet to = a destination that need to be reached via IPsec tunnel

either way works <= /i>

  1. How does the BGP UPDATE ease the IPsec configuration? Does  it e= ase the configuration on the BGP UPDATE speaker? Or does it ease the config= uration of the receiver?

[Hu Jun] think of a simple case, where there a= re 3 routers: A , B and C, A has subnet S behind it that require IPsec prot= ection, if B or C need to forward a packet to S, it must be over an IPsec t= unnel; so traditionally, you would configure two tunnels on A: A->B and A->C, then you would also need = to configure a tunnel B->A on B and a tunnel C->A on C, so in total, = there are 4x tunnel configuration on 3 routers; but now with my draft, you = just need to configure A to advertise a BGP update for S which include ipsec config, there is no per-tunnel configurat= ion on A, B or C.

  1. How to differentiate  Public Routing Instances?  

If the payload packet wi= thin the IPsec tunnel are simple IP forwarding, is there still “Priva= te Routing Instances”?

[Hu Jun] the concept of public and private rou= ting instance is to separate trust network from un-trusted network; Typical= ly, for security reason, you want to separate trusted network from un-trust= ed network by using different routing instance,  for example, internet is un-trusted network, while an ente= rprise intranet is trusted network, they are different routing instance; &n= bsp;then an payload packet from the intranet is encapsulated into an IPsec = tunnel, the result ESP tunnel packet is forwarded via internet.

But public routing instance could same as priv= ate routing instance if you have good reason to do so, there is nothing in = protocol level prevent that

On Page 3, the draft states that only “Local T= unnel Endpoint address, Public Routing Instance and CHILD SA traffic select= or address range” are advertised by the BGP.

Is the Local Tunnel Endp= oint address same as the LOOPBACK address of the node? Or can be a specific= Ingress or egress port of the node sending out the BGP UPDATE?

[Hu Jun] this total up to the operator, both l= oopback or a physical interface address could be used, but typically a loop= back address is prefer for stable reason

 

Thank you very much.

 

Linda Dunbar

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 7:07 AM
To: 'IDR List' <idr@ietf.org&= gt;
Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.= txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020=

 

This begins a 2 week WG adoption call for  two = drafts BGP provisioned IPSEC infrastructure

 

1) draft-hujun-idr-bgp-ipsec-02.txt:

BGP Provisioned IPSEC Tunnel Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/<= /a>

 

2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt:<= o:p>

BGP Provisioned IPsec Transport Mode Protected Tunne= l Configuration

 

https://datatracker.ietf.org/doc/draft-hujun-id= r-bgp-ipsec-transport-mode/

 

These drafts were presented at IETF 104 and IETF 105= ..

At IETF 105, there was a detailed discussion on the = security issues.

After IETF 105, the author modified his draft to tak= e care of the

Issues mentioned. 

 

Discussion during the WG Adoption should examine:

1) Has this draft addressed the necessary security i= ssues to

    be adopted as IDR WG draft?<= o:p>

 

2) Is this useful generic IPSEC functionality for ne= tworks?

 

   The EVPN related to IPSEC continue= s in BESS.

   This draft is considered here as a= general feature.

 

3) Are there any deployments of this draft?

 

 

Stay safe and healthy… Sue

 

--_000_BY5PR08MB6312EA69C769DD993CFC88B695C10BY5PR08MB6312namp_-- From nobody Fri Apr 10 03:13:30 2020 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 307123A1B78; Fri, 10 Apr 2020 03:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYVEwwdnmWXj; Fri, 10 Apr 2020 03:13:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C673A1B72; Fri, 10 Apr 2020 03:13:18 -0700 (PDT) Received: from lhreml732-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5173AE3385A7407E8B35; Fri, 10 Apr 2020 11:13:13 +0100 (IST) Received: from lhreml732-chm.china.huawei.com (10.201.108.83) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 10 Apr 2020 11:13:12 +0100 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 10 Apr 2020 11:13:12 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.59]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Fri, 10 Apr 2020 18:13:05 +0800 From: "Chengli (Cheng Li)" To: "Ketan Talaulikar (ketant)" , Susan Hares , 'IDR List' CC: SPRING WG Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aAABGXt8AAr5fhgAAcgLvAALxWdcA== Date: Fri, 10 Apr 2020 10:13:05 +0000 Message-ID: References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029AFC3Edggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 10:13:22 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB029AFC3Edggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thanks for your comments! Sure, will add text to describe it. BTW, if we ne= ed to write a new draft, you are really welcome to do it together! Best, Cheng From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Thursday, April 9, 2020 7:33 PM To: Chengli (Cheng Li) ; Susan Hares ; 'IDR List' Cc: SPRING WG Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Cheng, Thanks for your responses and clarifications. They help get a better unders= tanding for what exactly the authors wish to specify for "Path MTU" for SR = Policy. Will look forward to normative text with description of computation= and behaviours expected from both the entity computing this Path MTU value= and it's handling on the headend. I would request description text in the = draft instead of a normative reference to RFC3209. That said, I still don't believe this belongs to an IDR document. The draft= -li-idr-sr-policy-path-mtu should limit itself to the BGP encodings. I woul= d suggest to move the specification of SR Policy Path MTU into a new draft = positioned in the Spring WG. That IMHO would be the right way to progress t= his work. Thanks, Ketan From: Chengli (Cheng Li) = > Sent: 09 April 2020 16:27 To: Ketan Talaulikar (ketant) >; = Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Thanks for your reply, please see my reply inline. Cheng From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Wednesday, April 8, 2020 7:37 PM To: Chengli (Cheng Li) >;= Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Cheng, Please check inline below. From: Chengli (Cheng Li) = > Sent: 08 April 2020 14:36 To: Ketan Talaulikar (ketant) >; = Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hi Ketan, Many thanks for your comments, and sorry for my delay, please see my reply = inline. Thanks, Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (keta= nt) Sent: Friday, April 3, 2020 4:18 PM To: Susan Hares >; 'IDR List' > Cc: SPRING WG > Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2= Week WG adoption call (3/30 - 4/13) Hello, I have a few questions for the authors of this draft and some discussion po= ints for the WG. 1) What is precisely the definition of this "path MTU" for an SR Polic= y? I am guessing that it includes all the labels/SIDs that are used for the= SR path? [Cheng] Yes, The Path MTU describes the largest size of the packet, includi= ng the overhead of Labels/SIDs/IPv6 header/SRH and others. [KT] Here, "path" is the SR path and the SR path is specified by a label st= ack. So the "payload" over the SR path does not include the SID List use to= construct the path itself, right? Or do you mean that the "path MTU" is th= e lowest MTU value of all paths over which packet steered over the SR Polic= y may go over? [Cheng] The path here is the SR path specified by a SID list. The PMTU is = the lowest MTU value of the MTU of the Links along the path identified by t= he SID list. It is the largest size of the packet to be sent along the SR p= ath (SID List), so it can include the payload, overhead of SR, FRR and may = be Binding SID (an Binding SID will introduce a new IPv6 encapsulation or a= new SRH). When encapsulating a packet, the length of the payload(inner IP packet or s= omething else) should be less than the PMTU minus the overhead of SID List/= SRH/ FRR overhead and Binding SID overhead, but it is a implementation choi= ce. [KT] Here a "path MTU" object is being defined. It is to be calculated by a= component X and communicated over BGP protocol to a node/component Y. IMHO= we cannot leave such things to implementation aspects - this attribute sho= uld be clearly specified so that both X and Y have the same understanding o= f what it means and how it is to be used. [Cheng] Well, as I mention above, this value is the largest value of the MT= U of links along the path. This value can be calculated very precisely. How= ever, when we encapsulate the packet, how long the payload can be, it depe= nds on the implementation. For example, device A can encapsulate M byte, and M =3D P= MTU - A(overhead of SR) - B (FRR overhead), and the FRR overhead may be 40= Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on t= he policy. But you may be right, we can calculate the TRUE PMTU on X = (Controller, etc.) , and send it to the device, and the device will use it = as the longest length of the Payload, that will be fine. We can discuss abo= ut this. 2) While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path= MTU" for RSVP-TE LSPs, it does describe the procedures for the same for ha= ndling IP packets/payloads on the headend. It does not cover the scenarios = where the incoming packets may be themselves labelled. [Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rf= c3209#section-2.6, but I think it covers the scenarios where the incoming p= ackets may be themselves labelled. I may be wrong. " The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined. Using the terminology defined in [5], an LSR MUST execute the following algorithm: 1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node. " [KT] May be I misunderstood your proposal then. It seems that the authors w= ant the headend to perform the behavior described in RFC3209 Sec 2.6 for SR= Policies, then please specify the same with normative language. How would = this work for SRv6? This way the WG can review and understand what the prop= osal is. Note that we can also have a label stack introduced during transit= due to something like TI-LFA. [Cheng] Yes, that is what I mentioned above, some overhead will be introduc= ed like FRR/TI-LFA. Will add the text to specify how to do it in SRv6. 3) Shouldn't the concept of "path MTU" for SR Policies and its' applic= ability and operations be first defined in a (Spring WG?) document before w= e introduce its signalling aspects in protocols like BGP? Note that such a = document would bring in requirements and guidelines for how the value is go= ing to be computed and it's usage for different steering mechanisms over SR= Policies. [Cheng] This is a really small but useful and straight forward extensions, = it might not need to write a draft to describe the requirement instead of a= dding text in the current SR policy architecture draft or it current docume= nt. [KT] It is not about the size of the document, but the clear and normative = specification of behaviors being introduced - both for the node calculating= this value and for the headend for how it is supposed to handle this. My w= orry is that there is devil in the details here and operational aspects on = how exactly this will work. I am not against this work. I only ask the auth= ors to document the behaviors associated with this in a Spring WG document = so the WG can review all that is entailed by the proposal. It is somewhat s= imilar to how Path Segment was introduced - I would suggest to start with a= fresh draft using much of the content from this BGP document plus other cl= arifications as discussed in this email thread. Once the "Path MTU" for SR Policy is properly specified, the BGP SRTE encod= ing is actually trivial by simply referring to its base draft. The same may= be also specified via PCEP or a Yang model. [Cheng] Agree with your proposal. We should specify the be= havior clearer. The question is that do we need to write a new draft in SPR= ING to describe it ? or describe it in the BGP draft directly? Or add text = in the existing SR policy architecture draft? We can discuss this. But for = sure, will add text to specify this part. 4) Finally, specific to the proposed encoding here, would this "path M= TU" not be more suitable on the CP level since each SL may have different s= ize label stack and different paths and one does not know which SL would be= picked for a particular flow? So may be the lowest value computed for all = SLs is what gets applied to the packets at the CP (i.e. SR Policy) level? [Cheng] You are correct. The PMTU is defined for SID List. When we talk abo= ut Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID li= sts. But do we need this value? If we need, then the node can compute it ba= sed on PMTUs. [KT] Sure. I think these are details and we can leave them aside for now. M= y main concerns are the previous comments. Thanks, Ketan Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 30 March 2020 18:06 To: 'IDR List' > Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Wee= k WG adoption call (3/30 - 4/13) This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-0= 3.txt You can view this draft at: https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/ This draft distributes path maximum transmission unit for the SR policy via BGP. Any discussion regarding on whether one desires SR Policy should be clearly distinguished from the Technical discussions on the mechanisms to pass SR policy MTU. The questions for the people to discuss on this draft are: 1) Is there a need for this mechanism in networks using MPLS-SR or SR-V6 and SR policy? 2) Are there any error handling issues besides what is being Taken care of in RFC7752bis-03.txt 3) Do you think this draft is ready to be adopted? In this category, please list any concerns you have regarding adoption. This category can include general concerns about BGP-LS, MPLS-SR, SR-V6, and SR-Policy. Cheers, Sue Hares --_000_C7C2E1C43D652C4E9E49FE7517C236CB029AFC3Edggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

 

Thanks for your commen= ts! Sure, will add text to describe it. BTW, if we need to write a new draf= t, you are really welcome to do it together!

 

Best,
Cheng

 

 

From: Ketan Talaulikar (ketant) [mailto:ketan= t@cisco.com]
Sent: Thursday, April 9, 2020 7:33 PM
To: Chengli (Cheng Li) <chengli13@huawei.com>; Susan Hares <= ;shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Cheng,

 

Thanks for your responses and clarifications. They help get a better = understanding for what exactly the authors wish to specify for “Path = MTU” for SR Policy. Will look forward to normative text with description of computation and behaviours expected from both the= entity computing this Path MTU value and it’s handling on the headen= d. I would request description text in the draft instead of a normative ref= erence to RFC3209.

 

That said, I still don’t believe this belongs to an IDR documen= t. The draft-li-idr-sr-policy-path-mtu should limit itself to the BGP encod= ings. I would suggest to move the specification of SR Policy Path MTU into a new draft positioned in the Spring WG. That I= MHO would be the right way to progress this work.

 

Thanks,

Ketan

 

From: Chengli (Cheng Li) <chengli13@huawei.com>
Sent: 09 April 2020 16:27
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Ketan,

 

Thanks for your reply,= please see my reply inline.

 

Cheng

 

 

 

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) <c= hengli13@huawei.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Cheng,

 

Please check inline below.

 

From: Chengli (Cheng Li) <chengli13@huawei.com>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hi Ketan,

 

Many thanks for your c= omments, and sorry for my delay, please see my reply inline.

 

Thanks,

Cheng

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.c= om>; 'IDR List' <idr@ietf.org= >
Cc: SPRING WG <spring@ietf.org= >
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.= txt - 2 Week WG adoption call (3/30 - 4/13)

 

Hello,

 

I have a few questions for the authors of this draft and some discuss= ion points for the WG.

 

1)      What is precisely the definition of this “path MTU̶= 1; for an SR Policy? I am guessing that it includes all the labels/SIDs tha= t are used for the SR path?

[Cheng] Yes, The Path MTU describes the largest size of the packet, = including the overhead of Labels/SIDs/IPv6 header/SRH and others.

[KT] Here, “path” is the SR path a= nd the SR path is specified by a label stack. So the “payload” = over the SR path does not include the SID List use to construct the path it= self, right? Or do you mean that the “path MTU” is the lowest MTU value of all paths over which packet steered over the SR Policy may go= over?

 

[Cheng] The path here = is the SR path specified by a SID list.  The PMTU is the lowest MTU value of t= he MTU of the Links along the path identified by the SID list. It is the la= rgest size of the packet to be sent along the SR path (SID List), so it can= include the payload, overhead of SR, FRR and may be Binding SID (an Binding SID will introduce a new IPv6 encap= sulation or a new SRH).

 

When encapsulating a packet, the length of the payload(inner IP pack= et or something else) should be less than the PMTU minus the overhead of SI= D List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation choice.

[KT] Here a “path MTU” object is being defined. It = is to be calculated by a component X and communicated over BGP protocol to = a node/component Y. IMHO we cannot leave such things to implementation aspects – this attribute should be clearly specifi= ed so that both X and Y have the same understanding of what it means and ho= w it is to be used.

 

[Cheng]= Well, as I mention above, this value is the largest value of the MTU of li= nks along the path. This value can be calculated very precisely. However, w= hen we encapsulate the packet, how long  the payload can be, it depends on the implementation.

 &= nbsp;           &nbs= p;   For example, device A can encapsulate M byte, and M =3D=   PMTU –  A(overhead of SR) – B (FRR overhead), and t= he FRR overhead may be 40 Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on the policy. 

 &= nbsp;           &nbs= p;   

 &= nbsp;           &nbs= p;   But you may be right, we can calculate the TRUE PMTU on= X (Controller, etc.) , and send it to the device, and the device will use = it as the longest length of the Payload, that will be fine. We can discuss about this.

 

 

 

2)      While https://tools.ietf.org/html/rfc3209#section-2.6 defines “path MTU” for RSVP-TE LSPs, it does = describe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where = the incoming packets may be themselves labelled.

[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the scenarios where the i= ncoming packets may be themselves labelled. I may be wrong.

 

   “

   The following algorithm applies t= o all unlabeled IP datagrams and to

   any labeled packets which the nod= e knows to be IP datagrams, to which

   labels need to be added before fo= rwarding.  For labeled packets the

   bottom of stack is found, the IP = header examined.

 

   Using the terminology defined in [5], an LSR MUST execute the

   following algorithm:


 


   1. Let N be the number of bytes in the label stack =
(i.e, 4 times the


      number of label stack entries) in=
cluding labels to be added by


      this node.

       “


[KT] May be I misunderstood your proposal then=
. It seems that the authors want the headend to perform the behavior descri=
bed in RFC3209 Sec 2.6 for SR Policies, then please specify the same with n=
ormative language. How would this
 work for SRv6? This way the WG can review and understand what the proposal=
 is. Note that we can also have a label stack introduced during transit due=
 to something like TI-LFA.


 


[Cheng] Yes, that is w=
hat I mentioned above, some overhead will be introduced like FRR/TI-LFA.&nb=
sp; Will add the text to specify how to do it in SRv6.



 


 



3)     
Shouldn’t the con=
cept of “path MTU” for SR Policies and its’ applicability=
 and operations be first defined in a (Spring WG?) document before we intro=
duce its signalling aspects in protocols like BGP? Note that
 such a document would bring in requirements and guidelines for how the val=
ue is going to be computed and it’s usage for different steering mech=
anisms over SR Policies.


[Cheng] This is a really small but useful and straight forward exten=
sions, it might not need to write a draft to describe the requirement inste=
ad of adding text in the current SR policy
 architecture draft or it current document.  


[KT] It is not about the size of the document,=
 but the clear and normative specification of behaviors being introduced &#=
8211; both for the node calculating this value and for the headend for how =
it is supposed to handle this. My worry
 is that there is devil in the details here and operational aspects on how =
exactly this will work. I am not against this work. I only ask the authors =
to document the behaviors associated with this in a Spring WG document so t=
he WG can review all that is entailed
 by the proposal. It is somewhat similar to how Path Segment was introduced=
 – I would suggest to start with a fresh draft using much of the cont=
ent from this BGP document plus other clarifications as discussed in this e=
mail thread.


 


Once the “Path MTU” for SR Policy =
is properly specified, the BGP SRTE encoding is actually trivial by simply =
referring to its base draft. The same may be also specified via PCEP or a Y=
ang model.


 


 &=
nbsp;           &nbs=
p;   [Cheng] Agree with your proposal. We should specify the beha=
vior clearer. The question is that do we need to write a new draft in SPRIN=
G to describe it ? or describe it in the BGP
 draft directly? Or add text in the existing SR policy architecture draft? =
We can discuss this. But for sure, will add text to specify this part.=



&n=
bsp;


 



4)     
Finally, specific to th=
e proposed encoding here, would this “path MTU” not be more sui=
table on the CP level since each SL may have different size label stack and=
 different paths and one does not know which SL
 would be picked for a particular flow? So may be the lowest value computed=
 for all SLs is what gets applied to the packets at the CP (i.e. SR Policy)=
 level?


[Cheng] You are correct. The PMTU is defined for SID List. When we t=
alk about Path MTU for SR policy, it CAN be the lowest value of the PMTU of=
 SID lists. But do we need this value?
 If we need, then the node can compute it based on PMTUs.=



[KT] Sure. I think these are details and we ca=
n leave them aside for now. My main concerns are the previous comments.


 


Thanks,


Ketan<=
/span>


 


Thanks,


Ketan


 


 






From: Idr <idr-bounces@ietf.org>
On Behalf Of Susan Hares

Sent: 30 March 2020 18:06

To: 'IDR List' <idr@ietf.org&=
gt;

Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt =
- 2 Week WG adoption call (3/30 - 4/13)






 


This begins a 2 week WG adoption call for draft-li-i=
dr-sr-policy-path-mtu-03.txt



 


You can view this draft at: 


https://datatracker.ietf.org/doc/draft-li-idr-sr-=
policy-path-mtu/


 


This draft distributes path maximum transmission uni=
t for the



SR policy via BGP.  


 


Any discussion regarding on whether one desires 


SR Policy should be clearly distinguished from the <=
o:p>


Technical discussions on the mechanisms to pass SR p=
olicy MTU.



 


The questions for the people to discuss on this draf=
t are: 



 


1) Is there a need for this mechanism in networks us=
ing 



        MPLS=
-SR or SR-V6 and SR policy? 


 


2) Are there any error handling issues besides what =
is being



     Taken care of in RFC77=
52bis-03.txt


 


3) Do you think this draft is ready to be adopted? <=
o:p>


     In this category, plea=
se list any concerns you have


     regarding adoption.  T=
his category can include 


     general concerns about=
 BGP-LS, MPLS-SR, 


    SR-V6, and SR-Policy.  =
 


 


Cheers, Sue Hares  


 


 


 


 


 
--_000_C7C2E1C43D652C4E9E49FE7517C236CB029AFC3Edggeml529mbxchi_-- From nobody Sun Apr 12 21:02:40 2020 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 CD0C83A0D0F; Sun, 12 Apr 2020 21:02:34 -0700 (PDT) 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.126.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158675055479.11334.17988235153645781921@ietfa.amsl.com> Date: Sun, 12 Apr 2020 21:02:34 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 04:02:35 -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 Dissemination of L2 Flow Specification Rules Authors : Weiguo Hao Donald E. Eastlake James Uttaro Stephane Litkowski Shunwan Zhuang Filename : draft-ietf-idr-flowspec-l2vpn-14.txt Pages : 23 Date : 2020-04-12 Abstract: This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/SAFI 6/133 and 25/134 are used for these purposes. New component types and an extended community also are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-14 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-l2vpn-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 Sun Apr 12 21:04:31 2020 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 A2C0F3A0D17; Sun, 12 Apr 2020 21:04:26 -0700 (PDT) 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.126.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158675066662.2039.7616114453115283462@ietfa.amsl.com> Date: Sun, 12 Apr 2020 21:04:26 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-nvo3-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 04:04:27 -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 Dissemination of Flow Specification Rules for Tunneled Traffic Authors : Donald Eastlake Weiguo Hao Shunwan Zhuang Zhenbin Li Rong Gu Filename : draft-ietf-idr-flowspec-nvo3-09.txt Pages : 19 Date : 2020-04-12 Abstract: This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 5575bis) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-nvo3/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-09 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-nvo3-09 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 Mon Apr 13 10:15:42 2020 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 16BC63A0FCC for ; Mon, 13 Apr 2020 10:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qXOoEkAiRQh for ; Mon, 13 Apr 2020 10:15:38 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 AF55D3A0FCA for ; Mon, 13 Apr 2020 10:15:38 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id z12so9172680ilb.10 for ; Mon, 13 Apr 2020 10:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VnHgPJxZyAgeUTz6XyXKcAvCt2H5k+TZPDiKWU77Djo=; b=laxwEl5Q7NLJ/o3v522985f1horeWfWK708T73y8+8KPilUBaOEcacEd9B8X4HLHBf c4igZ0+eAgN8VyWSXKNasOA9IIS11QnXO5ayRl5s/PCr/FbYtMyQwFqUUQHXb9Vb58Ku Nwi+sIF/iZsdd1Bf6/1xfaiA5xWltNEjpDtGHPbtCWm1fCq7m1/GumB/5XguAX9RUUvN QuSIuMuzIRvEgNntDwJhTAg+60sTGnJrARxzMwEWPnfQeSvSLvoISuI0R7aRPhfLkkib Kiqr5HqEhVDrgLYNA4oG5bGW00u5pCB2x6c6DotGW33Ax/zk0/+OVCAz2F/Ylk2WOJcY mZFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VnHgPJxZyAgeUTz6XyXKcAvCt2H5k+TZPDiKWU77Djo=; b=GyG9U5n/f0UetOvKo+ICX4NhdOw/Tv7Ir6GhDCUaKbVs1uWTNATycQJ/OLnBZ1BAH0 LPphzkpOpnsEO4+c3WI86Or08kg3kEmzEHThhaXUmPsU0LZ3XLcUfEpXLZexhBm6zTHj y9fOwVBjc2mfSBgxG9wRQppiL0+BoWTufoXbzsqtEGoCXgFwC61i0XBRaD7i2Z7ZCSXN JcnYMDPLW6qB0VlnRabRu3ue8ZHF9nY09EGDY8PpI1EToSpOvKmXNh8cOWRYd44SGxVe ifRYaMky06xTgiJkoroFyFqGGtGL+Tdqij+UTizRi4qm5WvoP6Fqmpw/GnqFaFfDdqLc vfTQ== X-Gm-Message-State: AGi0Puaw2lW0avxJLwryZQATG4xyyhs/tfXx1yRS1a8+1D07mbyO0Jf1 XqpV7Yz6S2Y7gf6Ak67XjNUJL6KpVoj7bPIqynBEUA== X-Google-Smtp-Source: APiQypIxhJ/dkKK+URVmhe2tsFLnsPzLyIDi95Hiu3mfKKpMNKxQLICehs4IBonH3aLW2WsFD3/TPI+iLgbdQp52L0c= X-Received: by 2002:a92:9a4d:: with SMTP id t74mr18977500ili.168.1586798137498; Mon, 13 Apr 2020 10:15:37 -0700 (PDT) MIME-Version: 1.0 References: <158675055479.11334.17988235153645781921@ietfa.amsl.com> In-Reply-To: <158675055479.11334.17988235153645781921@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 13 Apr 2020 13:15:26 -0400 Message-ID: To: "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 17:15:40 -0000 The is a minor revision for clarification and editorial improvement as mentioned in my presentation to the IDR WG on April 8th. The authors believe this document is ready for WG Last Call. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Apr 13, 2020 at 12:03 AM wrote: > > > 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 Dissemination of L2 Flow Specification Rules > Authors : Weiguo Hao > Donald E. Eastlake > James Uttaro > Stephane Litkowski > Shunwan Zhuang > Filename : draft-ietf-idr-flowspec-l2vpn-14.txt > Pages : 23 > Date : 2020-04-12 > > Abstract: > This document defines a Border Gateway Protocol (BGP) Flow > Specification (flowspec) extension to disseminate Ethernet Layer 2 > (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering > rules either by themselves or in conjunction with L3 flowspecs. > AFI/SAFI 6/133 and 25/134 are used for these purposes. New component > types and an extended community also are defined. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-14 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-l2vpn-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/ > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Apr 13 10:25:53 2020 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 7245C3A18EB for ; Mon, 13 Apr 2020 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLkGbwpAS6y4 for ; Mon, 13 Apr 2020 10:25:50 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 117363A16E3 for ; Mon, 13 Apr 2020 10:25:49 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id s18so6810497ioe.10 for ; Mon, 13 Apr 2020 10:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dmUTcWMNGCwihrKuqUi+lfuUjwHcWcmHlyGI2Phbvvw=; b=IZqnDG5xRG+XIch8R3T9CXaV/mAGbSFXjts9IaLSdFJvOGXZZDyV5Yod6toE8hu0Nq w/OX4bmBPP5yin058r76c9Sizc6PISIX+/G+EsD+HBmSUmYbqIJjKF6soRrOYfeYn6aX 7Fl7E0sTyHfo7h6bfe7o9aVf0k/YcvWtfhst4xgJxKfFGAVH0agnUI5PFI5qhO+IIFbX TJH/MuCmU27guycUrZ2jM5HIhUC1yhKAv7qwJkjbOHHqFOfrjDhAkK1yfFH1hC4k7LQI tlxCoz/eXyvHDi7JsHJXv8QBA6U6STsgBfeub13mBDHVx/fB3MHVUF9vLVUKFbN3fJFg gnMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dmUTcWMNGCwihrKuqUi+lfuUjwHcWcmHlyGI2Phbvvw=; b=tUSlAW8O8SkIWsBMXK0JRBGSSEj/zZG/Wtt+xLcft4PQK+Ad6eLcG4ElPF6hg/t3c6 Uo+Oq9iimyH4NDAdC8Vbf//dR23SiZfrMo4hX7fMmuhkXGPsB0lFirpcroaDSS2ejEXu aIFO6h5YE9hL+tv5UwhDFcCIzy4CKo/5ecp0jCCRQvR43Y/vCTm44sOpb6Ozh3M7oE7g BIPzYiNkgu0DZZA0Pxo/O66qZmkCNUHEz7M/40t0HBWSZWc6BFyvS2/DZDM00Ly8aN7z BppLUKYOD7xhNtS/diapKUHuEAVYisGwTkdNQAggs5Orx3+843PkvHz2hUjR+AFxGKVe ucAg== X-Gm-Message-State: AGi0PuaffPZttYAKBmz3p1u4pQmDT5W0qpX2PS/o5LBowuL7ddK1/elU h+IBFnDRIOD5zAY95DcQmiK84OpaoT7zvr78whwzyQ== X-Google-Smtp-Source: APiQypI3gIvDDkZkL91ox+ukhfn+Z0VY7E0dnXMJny/1Zc8UYYb95ptpocKtdJy3eReiC042+6w3FAfoIEo6uesuUZw= X-Received: by 2002:a02:3b50:: with SMTP id i16mr1065879jaf.39.1586798748659; Mon, 13 Apr 2020 10:25:48 -0700 (PDT) MIME-Version: 1.0 References: <158675066662.2039.7616114453115283462@ietfa.amsl.com> In-Reply-To: <158675066662.2039.7616114453115283462@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 13 Apr 2020 13:25:37 -0400 Message-ID: To: "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-nvo3-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 17:25:51 -0000 This revision includes some clarifications nd editorial improvements. Please review. Comments and suggestions are welcome. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Apr 13, 2020 at 12:05 AM wrote: > > > 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 Dissemination of Flow Specification Rules for Tunneled Traffic > Authors : Donald Eastlake > Weiguo Hao > Shunwan Zhuang > Zhenbin Li > Rong Gu > Filename : draft-ietf-idr-flowspec-nvo3-09.txt > Pages : 19 > Date : 2020-04-12 > > Abstract: > This draft specifies a Border Gateway Protocol (BGP) Network Layer > Reachability Information (NLRI) encoding format for flow > specifications (RFC 5575bis) that can match on a variety of tunneled > traffic. In addition, flow specification components are specified for > certain tunneling header fields. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-nvo3/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-09 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-nvo3-09 > > > 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 From nobody Wed Apr 15 07:22:22 2020 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 E1B993A0922; Wed, 15 Apr 2020 07:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YaZDYPBgQWJ2; Wed, 15 Apr 2020 07:22:14 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 33E6B3A091A; Wed, 15 Apr 2020 07:22:11 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id x25so17693949wmc.0; Wed, 15 Apr 2020 07:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=rMOg2R7zXfIEmx0b50wPlVhSewwx7RVGd25xmMIBjzY=; b=ES/JOZ5EhhIuM9zf9SZa03lFiCZ8NOD9ju2GrpVddmxLFaVZA0qcOe1SiSm2KTzp00 +9m9erKD0HH0+CWKqypSUhJl6DPGlUc4ngdMyqZtcbVsRkoHrZs9oKzkhEAa9m3lDKDP qJTS8ggXc2LLM9TrztQ69GF9ckz5V1Y+aHBSNdDrM2BOjdVCcJzIhGP4goF+7Dc1dicP 6oS/PVd2czlt6e86PcSxrD80FW64Q3DoU/brekopZkybTmnLiqaIfy2LY8iL/pQ08l5z yqU6AyxNqK1oUnPbUZeQshO567oX+5gRfv/ajvkqn+YK1BuyVH8SUsqXPMYlWll5VsP4 X9HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=rMOg2R7zXfIEmx0b50wPlVhSewwx7RVGd25xmMIBjzY=; b=SwlyKgiiPJlkqqveCI5G+cXNlnpQ7VeLA0a53EqQCEWRkk6x4/ZVnTYf04+hEnesHr EHSvZw5ArD5eNfQgtTeiMJldPdlckiEd3zSqHGjRuOOgt4CBk+MTgeH6TmUkNU04vISK Sb40f8F5j9irGAb2hZ2yVwDg/PVpNjWw6DJZdahKlC2yNadJWurDXjpIHOpR5fCQOIm9 CBHskl03u3pnLBiB6lPNQPtz4GL/p/Jg4/x9TiXjRv5ZFI4TD4U1A4UQyno4bicu1iGi gEKZsWRYjK6Je6wRA/81Yk5PGAJi9r7CVPLbb+SUG61GmjQvApuA1R1gSrsI65TrMtj9 uXqg== X-Gm-Message-State: AGi0PuZXDh3dmCSd9Mul+Sy0OD/xNMLf1LYL5rtlrVYQ2R2fqL4jvP0R JXbJfGBijRGrEXJiwO76M3tglz9eocvZG9q1PT96Ox1Z X-Google-Smtp-Source: APiQypJ1gEfVi9/velD4Na06t0v3N/R4Bcip1mTXyXuVzZBPHPyqWkMKA8t2zx+pd7zwF/fhtYvaYPsl7SLnLLWU3vE= X-Received: by 2002:a1c:ed1a:: with SMTP id l26mr5447453wmh.175.1586960529286; Wed, 15 Apr 2020 07:22:09 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Apr 2020 07:22:08 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Wed, 15 Apr 2020 07:22:08 -0700 Message-ID: To: draft-ietf-idr-capabilities-registry-change@ietf.org, John Scudder Cc: Susan Hares , idr-chairs@ietf.org, "idr@ietf. org" Content-Type: multipart/alternative; boundary="0000000000009ee9bd05a3550acf" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-capabilities-registry-change-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 14:22:21 -0000 --0000000000009ee9bd05a3550acf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping! On February 11, 2020 at 11:31:30 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote: John: Hi! Thanks for your work on this document! I have a couple of important items that need to be addressed before moving this document forward, specifically about change control and a couple more values that should be deprecated. Please see in-line. I will wait for an update before starting the IETF LC. Thanks!! Alvaro. [Line numbers from idnits.] ... 11 Abstract 13 This document updates RFC 5492 by making a change to the registration 14 procedures for BGP Capability Codes. Specifically, the range 15 formerly designated "Reserved for Private Use" is divided into three 16 new ranges, respectively designated as "First Come First Served", 17 "Experimental" and "Reserved". [nit] s/Experimental/Experimental Use ... 63 1. Introduction 65 [RFC5492] designates the range of Capability Codes 128-255 as 66 "Reserved for Private Use". Subsequent experience has shown this to 67 be not only useless, but actively confusing to implementors. BGP 68 Capability Codes do not meet the criteria for "Private Use" described 69 in [RFC8126] section 4.1. An example of a legitimate "private use" 70 code point might be a BGP community [RFC1997] value assigned for use 71 within a given Autonomous System, but no analogous use of 72 Capabilities exists. [nit/potential rathole] I don=E2=80=99t see why Capabilities Advertisement = can=E2=80=99t meet the =E2=80=9Cfor private or local use only=E2=80=9D criteria in rfc812= 6. I guess we just don=E2=80=99t know of any local-only capability! ;-) Seriously, I= =E2=80=99m not going to object the justification, or strongly ask you to change it, but others in the IESG might. Suggestion: Leave just the first two sentences. ... 85 2. Discussion ... 100 The reason for designating "IESG" as the change controller for all 101 registrations is that while it should be easy to obtain a Capability 102 Code, once registered it's not a trivial matter to safely and 103 interoperably change the use of that code, and thus working group 104 consensus should be sought before changes are made to existing 105 registrations. [minor] I don=E2=80=99t think this paragraph is needed because =E2=80=9CFor= registries created by RFCs in the IETF stream, change control for the registry lies by default with the IETF, via the IESG.=E2=80=9D [rfc8126] [] I think it is confusing (at least to me) the text about =E2=80=9Cworking= group consensus=E2=80=9D if the change controller is the IESG, and we're dealing = with FCFS. Again, I don=E2=80=99t think this paragraph is needed. 107 Finally, we invite implementors who have used values in the range 108 128-255 to contribute to this draft, so that the values can be 109 included in the registry. Values that have been reported, are 110 included. [nit] The invitation is not needed, since the draft is now =E2=80=9Cdone=E2= =80=9D and the values are already included... 112 3. IANA Considerations ... 119 Registry Owner/Change Controller: IESG [] See above. 121 Registration procedures: 123 +---------+-------------------------+ 124 | Range | Registration Procedures | 125 +---------+-------------------------+ 126 | 1-63 | IETF Review | 127 | 64-238 | First Come First Served | 128 | 239-254 | Experimental | 129 +---------+-------------------------+ [minor] Please add Figure/Table numbers. 131 Note: a separate "owner" column is not provided because the owner of 132 all registrations, once made, is "IESG". [major] The IANA review (which I now notice was only sent to Sue and me), says: "Since part of the registry will be First Come First Served, we'll be adding a change controller column, per RFC 8126." [That is the full review...] "Change controller" and "owner" are the same thing; I think it would be ok to rename the "Reference" column (below) to "Reference / Change Controller". 134 IANA is requested to perform the following new allocations within the 135 "Capability Codes" registry: 137 +-------+-----------------------------------------------+-----------+ 138 | Value | Description | Reference | 139 +-------+-----------------------------------------------+-----------+ 140 | 128 | Prestandard Route Refresh (deprecated) | (this | 141 | | | document) | 142 +-------+-----------------------------------------------+-----------+ 143 | 129 | Prestandard Outbound Route Filtering | (this | 144 | | (deprecated), prestandard draft-li-idr- | document) | 145 | | flowspec-rpd-04 (deprecated) | | 146 +-------+-----------------------------------------------+-----------+ 147 | 130 | Prestandard Outbound Route Filtering | (this | 148 | | (deprecated) | document) | 149 +-------+-----------------------------------------------+-----------+ 150 | 255 | Reserved | (this | 151 | | | document) | 152 +-------+-----------------------------------------------+-----------+ [major] There is mention in the mail archive of other values that should also be deprecated [1]. - "131 (CISCO multi-session)" - "184, cumulus hostname draft" - "185, operational draft" [1] https://mailarchive.ietf.org/arch/msg/idr/eIoTAz3wS6dJMKBoIxwrAk98lxM --0000000000009ee9bd05a3550acf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ping!

On Febru= ary 11, 2020 at 11:31:30 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

John:

Hi!=C2=A0 Thanks for your work on this document!

I have a couple of important items that need to be addressed before mov= ing this document forward, specifically about change control and a couple m= ore values that should be deprecated.=C2=A0 Please see in-line.

I will wait for an update before starting the IETF LC.

Thanks!!

Alvaro.



[Line numbers from idnits.]


...
11 =C2=A0 =C2=A0Abstract

13 =C2=A0 =C2=A0 =C2=A0 This document updates RFC 5492 by making a chan= ge to the registration
14 =C2=A0 =C2=A0 =C2=A0 procedures for BGP Capability Codes.=C2=A0 Spec= ifically, the range
15 =C2=A0 =C2=A0 =C2=A0 formerly designated "Reserved for Private = Use" is divided into three
16 =C2=A0 =C2=A0 =C2=A0 new ranges, respectively designated as "Fi= rst Come First Served",
17 =C2=A0 =C2=A0 =C2=A0 "Experimental" and "Reserved&quo= t;.

[nit] s/Experimental/Experimental Use


...
63 =C2=A0 =C2=A01.=C2=A0 Introduction

65 =C2=A0 =C2=A0 =C2=A0 [RFC5492] designates the range of Capability Co= des 128-255 as
66 =C2=A0 =C2=A0 =C2=A0 "Reserved for Private Use".=C2=A0 Sub= sequent experience has shown this to
67 =C2=A0 =C2=A0 =C2=A0 be not only useless, but actively confusing to = implementors.=C2=A0 BGP
68 =C2=A0 =C2=A0 =C2=A0 Capability Codes do not meet the criteria for &= quot;Private Use" described
69 =C2=A0 =C2=A0 =C2=A0 in [RFC8126] section 4.1.=C2=A0 An example of a= legitimate "private use"
70 =C2=A0 =C2=A0 =C2=A0 code point might be a BGP community [RFC1997] v= alue assigned for use
71 =C2=A0 =C2=A0 =C2=A0 within a given Autonomous System, but no analog= ous use of
72 =C2=A0 =C2=A0 =C2=A0 Capabilities exists.

[nit/potential rathole] I don=E2=80=99t see why Capabilities Advertisem= ent can=E2=80=99t meet the =E2=80=9Cfor private or local use only=E2=80=9D = criteria in rfc8126.=C2=A0 I guess we just don=E2=80=99t know of any local-= only capability! =C2=A0;-) =C2=A0 Seriously, I=E2=80=99m not going to objec= t the justification, or strongly ask you to change it, but others in the IE= SG might.=C2=A0 Suggestion: Leave just the first two sentences.


...
85 =C2=A0 =C2=A02.=C2=A0 Discussion
...
100 =C2=A0 =C2=A0 =C2=A0 The reason for designating "IESG" as= the change controller for all
101 =C2=A0 =C2=A0 =C2=A0 registrations is that while it should be easy = to obtain a Capability
102 =C2=A0 =C2=A0 =C2=A0 Code, once registered it's not a trivial m= atter to safely and
103 =C2=A0 =C2=A0 =C2=A0 interoperably change the use of that code, and= thus working group
104 =C2=A0 =C2=A0 =C2=A0 consensus should be sought before changes are = made to existing
105 =C2=A0 =C2=A0 =C2=A0 registrations.

[minor] I don=E2=80=99t think this paragraph is needed because =E2=80= =9CFor registries created by RFCs in the IETF stream, change control for th= e registry lies by default with the IETF, via the IESG.=E2=80=9D [rfc8126]

[] I think it is confusing (at least to me) the text about =E2=80=9Cwor= king group consensus=E2=80=9D if the change controller is the IESG, and we&= #39;re dealing with FCFS.=C2=A0 Again, I don=E2=80=99t think this paragraph= is needed.


107 =C2=A0 =C2=A0 =C2=A0 Finally, we invite implementors who have used = values in the range
108 =C2=A0 =C2=A0 =C2=A0 128-255 to contribute to this draft, so that t= he values can be
109 =C2=A0 =C2=A0 =C2=A0 included in the registry.=C2=A0 Values that ha= ve been reported, are
110 =C2=A0 =C2=A0 =C2=A0 included.

[nit] The invitation is not needed, since the draft is now =E2=80=9Cdon= e=E2=80=9D and the values are already included...


112 =C2=A0 =C2=A03.=C2=A0 IANA Considerations
...
119 =C2=A0 =C2=A0 =C2=A0 Registry Owner/Change Controller: IESG

[] See above.

121 =C2=A0 =C2=A0 =C2=A0 Registration procedures:

123 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +---------+-------------------------+
124 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0Range =C2=A0| Registration Procedures |
125 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +---------+-------------------------+
126 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 1-63 =C2=A0| IETF Review =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
127 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A064-238 | First Come First Served |
128 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | 239-254 | Experimental =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
129 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +---------+-------------------------+

[minor] Please add Figure/Table numbers.

131 =C2=A0 =C2=A0 =C2=A0 Note: a separate "owner" column is n= ot provided because the owner of
132 =C2=A0 =C2=A0 =C2=A0 all registrations, once made, is "IESG&qu= ot;.

[major] The IANA review (which I now notice was only sent to Sue and me= ), says: "Since part of the registry will be First Come First Served, = we'll be adding a change controller column, per RFC 8126." [That i= s the full review...] =C2=A0"Change controller" and "owner&q= uot; are the same thing; I think it would be ok to rename the "Referen= ce" column (below) to "Reference / Change Controller".

134 =C2=A0 =C2=A0 =C2=A0 IANA is requested to perform the following new= allocations within the
135 =C2=A0 =C2=A0 =C2=A0 "Capability Codes" registry:

137 =C2=A0 =C2=A0 =C2=A0 +-------+-------------------------------------= ----------+-----------+
138 =C2=A0 =C2=A0 =C2=A0 | Value | Description =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | Reference |
139 =C2=A0 =C2=A0 =C2=A0 +-------+-------------------------------------= ----------+-----------+
140 =C2=A0 =C2=A0 =C2=A0 | =C2=A0128 =C2=A0| Prestandard Route Refresh = (deprecated) =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 |
141 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | docume= nt) |
142 =C2=A0 =C2=A0 =C2=A0 +-------+-------------------------------------= ----------+-----------+
143 =C2=A0 =C2=A0 =C2=A0 | =C2=A0129 =C2=A0| Prestandard Outbound Route= Filtering =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 |
144 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | (deprecated), prestan= dard draft-li-idr- =C2=A0 =C2=A0 =C2=A0 | document) |
145 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | flowspec-rpd-04 (depr= ecated) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
146 =C2=A0 =C2=A0 =C2=A0 +-------+-------------------------------------= ----------+-----------+
147 =C2=A0 =C2=A0 =C2=A0 | =C2=A0130 =C2=A0| Prestandard Outbound Route= Filtering =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 |
148 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | (deprecated) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| document) |
149 =C2=A0 =C2=A0 =C2=A0 +-------+-------------------------------------= ----------+-----------+
150 =C2=A0 =C2=A0 =C2=A0 | =C2=A0255 =C2=A0| Reserved =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 |
151 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | docume= nt) |
152 =C2=A0 =C2=A0 =C2=A0 +-------+-------------------------------------= ----------+-----------+

[major] There is mention in the mail archive of other values that shoul= d also be deprecated [1].

- "131 (CISCO multi-session)"
- "184, cumulus hostname draft"
- "185, operational draft"

[1] https://mailarchive.ietf.org/arch/msg/idr/eIoTAz3wS6dJMKBoIx= wrAk98lxM



<= /body> --0000000000009ee9bd05a3550acf-- From nobody Wed Apr 15 09:36:07 2020 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 C53113A0CDA; Wed, 15 Apr 2020 09:36:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: idr@ietf.org, last-call@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158696856575.24074.9062191460091207808@ietfa.amsl.com> Reply-To: Ines Robles Date: Wed, 15 Apr 2020 09:36:05 -0700 Archived-At: Subject: [Idr] Rtgdir telechat review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 16:36:06 -0000 Reviewer: Ines Robles Review result: Has Nits Review type: rtgdir - Telechat review Requested version for review: 20 Deadline: 2020-04-15 Reviewer: Ines Robles Summary: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. It also specifies BGP Extended Community encoding formats. This document obsoletes both RFC5575 and RFC7674. I found the document clear and complete. Some minor nits are detailed below. Major issues: Not found Minor issues: Not found Nits: 1- In the Introduction, it would be nice to mention how this draft obsoletes RFC7674 and point to appendix B when referring obsoleting RFC5575. For example, This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], whose differences can be found in Appendix B. This document obsoletes also "Clarification of the Flowspec Redirect Extended Community"[RFC7674] due to this document includes..... - please expand iBGP --> Internal BGP (iBGP) 2- Section 4.2.1.1 in "a - AND bit:..." 2.1 - "the previous term" refers to a component? 2.2 -nit: "...unset and and MUST..." => "...unset and MUST..." 3-nit Section 5: "...this draft specifies..." if it becomes RFC it would be nice to read "..this document specifies.." Thanks for this document, Ines. From nobody Wed Apr 15 09:38:44 2020 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 5E9EF3A0CDB for ; Wed, 15 Apr 2020 09:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans-eu.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 wCFXJIgpp2kv for ; Wed, 15 Apr 2020 09:38:39 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 E7B463A0CDA for ; Wed, 15 Apr 2020 09:38:38 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id z6so342671wml.2 for ; Wed, 15 Apr 2020 09:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MjjRZP91JyAUxLS4psW3aSW+mpXtaJKw3Fp3mxHd5lw=; b=1XagwS5VXwlbC9NYdQG+GMCJlMXGEW5k9MvJZGQ0LYNo9kGELgdJPgoZblWxtgZRih afxob9b2guGgKh3o3iCZh33ikTTsentinN5Je7cekvk735xBhq3bR85Y7J36rUFN4+LQ yN2Wt66qUjY24IQkHps7CdekFaYw+DY+oDVw1TFDAjMxuqN4E6lTI+jDrVbY5xSlIGr1 XD5L6atxEFMLeM4cTz9gxRGTOu0/SsDRclqtzehjk0IOC6K4OF/lp5kie2OATpy1/G6M KHTbu9GrAXabd56qtoGah2rLdRBVs9Vavz1jTh3eT3XDsov6J+kNnaIwj/G8uL4g2bCv CoEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MjjRZP91JyAUxLS4psW3aSW+mpXtaJKw3Fp3mxHd5lw=; b=qb9j5AmHgUYKN9uNbRx9wHCsYLWzry9nks2QOR3jsgpdChLWZMEfdgGBn5Ut6GYCbs KryqH4bmo3JsK2udsTL5ggysBkcmLTkayQ7jsDwEQaC5o1ei2j0IgKqukcaUSzS5D0i8 TKEJ3HTd08586LV3I/PpyIJA3Fq/BpGXt542H8x+ec2MV25Jts+PqlP6u2t/HhM3ni92 GXwQKSIK8w1RSi6CmMx10KVIye8krjv77wASQoUBVtbDi98jKvsLHKT8jS93zbR/GSHh K29zb8jjhEiIoEtvQL/TUlGfT5dP2wLW+caYXhBbGtPuqmm6w+nLnxBkUqxu8p39QGyc +DHQ== X-Gm-Message-State: AGi0PuaiYxU8emNWtNhsQ/b67XtKOIpmyW5M7Vuxnht2VOhyXdQADNwv DMHX7AFoQER+dTnkswXVjSWmNguIwVlauZj+bmuzyPMhkS4CLA== X-Google-Smtp-Source: APiQypKUNcJ+faxOjzQ7mQJJ1Fc6DZod5kvwj5+aNtCoOjJPEH2K3eOQr5qrv4jwP0ca9HGENeSChAdtw4cVEwDwU38= X-Received: by 2002:a1c:5446:: with SMTP id p6mr84938wmi.172.1586968713801; Wed, 15 Apr 2020 09:38:33 -0700 (PDT) MIME-Version: 1.0 References: <158696818303.6243.5174235982641457432@ietfa.amsl.com> In-Reply-To: <158696818303.6243.5174235982641457432@ietfa.amsl.com> From: Melchior Aelmans Date: Wed, 15 Apr 2020 18:38:23 +0200 Message-ID: To: idr Content-Type: multipart/alternative; boundary="00000000000074c94305a356f20d" Archived-At: Subject: [Idr] Fwd: I-D Action: draft-sas-idr-maxprefix-inbound-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 16:38:42 -0000 --00000000000074c94305a356f20d Content-Type: text/plain; charset="UTF-8" Hi IDR, After feedback in GROW, both on the list and during the last IETF meetings, a few things happened; - John and Susan suggested to submit the draft in IDR instead of GROW so here it is. - We decided to split inbound and outbound, hereby you find inbound. We will submit 'outbound' later as well. - We've received very constructive feedback from Susan which should be incorporated now. Looking forward to your comments and feedback. Thanks! Melchior ---------- Forwarded message --------- From: Date: Wed, Apr 15, 2020 at 6:30 PM Subject: I-D Action: draft-sas-idr-maxprefix-inbound-00.txt To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Maximum Prefix Limits Inbound Authors : Job Snijders Melchior Aelmans Massimiliano Stucchi Filename : draft-sas-idr-maxprefix-inbound-00.txt Pages : 8 Date : 2020-04-15 Abstract: This document describes mechanisms to limit the negative impact of route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271] implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sas-idr-maxprefix-inbound/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-sas-idr-maxprefix-inbound-00 https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --00000000000074c94305a356f20d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi IDR,

After feedback in GROW, both on= the list and during the last IETF meetings, a few things happened;
- John and Susan suggested to submit the draft in IDR instead of GROW so= =C2=A0here it is.
- We decided to split=C2=A0inbound and outbound= , hereby you find inbound. We will submit 'outbound' later as well.=
- We've received very constructive feedback from Susan which= should be incorporated=C2=A0now.

Looking forward = to your comments and=C2=A0feedback.

Thanks!
Mel= chior

---------- Forwarded message ---------
From: <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org>
Date: Wed, Apr 15, 2020 at 6:30 PM
Subject:= I-D Action: draft-sas-idr-maxprefix-inbound-00.txt
To: <i-d-announce@ietf.org&g= t;



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= BGP Maximum Prefix Limits Inbound
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Job = Snijders
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Melchior Aelmans
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Massimiliano Stucchi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-sas= -idr-maxprefix-inbound-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-04-15

Abstract:
=C2=A0 =C2=A0This document describes mechanisms to limit the negative impac= t of
=C2=A0 =C2=A0route leaks [RFC7908] and/or resource exhaustion in BGP [RFC42= 71]
=C2=A0 =C2=A0implementations.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-sas-idr-maxprefix-inbound/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-sas-= idr-maxprefix-inbound-00
https://datatracker.ietf.org= /doc/html/draft-sas-idr-maxprefix-inbound-00


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/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Sorry about the typo in the Draft name sp= ecified was incorrect.

Doc= ument: draft-ietf-rmcat-wireless-tests-08=C2=A0 - should be=C2=A0 "dra= ft-ietf-idr-rfc5575bis-20"=C2=A0=C2=A0

Kind reg= ards

Gyan

On Wed, Apr 8, 2020 at 3:36 AM Chri= stoph Loibl <c@tix.at> wrote:
Hi Gyan,

Thanks for the review. I wil= l collect the results of all reviews and comment on those later. I need to = note that the reviewed document is draft-ietf-idr-rfc5575bis-20 not rmcat-w= ireless-tests ;-) :

On 07.04.2020, at 23:43, = Gyan Mishra via Datatracker <noreply@ietf.org> wrote:

Document:= draft-ietf-rmcat-wireless-tests-08
Reviewer: Gyan Mishra
Review Date: 2020-04-7=
IETF LC End = Date: 2020-04-8
IESG Telechat date: Not scheduled for a telechat
Thanks,

Christoph
--=C2=A0
Christoph Loibl
c@tix.at=C2=A0| CL8-RIPE | PGP-Key-ID:=C2=A00x4B2C00= 55 |=C2=A0http://www.= nextlayer.at





--

Gyan=C2=A0 Mishra

Network Engineering = & Technology=C2=A0

Verizon=C2=A0

Silv= er Spring, MD 20904

Phone: 301 502-1347

E= mail: gyan.s= .mishra@verizon.com