From nobody Sat Feb 1 08:46:38 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D64120144 for ; Sat, 1 Feb 2020 08:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 8iWLwfZt3DAG for ; Sat, 1 Feb 2020 08:46:34 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 CEA461200E5 for ; Sat, 1 Feb 2020 08:46:33 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id c23so6922368lfi.7 for ; Sat, 01 Feb 2020 08:46:33 -0800 (PST) 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=TxWRFT75yAuBRogS5S+8oF8oH+dTo9yUtFqUlGeRqYk=; b=VH5eRO0NzWzOQ22gk/4+3zQnEvxXZnYP7QKTwZpQ8bxfWGFeg8RnjTUzOoOb3ZYVTV wRpPilD3wN0DfLY/h+aNpDmPRTFuPqvudar4mBDz0MLnf7jL+2fC59cvUCyuc3YeBsCl NGwqW8HUxjRLu1RHee9+emC9pZfQDQr5zt4gEBJMS2HuYicF4EFcEYBasup2ph9xQ28E HGXc249YjyGCi6mjKIaM11cZSqXNjOlyk4Opi1nq0HXJVwM7AUOsfMubZDyO1JkpCpKC yGDTB4/rB/oQYmjlPsLjRaFKzNndfQx4q/Rm/wajnXULpp6Hw1ogqdXYMREEV/q/qwCa 4u3A== 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=TxWRFT75yAuBRogS5S+8oF8oH+dTo9yUtFqUlGeRqYk=; b=eVOl4YvagIZB9AEJP6LdgkKeULJMBZ/SfjgH/ngPjych8by3rNCOCiWjMwqmuYL3pI 3RWxqNncSehpRKZvEe940Odal1VIn6mW3FX+LWrvkqGTOTV2rMex0VkvH2/bCPuLE1X6 iRwuGpyUPPz5iHP1IYzfwkJPqs+8SIz+iViRnf3CDWnl+C2o9JDPj6Eu42VEOEpdgpyK Ltwl2MYONUtTCdi916EfBxN3mMMz2yIzqJR8z06YJeaBQvkorfh0SbImhkcJzmfa5XAB Y1BrK4fvr+/e/kxpo5dwpuyysxwv/e5Jvnx1EF3PfdEJvlCh8qoQLBR6nFnBvCrXPUmy lZxA== X-Gm-Message-State: APjAAAUpbfanTuvvwXHX4nSy1xYc1fjjBr91XO8A5wcuO/90/wWq6BTL RBDG/3XhuKZHR9VSvGVcIbgBiZWgtd71nBgF1A== X-Google-Smtp-Source: APXvYqysffgPoiJgDcF6xF/Q/akrzSiJ/7IzK6oJu40002QFm2Sy0+YJLk2nnFeEshoDKZTzTwZYfb+FOPZXKMlHGN0= X-Received: by 2002:a19:5503:: with SMTP id n3mr8061491lfe.136.1580575591953; Sat, 01 Feb 2020 08:46:31 -0800 (PST) MIME-Version: 1.0 References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> In-Reply-To: From: Rakesh Gandhi Date: Sat, 1 Feb 2020 11:46:18 -0500 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: Dhruv Dhody , "pce@ietf.org" , Farrel Adrian Content-Type: multipart/alternative; boundary="000000000000b2f934059d866ed1" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 16:46:37 -0000 --000000000000b2f934059d866ed1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Andrew. Adding Adrian who had a similar comment in a different thread. Hi Dhruv, Cheng, For all other association types (VN, Policy, diversity, etc.), we do not have different types defined for RSVP and SR. If we use the same association type and limit the LSPs to be the same type (PST) in the bidirectional LSP, then may be implementation can handle the logic for the PST type accordingly? As IANA allocation has not been done, current implementation can be adjusted? Thanks, Rakesh On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) < andrew.stone@nokia.com> wrote: > Hi Rakesh, > > Thanks for the reply and input. I initially had the same thought as well: > "just migrate both sides at the same time". Only concern is of course som= e > migration strategies choose to migrate regionally or node-by-node, rather > than tunnel pairs. In this case, definitely will have to do both sides at > the same time. It may not actually be that troublesome, since I'm not an > operator just going by what I've heard from colleagues and theorizing the > situation. > > Cheers > Andrew > > ------------------------------ > *From:* Rakesh Gandhi > *Sent:* Thursday, January 23, 2020 11:12 AM > *To:* Stone, Andrew (Nokia - CA/Ottawa) > *Cc:* Dhruv Dhody ; pce@ietf.org > *Subject:* Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > > Hi Andrew, > > Many thanks for your review comments. Please see below with .. > > On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) < > andrew.stone@nokia.com> wrote: > > Hi Dhruv, > > Thanks again for the speedy reply. Comments below under > > Cheers > Andrew > > =EF=BB=BFOn 2020-01-22, 8:01 AM, "Dhruv Dhody" wro= te: > > Hi Andrew, > > On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa) > wrote: > > > > Hi Dhruv, > > > > Thanks for the reply and feedback. > > > > Could an implementation of PCE not simply just return error during > that situation? In diversity if too many LSPs grouped together and PCE > computationally can't support it, it returns a PCERR. So I would reason > that if bidirectionally associated and notify PCCs is necessary, but was > configured between SR and RSVP, that's also an error due to the (current) > unsupported feature set. I see this as trying to protect against day-0 > misconfig by changing the wire encoding within the protocol (which I'm no= t > necessarily against..). While I have doubt if it's a valid use case or > requirement in a production deployment, and it may have been acknowledged > before, but this essentially blocks associating SR LSP with RSVP LSP > bidirectionally for PCE to compute. > > > > Since the overall workflow doesn't change by this new type def, and > if SR<->RSVP associated is not reasonable requirement, and If consensus h= as > already been reached on this, and implementation already exist, I'm okay > with parking this topic. > > > > The SR draft does expect all LSPs to be SR for the new association > type and thus easier to handle. If you use a common association type, > the behavior would be dependent on the PST for the first LSP that is > added to the association. We could end up in a situation where Peer 1 > would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 woul= d > add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be = a > use for this mixed cases in future, which would require different > processing to be defined. > > > > > I will ponder on this some more. I'm undecided yet if the reasons to > protect config/behaviour mismatch, outweigh just having one type encoding > and defining the individual behaviours separately, which could also be up > to the local policy defined by the PCE implementation. > > It could be possible that a network has nodes currently running RSVP, wit= h > plans to migrate to SR-TE which could take a very long time due to the si= ze > of the network. The software running on the nodes may be upgraded, of whi= ch > those PCCs may have an implementation of these bidirectional drafts, but > have still not yet migrated to SR-TE. An operator may wish to leverage PC= E > feature sets on newer created services sooner than later (for example, > bidirectional capability) so they begin using bidirectional RSVP to have > symmetric paths for SLA reasons and aid in avoiding manual traffic > engineering. Over time, as the network is migrated to SR-TE tunnels you > have some nodes using SR-TE tunnels and the reverse nodes still operating > with RSVP. From an operator p.o.v the bidirectional notification behaviou= r > here wouldn't matter, they just want the LSPs to take the same resources > symmetrically. The feature set on PCE, as per the current draft wording a= nd > types will be broken. > > > > > > I would think that the migration would happen for the whole > bidirectional LSP on both endpoints at the same time. This is because, al= l > nodes would have migrated to be SR aware in order for the forward path to > be SR path (I am thinking co-routed). In addition, the complexity to > associate the SR and RSVP paths into a bidirectional path is not small, > given that SR path ingress node would know the reverse path via signaling > whereas RSVP path ingress node would know via PCEP. Which also means, on= e > would need to upgrade the RSVP ingress node anyways to learn the reverse = SR > path. Traffic steering and other functions for the RSVP path and SR path = in > the reverse direction (and vice versa) may bring additional work. > > Having said that, the same association group type can be used for S= R > and RSVP paths (e.g. both are the same PST) in theory, but given the > implementation status in the draft, I will let respective co-authors > comment. > > > > > > > Still hoping for feedback regarding my comments on section 5. I see > that as being more significant, since it influences the workflow and at t= he > moment I don't see the dependency on draft-li-pce-controlled-id-space as > necessary to achieve notifying PCCs of reverse paths. > > > > And I was hoping that authors would take a bite :) > From what I understood PLSP-ID remains a PCC allocated ID. The point > that section 5 is making is that the same LSP would be identified by > two PLSP-IDs, one allocated by Ingress and another by Egress PCCs. > There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R bit > is enough (as you state) and I am in full agreement with you that > figures with PLSP-ID could be useful. > > > > > > > Thanks for the comments and agreement. draft-li-pce-sr-bidir-path-06 > section 5.1, says "PCE needs to allocate a PLSP-ID". Perhaps it was just = a > typo and should have said PCC. > > =3D=3D=3Dcurrent > Since the PLSP-ID space is independent at each PCC, the PLSP-ID > allocated by the egress PCC can not be used for the LSP at the > ingress PCC (PLSP-ID conflict may occur). Hence, the PCE needs to > allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space , > say 101. Similarly for LSP1, it has PLSP-ID 100 at the ingress, and > may have say PLSP-ID 201 at the egress node. > =3D=3D=3D=3D=3Dend current > > > May I propose the following text (or something like it) instead: > > > =3D=3D=3Dnew proposal > > Since the PLSP-ID space is independent at each PCC, the PLSP-ID > allocated by the egress PCC cannot be used for the LSP at the > ingress PCC (PLSP-ID conflict may occur). As per normal PCE-INIT > operations, PCC assigns the PLSP-IDs for local LSPs. > Hence, when the PCE notifies an ingress PCC of the reverse egress LSP, > it > does so using PCE-INIT operations and sets PLSP-ID to zero and sets th= e > R bit in the association > object to indicate that this PCE-INIT LSP is a reverse LSP. The PCC > upon receiving the PCE-INIT MUST locally assign a PLSP-ID and it MUST > issue a PCREPORT to PCE for this LSP containing the new PLSP-ID. This > LSP MUST NOT be instantiated on the PCC. > > For example, ingress PCC1 way may report to PCE an LSP with > PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID 200. > Both of these LSPs are bi-directional associated. When PCE > notifies PCC1 of the PCC2 LSP, it does so by sending a PCE-INIT to PCC= 1 > with > PLSP-ID set to zero and R bit set. PCC1 upon reception of this > generates a PLSP-ID > (example PLSP-ID 300) and issues a PCREPORT to PCE. > > =3D=3D=3D=3D=3Dend new proposal > > > Looks good to me. Thanks for the text. > Many thanks Dhruv for the inputs. > > Thanks, > Rakesh > > > > > > > > > > > --000000000000b2f934059d866ed1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Andrew.
Adding Adrian who had a similar comment in a = different thread.

Hi Dhruv, Cheng,

For all other association types (VN, Policy, diversity, e= tc.), we do not have different types defined for RSVP and SR. If we use the= same association type and limit the LSPs to be the same type (PST) in the = bidirectional LSP, then may be implementation can handle the logic for the = PST type accordingly? As IANA allocation has not been done, current impleme= ntation can be adjusted?

Thanks,
Rakesh<= /div>

= On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com> wrote:<= br>
Hi Rakesh,

Thanks for the reply and input. I initially had the same thought as well: &= quot;just migrate both sides at the same time". Only concern is of cou= rse some migration strategies choose to migrate regionally or node-by-node,= rather than tunnel pairs. In this case, definitely will have to do both sides at the same time. It may not actually be that t= roublesome, since I'm not an operator just going by what I've heard= from colleagues and theorizing the situation.

Cheers
Andrew

From= : Rakesh Gandhi <rgandhi.ietf@gmail.com>
Sent: Thursday, January 23, 2020 11:12 AM
To: Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>; pce@ietf.org <pce@ietf.org>
Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
=C2=A0
Hi Andrew,

Many thanks for your review comments. Please see below with <RG2>= ;..

On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA= /Ottawa) <an= drew.stone@nokia.com> wrote:
Hi Dhruv,

Thanks again for the speedy reply. Comments below under <andrew2>

Cheers
Andrew

=EF=BB=BFOn 2020-01-22, 8:01 AM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wr= ote:

=C2=A0 =C2=A0 Hi Andrew,

=C2=A0 =C2=A0 On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ot= tawa)
=C2=A0 =C2=A0 <andrew.stone@nokia.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Dhruv,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks for the reply and feedback.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Could an implementation of PCE not simply just return er= ror during that situation? In diversity if too many LSPs grouped together a= nd PCE computationally can't support it, it returns a PCERR. So I would= reason that if bidirectionally associated and notify PCCs is necessary, but was configured between SR and RSVP, that's also= an error due to the (current) unsupported feature set. I see this as tryin= g to protect against day-0 misconfig by changing the wire encoding within t= he protocol (which I'm not necessarily against..). While I have doubt if it's a valid use case or requirement= in a production deployment, and it may have been acknowledged before, but = this essentially blocks associating SR LSP with RSVP LSP bidirectionally fo= r PCE to compute.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Since the overall workflow doesn't change by this ne= w type def, and if SR<->RSVP associated is not reasonable requirement= , and If consensus has already been reached on this, and implementation alr= eady exist, I'm okay with parking this topic.
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 The SR draft does expect all LSPs to be SR for the new associ= ation
=C2=A0 =C2=A0 type and thus easier to handle. If you use a common associati= on type,
=C2=A0 =C2=A0 the behavior would be dependent on the PST for the first LSP = that is
=C2=A0 =C2=A0 added to the association. We could end up in a situation wher= e Peer 1
=C2=A0 =C2=A0 would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and pee= r 2 would
=C2=A0 =C2=A0 add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there m= ight be a
=C2=A0 =C2=A0 use for this mixed cases in future, which would require diffe= rent
=C2=A0 =C2=A0 processing to be defined.


<Andrew2>

I will ponder on this some more. I'm undecided yet if the reasons to pr= otect config/behaviour mismatch, outweigh just having one type encoding and= defining the individual behaviours separately, which could also be up to t= he local policy defined by the PCE implementation.

It could be possible that a network has nodes currently running RSVP, with = plans to migrate to SR-TE which could take a very long time due to the size= of the network. The software running on the nodes may be upgraded, of whic= h those PCCs may have an implementation of these bidirectional drafts, but have still not yet migrated to SR-TE. A= n operator may wish to leverage PCE feature sets on newer created services = sooner than later (for example, bidirectional capability) so they begin usi= ng bidirectional RSVP to have symmetric paths for SLA reasons and aid in avoiding manual traffic engineering. Over= time, as the network is migrated to SR-TE tunnels you have some nodes usin= g SR-TE tunnels and the reverse nodes still operating with RSVP. From an op= erator p.o.v the bidirectional notification behaviour here wouldn't matter, they just want the LSPs to take the sa= me resources symmetrically. The feature set on PCE, as per the current draf= t wording and types will be broken.

</end andrew2>


<RG2> I would think that the migration would happen for the whol= e bidirectional LSP on both endpoints at the same time. This is because, al= l nodes would have migrated to be SR aware in order for the forward path to= be SR path (I am thinking co-routed). In addition, the complexity to associate the SR and RSVP paths into a bidi= rectional path is not small, given that SR path ingress node would know the= reverse path via signaling whereas RSVP path ingress node would know via P= CEP.=C2=A0 Which also means, one would need to upgrade the RSVP ingress node anyways to learn the reverse SR path= . Traffic steering and other functions for the RSVP path and SR path in the= reverse direction (and vice versa) may bring additional work.

<RG2> Having said that, the same association group type can be u= sed for SR and RSVP paths (e.g. both are the same PST) in theory, but given= the implementation status in the draft, I will let respective co-authors c= omment.

=C2=A0


=C2=A0 =C2=A0 > Still hoping for feedback regarding my comments on secti= on 5. I see that as being more significant, since it influences the workflo= w and at the moment I don't see the dependency on draft-li-pce-controll= ed-id-space as necessary to achieve notifying PCCs of reverse paths.
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 And I was hoping that authors would take a bite :)
=C2=A0 =C2=A0 From what I understood PLSP-ID remains a PCC allocated ID. Th= e point
=C2=A0 =C2=A0 that section 5 is making is that the same LSP would be identi= fied by
=C2=A0 =C2=A0 two PLSP-IDs, one allocated by Ingress and another by Egress = PCCs.
=C2=A0 =C2=A0 There is no proposal for PCE-controlled PLSP-ID. So PCE-init = + R bit
=C2=A0 =C2=A0 is enough=C2=A0 (as you state) and I am in full agreement wit= h you that
=C2=A0 =C2=A0 figures with PLSP-ID could be useful.




<Andrew2>

Thanks for the comments and agreement. draft-li-pce-sr-bidir-path-06 sectio= n 5.1, says "PCE needs to allocate a PLSP-ID". Perhaps it was jus= t a typo and should have said PCC.

=3D=3D=3Dcurrent
=C2=A0 =C2=A0Since the PLSP-ID space is independent at each PCC, the PLSP-I= D
=C2=A0 =C2=A0allocated by the egress PCC can not be used for the LSP at the=
=C2=A0 =C2=A0ingress PCC (PLSP-ID conflict may occur).=C2=A0 Hence, the PCE= needs to
=C2=A0 =C2=A0allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID= space ,
=C2=A0 =C2=A0say 101.=C2=A0 Similarly for LSP1, it has PLSP-ID 100 at the i= ngress, and
=C2=A0 =C2=A0may have say PLSP-ID 201 at the egress node.
=3D=3D=3D=3D=3Dend current


May I propose the following text=C2=A0 (or something like it) instead:


=3D=3D=3Dnew proposal

=C2=A0 =C2=A0Since the PLSP-ID space is independent at each PCC, the PLSP-I= D
=C2=A0 =C2=A0allocated by the egress PCC cannot be used for the LSP at the<= br> =C2=A0 =C2=A0ingress PCC (PLSP-ID conflict may occur). As per normal PCE-IN= IT
=C2=A0 =C2=A0operations, PCC assigns the PLSP-IDs for local LSPs.
=C2=A0 =C2=A0Hence, when the PCE notifies an ingress PCC of the reverse egr= ess LSP, it
=C2=A0 =C2=A0does so using PCE-INIT operations and sets PLSP-ID to zero and= sets the R bit in the association
=C2=A0 =C2=A0object to indicate that this PCE-INIT LSP is a reverse LSP. Th= e PCC
=C2=A0 =C2=A0upon receiving the PCE-INIT MUST locally assign a PLSP-ID and = it MUST
=C2=A0 =C2=A0issue a PCREPORT to PCE for this LSP containing the new PLSP-I= D. This
=C2=A0 =C2=A0LSP MUST NOT be instantiated on the PCC.

=C2=A0 =C2=A0For example, ingress PCC1 way may report to PCE an LSP with =C2=A0 =C2=A0PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID= 200.
=C2=A0 =C2=A0Both of these LSPs are bi-directional associated. When PCE =C2=A0 =C2=A0notifies PCC1 of the PCC2 LSP, it does so by sending a PCE-INI= T to PCC1 with
=C2=A0 =C2=A0PLSP-ID set to zero and R bit set. PCC1 upon reception of this= generates a PLSP-ID
=C2=A0 =C2=A0(example PLSP-ID 300) and issues a PCREPORT to PCE.

=3D=3D=3D=3D=3Dend new proposal


<RG2> Looks good to me. Thanks for the text.
<RG2> Many thanks Dhruv for the inputs.

Thanks,
Rakesh


=C2=A0
</end andrew2>





--000000000000b2f934059d866ed1-- From nobody Sun Feb 2 12:52:50 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845F9120127 for ; Sun, 2 Feb 2020 12:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 GPOHJd1kWUjv for ; Sun, 2 Feb 2020 12:52:44 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 259A212006E for ; Sun, 2 Feb 2020 12:52:43 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 012KqeEF010917; Sun, 2 Feb 2020 20:52:40 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A1FD12203A; Sun, 2 Feb 2020 20:52:40 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 8C7EB22032; Sun, 2 Feb 2020 20:52:40 +0000 (GMT) Received: from LAPTOPK7AS653V (089144198045.atnat0007.highway.a1.net [89.144.198.45]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 012KqcOZ016282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Feb 2020 20:52:40 GMT Reply-To: From: "Adrian Farrel" To: "'Rakesh Gandhi'" , "'Stone, Andrew \(Nokia - CA/Ottawa\)'" Cc: "'Dhruv Dhody'" , References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> In-Reply-To: Date: Sun, 2 Feb 2020 20:52:38 -0000 Organization: Old Dog Consulting Message-ID: <06eb01d5da0a$b4f57150$1ee053f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06EC_01D5DA0A.B4FD87A0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQI0gUu9XpjujtRzkUKxxLPCC8TxgQE+0N/zAgsO78oByAIUHwIypYZpAlcnAtwByjkWEQK+4URdARJsfuICRM4iWQH4LJ8ypq9uwXA= X-Originating-IP: 89.144.198.45 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25208.002 X-TM-AS-Result: No--24.179-10.0-31-10 X-imss-scan-details: No--24.179-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25208.002 X-TMASE-Result: 10--24.179000-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbPVY7U3NX8Jgi+TAnPnbttj3Svk2O3oOp5c1 qCkooZMTU/yV8XxciZF0kjLu/GL7T55PkKNaIO1CSVtfn9pafRcuKWLFFZtztmsFfPqDo4B1CAW hmMa6NG153DrnZ9A6EwgoeUCsqiB7fy0Tkju8iGzuT8D5XgAswhfbPFE2GHrV9nlXGNvelBfstV FL/7XkaJABJGtmXmoO7ocP5E9P0IDTNEH87J6XrkAoPtuOD8baH3KcWQJEA/W1eX0jEQ9c6ugUr KBxousFa6sukSXPefHXNC6HGuGs1lvzhdI02TWYBi0Si9jXsY0hXHiVbGfuY4g/y3JYxGR5clLz WaoHvbgzr1NwPWUSusXr7yvfQOi8YxTYGPEp8RwvLP1C8DIeOvg/s23WPBIpaHvr9sOkYSvEOb3 Mgo89SD/ZezU2Dw+VdLgIjIlTpwZ4pkAgPeEdVudNi+0D4LmKBGwExtNOAA/t6pTq30oq0gDCXB zs8w7jlds1LPY0icQAMuWxZ7iblKkrm8GLHGyoSyH6bNPVSds9e7UvbyNKcT5rmxYrg6WH9ujae QtR93uPqQJ9fQR1znSlcg9lSmhT4rf59koGAipM0MpnLn+G9G7BSyDZmAnxtwM4Q2OYikuC6rUk 9IbB8I6KrxCsTJqEYTEgR3BWc1RfsHfe/gpJhPilM7nponT8l93RwgngsFqOIsAELqL7WGpAq14 Ss3bZueJqHV70+1hawYuswKS403ryTCfz5ry9M71h0SMVl8L+paX6bXuNYY0jIdnB7VAWVCB++i itAT6pBBSPp0P4Eza/9x+kNGH019XVRX0dnrieAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7uR0pHSpvAjrso36fXSq1w2brGmE3tEFYqzrAjR+qlQqcLTQ5sGSEp9Q== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 20:52:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06EC_01D5DA0A.B4FD87A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Rakesh, =20 It seems to me that associating an SR path in one direction with an = RSVP-TE path in the other direction is *possible* but seems unlikely in = the extreme. I would not want to take an action that made it impossible = to add this feature should someone come up with a pressing desire, but = it looks like an odd thing to specifically engineer into the solution at = this stage. =20 Of course, a way to test this would be to send an email to SPRING and = TEAS to ask this specific question. After all, the purpose of PCE is to = serve as a tool to facilitate what the people in those two WGs are = trying to do. =20 The two questions raised in the earlier threads are related to this, but = do not quite cancel each other out. 1. Do we need two different association types, one for RSVP-TE and one = for SR? 2. Is it an error if there is an attempt to associate an LSP with an SR = path? =20 Best, Adrian =20 From: Rakesh Gandhi =20 Sent: 01 February 2020 16:46 To: Stone, Andrew (Nokia - CA/Ottawa) Cc: Dhruv Dhody ; pce@ietf.org; Farrel Adrian = Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? =20 Thanks Andrew. Adding Adrian who had a similar comment in a different thread. =20 Hi Dhruv, Cheng, =20 For all other association types (VN, Policy, diversity, etc.), we do not = have different types defined for RSVP and SR. If we use the same = association type and limit the LSPs to be the same type (PST) in the = bidirectional LSP, then may be implementation can handle the logic for = the PST type accordingly? As IANA allocation has not been done, current = implementation can be adjusted? =20 Thanks, Rakesh =20 On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) = > wrote: Hi Rakesh, =20 Thanks for the reply and input. I initially had the same thought as = well: "just migrate both sides at the same time". Only concern is of = course some migration strategies choose to migrate regionally or = node-by-node, rather than tunnel pairs. In this case, definitely will = have to do both sides at the same time. It may not actually be that = troublesome, since I'm not an operator just going by what I've heard = from colleagues and theorizing the situation. =20 Cheers Andrew =20 _____ =20 From: Rakesh Gandhi > Sent: Thursday, January 23, 2020 11:12 AM To: Stone, Andrew (Nokia - CA/Ottawa) > Cc: Dhruv Dhody >; = pce@ietf.org = > Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?=20 =20 Hi Andrew, =20 Many thanks for your review comments. Please see below with .. =20 On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) = > wrote: Hi Dhruv, Thanks again for the speedy reply. Comments below under Cheers Andrew =EF=BB=BFOn 2020-01-22, 8:01 AM, "Dhruv Dhody" > wrote: Hi Andrew, On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa) > wrote: > > Hi Dhruv, > > Thanks for the reply and feedback. > > Could an implementation of PCE not simply just return error during = that situation? In diversity if too many LSPs grouped together and PCE = computationally can't support it, it returns a PCERR. So I would reason = that if bidirectionally associated and notify PCCs is necessary, but was = configured between SR and RSVP, that's also an error due to the = (current) unsupported feature set. I see this as trying to protect = against day-0 misconfig by changing the wire encoding within the = protocol (which I'm not necessarily against..). While I have doubt if = it's a valid use case or requirement in a production deployment, and it = may have been acknowledged before, but this essentially blocks = associating SR LSP with RSVP LSP bidirectionally for PCE to compute. > > Since the overall workflow doesn't change by this new type def, = and if SR<->RSVP associated is not reasonable requirement, and If = consensus has already been reached on this, and implementation already = exist, I'm okay with parking this topic. > The SR draft does expect all LSPs to be SR for the new association type and thus easier to handle. If you use a common association = type, the behavior would be dependent on the PST for the first LSP that is added to the association. We could end up in a situation where Peer = 1 would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 = would add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be = a use for this mixed cases in future, which would require different processing to be defined. =20 I will ponder on this some more. I'm undecided yet if the reasons to = protect config/behaviour mismatch, outweigh just having one type = encoding and defining the individual behaviours separately, which could = also be up to the local policy defined by the PCE implementation.=20 It could be possible that a network has nodes currently running RSVP, = with plans to migrate to SR-TE which could take a very long time due to = the size of the network. The software running on the nodes may be = upgraded, of which those PCCs may have an implementation of these = bidirectional drafts, but have still not yet migrated to SR-TE. An = operator may wish to leverage PCE feature sets on newer created services = sooner than later (for example, bidirectional capability) so they begin = using bidirectional RSVP to have symmetric paths for SLA reasons and aid = in avoiding manual traffic engineering. Over time, as the network is = migrated to SR-TE tunnels you have some nodes using SR-TE tunnels and = the reverse nodes still operating with RSVP. From an operator p.o.v the = bidirectional notification behaviour here wouldn't matter, they just = want the LSPs to take the same resources symmetrically. The feature set = on PCE, as per the current draft wording and types will be broken.=20 =20 =20 I would think that the migration would happen for the whole = bidirectional LSP on both endpoints at the same time. This is because, = all nodes would have migrated to be SR aware in order for the forward = path to be SR path (I am thinking co-routed). In addition, the = complexity to associate the SR and RSVP paths into a bidirectional path = is not small, given that SR path ingress node would know the reverse = path via signaling whereas RSVP path ingress node would know via PCEP. = Which also means, one would need to upgrade the RSVP ingress node = anyways to learn the reverse SR path. Traffic steering and other = functions for the RSVP path and SR path in the reverse direction (and = vice versa) may bring additional work. =20 Having said that, the same association group type can be used for = SR and RSVP paths (e.g. both are the same PST) in theory, but given the = implementation status in the draft, I will let respective co-authors = comment. =20 =20 > Still hoping for feedback regarding my comments on section 5. I = see that as being more significant, since it influences the workflow and = at the moment I don't see the dependency on = draft-li-pce-controlled-id-space as necessary to achieve notifying PCCs = of reverse paths. > And I was hoping that authors would take a bite :) From what I understood PLSP-ID remains a PCC allocated ID. The point that section 5 is making is that the same LSP would be identified by two PLSP-IDs, one allocated by Ingress and another by Egress PCCs. There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R bit is enough (as you state) and I am in full agreement with you that figures with PLSP-ID could be useful. =20 Thanks for the comments and agreement. draft-li-pce-sr-bidir-path-06 = section 5.1, says "PCE needs to allocate a PLSP-ID". Perhaps it was just = a typo and should have said PCC.=20 =3D=3D=3Dcurrent Since the PLSP-ID space is independent at each PCC, the PLSP-ID allocated by the egress PCC can not be used for the LSP at the ingress PCC (PLSP-ID conflict may occur). Hence, the PCE needs to allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space , say 101. Similarly for LSP1, it has PLSP-ID 100 at the ingress, and may have say PLSP-ID 201 at the egress node. =3D=3D=3D=3D=3Dend current May I propose the following text (or something like it) instead: =3D=3D=3Dnew proposal Since the PLSP-ID space is independent at each PCC, the PLSP-ID allocated by the egress PCC cannot be used for the LSP at the ingress PCC (PLSP-ID conflict may occur). As per normal PCE-INIT=20 operations, PCC assigns the PLSP-IDs for local LSPs. Hence, when the PCE notifies an ingress PCC of the reverse egress = LSP, it does so using PCE-INIT operations and sets PLSP-ID to zero and sets = the R bit in the association=20 object to indicate that this PCE-INIT LSP is a reverse LSP. The PCC=20 upon receiving the PCE-INIT MUST locally assign a PLSP-ID and it MUST issue a PCREPORT to PCE for this LSP containing the new PLSP-ID. This = LSP MUST NOT be instantiated on the PCC.=20 For example, ingress PCC1 way may report to PCE an LSP with=20 PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID 200.=20 Both of these LSPs are bi-directional associated. When PCE=20 notifies PCC1 of the PCC2 LSP, it does so by sending a PCE-INIT to = PCC1 with=20 PLSP-ID set to zero and R bit set. PCC1 upon reception of this = generates a PLSP-ID=20 (example PLSP-ID 300) and issues a PCREPORT to PCE.=20 =3D=3D=3D=3D=3Dend new proposal =20 Looks good to me. Thanks for the text. Many thanks Dhruv for the inputs. =20 Thanks, Rakesh =20 =20 =20 ------=_NextPart_000_06EC_01D5DA0A.B4FD87A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks = Rakesh,

 

It seems to = me that associating an SR path in one direction with an RSVP-TE path in = the other direction is *possible* but seems unlikely in the = extreme. I would not want to take an action that made it impossible to = add this feature should someone come up with a pressing desire, but it = looks like an odd thing to specifically engineer into the solution at = this stage.

 

Of course, = a way to test this would be to send an email to SPRING and TEAS to ask = this specific question. After all, the purpose of PCE is to serve as a = tool to facilitate what the people in those two WGs are trying to = do.

 

The two = questions raised in the earlier threads are related to this, but do not = quite cancel each other out.

  1. Do we need two different = association types, one for RSVP-TE and one for = SR?
  2. Is it an error if there is an = attempt to associate an LSP with an SR = path?

 

Best,

Adrian

 

From: Rakesh Gandhi <rgandhi.ietf@gmail.com> =
Sent: 01 February 2020 16:46
To: Stone, Andrew = (Nokia - CA/Ottawa) <andrew.stone@nokia.com>
Cc: Dhruv = Dhody <dhruv.ietf@gmail.com>; pce@ietf.org; Farrel Adrian = <adrian@olddog.co.uk>
Subject: Re: [Pce] Adoption of = draft-li-pce-sr-bidir-path-06?

 

Thanks Andrew.

Adding Adrian who had a similar comment in a different = thread.

 

Hi Dhruv, Cheng,

 

For all other association types (VN, Policy, = diversity, etc.), we do not have different types defined for RSVP and = SR. If we use the same association type and limit the LSPs to be the = same type (PST) in the bidirectional LSP, then may be implementation can = handle the logic for the PST type accordingly? As IANA allocation has = not been done, current implementation can be = adjusted?

 

Thanks,

Rakesh

 

On = Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com> = wrote:

Hi = Rakesh,

 

=

Thanks for the reply and input. I = initially had the same thought as well: "just migrate both sides at = the same time". Only concern is of course some migration strategies = choose to migrate regionally or node-by-node, rather than tunnel pairs. = In this case, definitely will have to do both sides at the same time. It = may not actually be that troublesome, since I'm not an operator just = going by what I've heard from colleagues and theorizing the = situation.

 

=

Cheers

=

Andrew

=

 

=

From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Sent: = Thursday, January 23, 2020 11:12 AM
To: Stone, Andrew (Nokia - = CA/Ottawa) <andrew.stone@nokia.com>
Cc: Dhruv = Dhody <dhruv.ietf@gmail.com>; pce@ietf.org <pce@ietf.org>
Subject: Re: [Pce] = Adoption of draft-li-pce-sr-bidir-path-06?

 

Hi Andrew,

 

Many thanks for your review comments. Please see below = with <RG2>..

 

On = Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com> = wrote:

Hi = Dhruv,

Thanks again for the speedy reply. Comments below under = <andrew2>

Cheers
Andrew

=EF=BB=BFOn 2020-01-22, = 8:01 AM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wrote:

  =   Hi Andrew,

    On Wed, Jan 22, 2020 at 12:06 AM = Stone, Andrew (Nokia - CA/Ottawa)
    <andrew.stone@nokia.com> wrote:
    = >
    > Hi Dhruv,
    >
  =   > Thanks for the reply and feedback.
    = >
    > Could an implementation of PCE not simply = just return error during that situation? In diversity if too many LSPs = grouped together and PCE computationally can't support it, it returns a = PCERR. So I would reason that if bidirectionally associated and notify = PCCs is necessary, but was configured between SR and RSVP, that's also = an error due to the (current) unsupported feature set. I see this as = trying to protect against day-0 misconfig by changing the wire encoding = within the protocol (which I'm not necessarily against..). While I have = doubt if it's a valid use case or requirement in a production = deployment, and it may have been acknowledged before, but this = essentially blocks associating SR LSP with RSVP LSP bidirectionally for = PCE to compute.
    >
    > Since the = overall workflow doesn't change by this new type def, and if = SR<->RSVP associated is not reasonable requirement, and If = consensus has already been reached on this, and implementation already = exist, I'm okay with parking this topic.
    = >

    The SR draft does expect all LSPs to be SR for = the new association
    type and thus easier to handle. If = you use a common association type,
    the behavior would = be dependent on the PST for the first LSP that is
    added = to the association. We could end up in a situation where Peer = 1
    would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) = and peer 2 would
    add LSP 2 (RSVP-TE) first and reject = LSP 1 (SR). Also there might be a
    use for this mixed = cases in future, which would require different
    = processing to be defined.


<Andrew2>

I will = ponder on this some more. I'm undecided yet if the reasons to protect = config/behaviour mismatch, outweigh just having one type encoding and = defining the individual behaviours separately, which could also be up to = the local policy defined by the PCE implementation.

It could be = possible that a network has nodes currently running RSVP, with plans to = migrate to SR-TE which could take a very long time due to the size of = the network. The software running on the nodes may be upgraded, of which = those PCCs may have an implementation of these bidirectional drafts, but = have still not yet migrated to SR-TE. An operator may wish to leverage = PCE feature sets on newer created services sooner than later (for = example, bidirectional capability) so they begin using bidirectional = RSVP to have symmetric paths for SLA reasons and aid in avoiding manual = traffic engineering. Over time, as the network is migrated to SR-TE = tunnels you have some nodes using SR-TE tunnels and the reverse nodes = still operating with RSVP. From an operator p.o.v the bidirectional = notification behaviour here wouldn't matter, they just want the LSPs to = take the same resources symmetrically. The feature set on PCE, as per = the current draft wording and types will be broken.

</end = andrew2>

 

 

<RG2> I would think that the migration would = happen for the whole bidirectional LSP on both endpoints at the same = time. This is because, all nodes would have migrated to be SR aware in = order for the forward path to be SR path (I am thinking co-routed). In = addition, the complexity to associate the SR and RSVP paths into a = bidirectional path is not small, given that SR path ingress node would = know the reverse path via signaling whereas RSVP path ingress node would = know via PCEP.  Which also means, one would need to upgrade the = RSVP ingress node anyways to learn the reverse SR path. Traffic steering = and other functions for the RSVP path and SR path in the reverse = direction (and vice versa) may bring additional = work.

 

<RG2> Having said that, the same association = group type can be used for SR and RSVP paths (e.g. both are the same = PST) in theory, but given the implementation status in the draft, I will = let respective co-authors comment.

 

 



    > Still hoping = for feedback regarding my comments on section 5. I see that as being = more significant, since it influences the workflow and at the moment I = don't see the dependency on draft-li-pce-controlled-id-space as = necessary to achieve notifying PCCs of reverse paths.
    = >

    And I was hoping that authors would take a = bite :)
    From what I understood PLSP-ID remains a PCC = allocated ID. The point
    that section 5 is making is = that the same LSP would be identified by
    two PLSP-IDs, = one allocated by Ingress and another by Egress PCCs.
    = There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R = bit
    is enough  (as you state) and I am in full = agreement with you that
    figures with PLSP-ID could be = useful.




<Andrew2>

Thanks for the = comments and agreement. draft-li-pce-sr-bidir-path-06 section 5.1, says = "PCE needs to allocate a PLSP-ID". Perhaps it was just a typo = and should have said PCC.

=3D=3D=3Dcurrent
   Since = the PLSP-ID space is independent at each PCC, the PLSP-ID
  =  allocated by the egress PCC can not be used for the LSP at = the
   ingress PCC (PLSP-ID conflict may occur).  = Hence, the PCE needs to
   allocate a PLSP-ID for LSP2 from = the ingress PCC's PLSP-ID space ,
   say 101.  = Similarly for LSP1, it has PLSP-ID 100 at the ingress, and
  =  may have say PLSP-ID 201 at the egress node.
=3D=3D=3D=3D=3Dend = current


May I propose the following text  (or something = like it) instead:


=3D=3D=3Dnew proposal

  =  Since the PLSP-ID space is independent at each PCC, the = PLSP-ID
   allocated by the egress PCC cannot be used for = the LSP at the
   ingress PCC (PLSP-ID conflict may occur). = As per normal PCE-INIT
   operations, PCC assigns the = PLSP-IDs for local LSPs.
   Hence, when the PCE notifies an = ingress PCC of the reverse egress LSP, it
   does so using = PCE-INIT operations and sets PLSP-ID to zero and sets the R bit in the = association
   object to indicate that this PCE-INIT LSP = is a reverse LSP. The PCC
   upon receiving the PCE-INIT = MUST locally assign a PLSP-ID and it MUST
   issue a = PCREPORT to PCE for this LSP containing the new PLSP-ID. This
  =  LSP MUST NOT be instantiated on the PCC.

   For = example, ingress PCC1 way may report to PCE an LSP with
  =  PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID = 200.
   Both of these LSPs are bi-directional associated. = When PCE
   notifies PCC1 of the PCC2 LSP, it does so by = sending a PCE-INIT to PCC1 with
   PLSP-ID set to zero and = R bit set. PCC1 upon reception of this generates a PLSP-ID
  =  (example PLSP-ID 300) and issues a PCREPORT to PCE. =

=3D=3D=3D=3D=3Dend new = proposal

 

<RG2> Looks good to me. Thanks for the = text.

<RG2> Many = thanks Dhruv for the inputs.

 

Thanks,

Rakesh

 

 

 

</end = andrew2>




------=_NextPart_000_06EC_01D5DA0A.B4FD87A0-- From nobody Sun Feb 2 21:56:48 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5BC1208EB for ; Sun, 2 Feb 2020 21:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 l8B4KrOVcatf for ; Sun, 2 Feb 2020 21:56:44 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 871231208E7 for ; Sun, 2 Feb 2020 21:56:44 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id i7so11580413ilr.7 for ; Sun, 02 Feb 2020 21:56:44 -0800 (PST) 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:content-transfer-encoding; bh=T3X9qddOvLKPLwYFgi6iYBx9pBefSeEu1OWmZY8+jdI=; b=jHwgNNVAJRrA/Sms9OSKu5/bGBd7FhluCVIvju2eCLikaJmArkvhP2DqAcHV6rR0Im Zipp1nxfatyBTnRn/48fVyrZYuymmuvlxFnrAm41xQK5EDTQLkLa1nuyfD6VmSiQEcRh o8MhTLshLE7uhTYAS75eDrrMGvAIagYECiQztjXsZ5VEZGhIR80qRPdLCoJLdCxcnQee sLV0PczFqA4lINoSLXbbdqdhenLyRUvzJus4JHqBzADKoshq9tFW+Z/0SGpTOlp9kZTR FUJUS3LKzg3pkJeHKJ2FugIMR3RtDslnw0XuvqA57VqTHn7cEoIDq1HfZ/yE8dpPAV+G ejRA== 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=T3X9qddOvLKPLwYFgi6iYBx9pBefSeEu1OWmZY8+jdI=; b=bn/b1KCcjUW/aovNQxZQaNGNzQy3V5Xkhc+/eJg7hXllNIktv0FvyU0TAKkcG12Cxq Ru5BJLI8Rm4vgERif+iR2nS1ONi+xZ6eLF+clibJnLBkfG3gipkMpX5R46CAxM9t8tD/ PIa/RQCQxeQWh1fKE80N3wiY6Z1RtUsPJ96mlC8iNL/o/mvYScxolk8bi9T1Nzz5TT6y WDaCtJubIu/JND3SCxvU1X6g0u1QSwJAgjxIeXq9Ij21uvT8wJ3TfmieJrnI4GAP4IsS X+jITmUemEPSYqEbwR66hHUr7Di1WvOz+Dk6qdPM9KMSitbJjMOVV2wF/PxhvbJvq0nZ fGGw== X-Gm-Message-State: APjAAAVjYx1z6qRC3Omt7M6N1I3+S6NcN3bz1I1eKME15vMLAlDZfUiu 8Pa+LzkFuo/BKnoiwyT0s9AwHmMlbjS2ngmD3rMA+LLRLW4= X-Google-Smtp-Source: APXvYqxCOpoUrTvX9hg12u7GFx1QjEvc/yrKOMaGLGz43B4NO6O6dMBe4lq3T5fJTHFZoIdC9kMqXYoX8+kZyWUJomY= X-Received: by 2002:a92:1b51:: with SMTP id b78mr19757908ilb.14.1580709403694; Sun, 02 Feb 2020 21:56:43 -0800 (PST) MIME-Version: 1.0 References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> <06eb01d5da0a$b4f57150$1ee053f0$@olddog.co.uk> In-Reply-To: <06eb01d5da0a$b4f57150$1ee053f0$@olddog.co.uk> From: Dhruv Dhody Date: Mon, 3 Feb 2020 11:26:07 +0530 Message-ID: To: Farrel Adrian Cc: Rakesh Gandhi , "Stone, Andrew (Nokia - CA/Ottawa)" , pce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 05:56:47 -0000 Hi Adrian, Rakesh, Valid questions. I was also wondering if it would help if we generalise the association-type names - such as - Double-sided Bidirectional LSP Association Group with LSP signalling (used for RSVP-TE) Double-sided Bidirectional LSP Association Group without LSP signaling (used by SR, PCECC, some future mix case etc) or Double-sided Bidirectional LSP Association Group (used for RSVP-TE) Double-sided Bidirectional LSP Association Group with reverse direction LSP encoded in PCEP (used by SR, PCECC, some future mix cases etc) I feel this would help those early implementer that wanted to decide the processing based on configured association type rather than the PST of the first LSP that joins the association, and fits well with different bi-directional association types based on the expected processing at PCE, as well do not lead to too many association types. Thoughts? Dhruv On Mon, Feb 3, 2020 at 2:22 AM Adrian Farrel wrote: > > Thanks Rakesh, > > > > It seems to me that associating an SR path in one direction with an RSVP-= TE path in the other direction is *possible* but seems unlikely in the extr= eme. I would not want to take an action that made it impossible to add this= feature should someone come up with a pressing desire, but it looks like a= n odd thing to specifically engineer into the solution at this stage. > > > > Of course, a way to test this would be to send an email to SPRING and TEA= S to ask this specific question. After all, the purpose of PCE is to serve = as a tool to facilitate what the people in those two WGs are trying to do. > > > > The two questions raised in the earlier threads are related to this, but = do not quite cancel each other out. > > Do we need two different association types, one for RSVP-TE and one for S= R? > Is it an error if there is an attempt to associate an LSP with an SR path= ? > > > > Best, > > Adrian > > > > From: Rakesh Gandhi > Sent: 01 February 2020 16:46 > To: Stone, Andrew (Nokia - CA/Ottawa) > Cc: Dhruv Dhody ; pce@ietf.org; Farrel Adrian > Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > > > > Thanks Andrew. > > Adding Adrian who had a similar comment in a different thread. > > > > Hi Dhruv, Cheng, > > > > For all other association types (VN, Policy, diversity, etc.), we do not = have different types defined for RSVP and SR. If we use the same associatio= n type and limit the LSPs to be the same type (PST) in the bidirectional LS= P, then may be implementation can handle the logic for the PST type accordi= ngly? As IANA allocation has not been done, current implementation can be a= djusted? > > > > Thanks, > > Rakesh > > > > On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) wrote: > > Hi Rakesh, > > > > Thanks for the reply and input. I initially had the same thought as well:= "just migrate both sides at the same time". Only concern is of course some= migration strategies choose to migrate regionally or node-by-node, rather = than tunnel pairs. In this case, definitely will have to do both sides at t= he same time. It may not actually be that troublesome, since I'm not an ope= rator just going by what I've heard from colleagues and theorizing the situ= ation. > > > > Cheers > > Andrew > > > > ________________________________ > > From: Rakesh Gandhi > Sent: Thursday, January 23, 2020 11:12 AM > To: Stone, Andrew (Nokia - CA/Ottawa) > Cc: Dhruv Dhody ; pce@ietf.org > Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > > > > Hi Andrew, > > > > Many thanks for your review comments. Please see below with .. > > > > On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) wrote: > > Hi Dhruv, > > Thanks again for the speedy reply. Comments below under > > Cheers > Andrew > > =EF=BB=BFOn 2020-01-22, 8:01 AM, "Dhruv Dhody" wro= te: > > Hi Andrew, > > On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa) > wrote: > > > > Hi Dhruv, > > > > Thanks for the reply and feedback. > > > > Could an implementation of PCE not simply just return error during = that situation? In diversity if too many LSPs grouped together and PCE comp= utationally can't support it, it returns a PCERR. So I would reason that if= bidirectionally associated and notify PCCs is necessary, but was configure= d between SR and RSVP, that's also an error due to the (current) unsupporte= d feature set. I see this as trying to protect against day-0 misconfig by c= hanging the wire encoding within the protocol (which I'm not necessarily ag= ainst..). While I have doubt if it's a valid use case or requirement in a p= roduction deployment, and it may have been acknowledged before, but this es= sentially blocks associating SR LSP with RSVP LSP bidirectionally for PCE t= o compute. > > > > Since the overall workflow doesn't change by this new type def, and= if SR<->RSVP associated is not reasonable requirement, and If consensus ha= s already been reached on this, and implementation already exist, I'm okay = with parking this topic. > > > > The SR draft does expect all LSPs to be SR for the new association > type and thus easier to handle. If you use a common association type, > the behavior would be dependent on the PST for the first LSP that is > added to the association. We could end up in a situation where Peer 1 > would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 woul= d > add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be = a > use for this mixed cases in future, which would require different > processing to be defined. > > > > > I will ponder on this some more. I'm undecided yet if the reasons to prot= ect config/behaviour mismatch, outweigh just having one type encoding and d= efining the individual behaviours separately, which could also be up to the= local policy defined by the PCE implementation. > > It could be possible that a network has nodes currently running RSVP, wit= h plans to migrate to SR-TE which could take a very long time due to the si= ze of the network. The software running on the nodes may be upgraded, of wh= ich those PCCs may have an implementation of these bidirectional drafts, bu= t have still not yet migrated to SR-TE. An operator may wish to leverage PC= E feature sets on newer created services sooner than later (for example, bi= directional capability) so they begin using bidirectional RSVP to have symm= etric paths for SLA reasons and aid in avoiding manual traffic engineering.= Over time, as the network is migrated to SR-TE tunnels you have some nodes= using SR-TE tunnels and the reverse nodes still operating with RSVP. From = an operator p.o.v the bidirectional notification behaviour here wouldn't ma= tter, they just want the LSPs to take the same resources symmetrically. The= feature set on PCE, as per the current draft wording and types will be bro= ken. > > > > > > > > I would think that the migration would happen for the whole bidirec= tional LSP on both endpoints at the same time. This is because, all nodes w= ould have migrated to be SR aware in order for the forward path to be SR pa= th (I am thinking co-routed). In addition, the complexity to associate the = SR and RSVP paths into a bidirectional path is not small, given that SR pat= h ingress node would know the reverse path via signaling whereas RSVP path = ingress node would know via PCEP. Which also means, one would need to upgr= ade the RSVP ingress node anyways to learn the reverse SR path. Traffic ste= ering and other functions for the RSVP path and SR path in the reverse dire= ction (and vice versa) may bring additional work. > > > > Having said that, the same association group type can be used for S= R and RSVP paths (e.g. both are the same PST) in theory, but given the impl= ementation status in the draft, I will let respective co-authors comment. > > > > > > > > > Still hoping for feedback regarding my comments on section 5. I see= that as being more significant, since it influences the workflow and at th= e moment I don't see the dependency on draft-li-pce-controlled-id-space as = necessary to achieve notifying PCCs of reverse paths. > > > > And I was hoping that authors would take a bite :) > From what I understood PLSP-ID remains a PCC allocated ID. The point > that section 5 is making is that the same LSP would be identified by > two PLSP-IDs, one allocated by Ingress and another by Egress PCCs. > There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R bit > is enough (as you state) and I am in full agreement with you that > figures with PLSP-ID could be useful. > > > > > > > Thanks for the comments and agreement. draft-li-pce-sr-bidir-path-06 sect= ion 5.1, says "PCE needs to allocate a PLSP-ID". Perhaps it was just a typo= and should have said PCC. > > =3D=3D=3Dcurrent > Since the PLSP-ID space is independent at each PCC, the PLSP-ID > allocated by the egress PCC can not be used for the LSP at the > ingress PCC (PLSP-ID conflict may occur). Hence, the PCE needs to > allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space , > say 101. Similarly for LSP1, it has PLSP-ID 100 at the ingress, and > may have say PLSP-ID 201 at the egress node. > =3D=3D=3D=3D=3Dend current > > > May I propose the following text (or something like it) instead: > > > =3D=3D=3Dnew proposal > > Since the PLSP-ID space is independent at each PCC, the PLSP-ID > allocated by the egress PCC cannot be used for the LSP at the > ingress PCC (PLSP-ID conflict may occur). As per normal PCE-INIT > operations, PCC assigns the PLSP-IDs for local LSPs. > Hence, when the PCE notifies an ingress PCC of the reverse egress LSP,= it > does so using PCE-INIT operations and sets PLSP-ID to zero and sets th= e R bit in the association > object to indicate that this PCE-INIT LSP is a reverse LSP. The PCC > upon receiving the PCE-INIT MUST locally assign a PLSP-ID and it MUST > issue a PCREPORT to PCE for this LSP containing the new PLSP-ID. This > LSP MUST NOT be instantiated on the PCC. > > For example, ingress PCC1 way may report to PCE an LSP with > PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID 200. > Both of these LSPs are bi-directional associated. When PCE > notifies PCC1 of the PCC2 LSP, it does so by sending a PCE-INIT to PCC= 1 with > PLSP-ID set to zero and R bit set. PCC1 upon reception of this generat= es a PLSP-ID > (example PLSP-ID 300) and issues a PCREPORT to PCE. > > =3D=3D=3D=3D=3Dend new proposal > > > > Looks good to me. Thanks for the text. > > Many thanks Dhruv for the inputs. > > > > Thanks, > > Rakesh > > > > > > > > > > > > From nobody Mon Feb 3 22:16:47 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4DF120041 for ; Mon, 3 Feb 2020 22:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OndkPO-fLhJK for ; Mon, 3 Feb 2020 22:16:41 -0800 (PST) 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 D41A3120013 for ; Mon, 3 Feb 2020 22:16:35 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 02EFDFB7FA48D167A6DD; Tue, 4 Feb 2020 06:16:32 +0000 (GMT) Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 4 Feb 2020 06:16:31 +0000 Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 4 Feb 2020 06:16:31 +0000 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 4 Feb 2020 06:16:30 +0000 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.111]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0439.000; Tue, 4 Feb 2020 14:16:19 +0800 From: "Chengli (Cheng Li)" To: Dhruv Dhody , Farrel Adrian CC: "pce@ietf.org" , "Stone, Andrew (Nokia - CA/Ottawa)" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AdXbIqjy/NcVWHIsQ+GvQ9O+u9VAzg== Date: Tue, 4 Feb 2020 06:16:19 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.220.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 06:16:46 -0000 SGkgQWRyaWFuLCBSYWtlc2gsIEFuZHJldyBhbmQgRGhydXYsDQoNClNvcnJ5IGZvciBteSBkZWxh eSwgSSB3YXMgaW4gU3ByaW5nIChOb3QgdGhhdCBTUFJJTkcpIEZlc3RpdmFsIFBUTyByZWNlbnRs eSwgYW5kIG1hbnkgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9ucy4NCg0K SSB0aGluayB3ZSBoYXZlIHRoZSBjb25zZW5zdXMgYWJvdXQgd2UgbmVlZCBhbiBleHRlbnNpb24g dG8gZGVmaW5lIHRoZXNlIG5ldyBhY3Rpb25zIG9mIGFzc29jaWF0aW5nIEJpZGlyIHBhdGggd2l0 aG91dCBzaWduYWxpbmcuIFRoZSBxdWVzdGlvbiBpcyBkbyB3ZSBuZWVkIGEgbmV3IHR5cGUgb2Yg QXNzb2NpYXRpb24gZ3JvdXAgb3IgdGFrZSBhY3Rpb24gYnkgbG9va2luZyBhdCB0aGUgUFNULg0K DQpUaGVzZSBoYXZlIGJlZW4gZGlzY3Vzc2VkIGF0IHRoZSBlYXJseSBzdGFnZSBvZiB0aGlzIGRv Y3VtZW50LCBhbmQgYXQgdGhhdCB0aW1lIHdlIGNvbmNsdWRlZCB0aGF0IHVzaW5nIGEgbmV3IHR5 cGUgb2YgYXNzb2NpYXRpb24gd2lsbCBoZWxwIGluIGltcGxlbWVudGF0aW9uIGFuZCBlYXNlIG9m IHVuZGVyc3RhbmRpbmcuIERocnV2IGhhcyBleHBsYWluZWQgb25lIHN1Y2ggaXNzdWUgaW4gdGhl IHByZS1wcmV2aW91cyBlbWFpbCwgYW5kIGhvcGUgaXQgY2FuIG1ha2UgcGVvcGxlIGNsZWFyIG9u IHdoeSB3ZSBwaWNrZWQgdGhhdCBvcHRpb24uDQoNCkFsc28sIEkgbGlrZSBEaHJ1didzIHByb3Bv c2FsIGZvciBuYW1lIGNoYW5nZTsgd2UgZGVmaW5lIHRoZSBBc3NvY2lhdGlvbiBncm91cCBiYXNl ZCBvbiB0aGUgYWN0aW9ucy9wcm9jZXNzaW5nIHJlcXVpcmVkIG9uIFBDRS9QQ0MsIHRoYXQgd2ls bCBoZWxwIHVzIHRvIHVuZGVyc3RhbmQgdGhlbSBlYXNpZXIuIExpa2Ugc2luZ2xlLXNpZGVkL2Rv dWJsZS1zaWRlZCBBRyB3aXRoIHNpZ25hbGluZywgYW5kIGRvdWJsZS1zaWRlZCBBRyB3aXRob3V0 IHNpZ25hbGluZy4NCg0KVGhhbmtzIGFuZCB0YWtlIGNhcmUgb2YgeW91cnNlbHZlcy4NCkNoZW5n DQoNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBQY2UgW21haWx0bzpwY2Ut Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIERocnV2IERob2R5DQrlj5HpgIHml7bpl7Q6IDIwMjDl ubQy5pyIM+aXpSAxMzo1Ng0K5pS25Lu25Lq6OiBGYXJyZWwgQWRyaWFuIDxhZHJpYW5Ab2xkZG9n LmNvLnVrPg0K5oqE6YCBOiBwY2VAaWV0Zi5vcmc7IFN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0Ev T3R0YXdhKSA8YW5kcmV3LnN0b25lQG5va2lhLmNvbT4NCuS4u+mimDogUmU6IFtQY2VdIEFkb3B0 aW9uIG9mIGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2Pw0KDQpIaSBBZHJpYW4sIFJha2Vz aCwNCg0KVmFsaWQgcXVlc3Rpb25zLiBJIHdhcyBhbHNvIHdvbmRlcmluZyBpZiBpdCB3b3VsZCBo ZWxwIGlmIHdlIGdlbmVyYWxpc2UgdGhlIGFzc29jaWF0aW9uLXR5cGUgbmFtZXMgLQ0KDQpzdWNo IGFzIC0NCg0KRG91YmxlLXNpZGVkIEJpZGlyZWN0aW9uYWwgTFNQIEFzc29jaWF0aW9uIEdyb3Vw IHdpdGggTFNQIHNpZ25hbGxpbmcgKHVzZWQgZm9yIFJTVlAtVEUpIERvdWJsZS1zaWRlZCBCaWRp cmVjdGlvbmFsIExTUCBBc3NvY2lhdGlvbiBHcm91cCB3aXRob3V0IExTUCBzaWduYWxpbmcgKHVz ZWQgYnkgU1IsIFBDRUNDLCBzb21lIGZ1dHVyZSBtaXggY2FzZSBldGMpDQoNCg0Kb3INCg0KRG91 YmxlLXNpZGVkIEJpZGlyZWN0aW9uYWwgTFNQIEFzc29jaWF0aW9uIEdyb3VwICh1c2VkIGZvciBS U1ZQLVRFKSBEb3VibGUtc2lkZWQgQmlkaXJlY3Rpb25hbCBMU1AgQXNzb2NpYXRpb24gR3JvdXAg d2l0aCByZXZlcnNlIGRpcmVjdGlvbiBMU1AgZW5jb2RlZCBpbiBQQ0VQICh1c2VkIGJ5IFNSLCBQ Q0VDQywgc29tZSBmdXR1cmUgbWl4IGNhc2VzIGV0YykNCg0KDQpJIGZlZWwgdGhpcyB3b3VsZCBo ZWxwIHRob3NlIGVhcmx5IGltcGxlbWVudGVyIHRoYXQgd2FudGVkIHRvIGRlY2lkZSB0aGUgcHJv Y2Vzc2luZyBiYXNlZCBvbiBjb25maWd1cmVkIGFzc29jaWF0aW9uIHR5cGUgcmF0aGVyIHRoYW4g dGhlIFBTVCBvZiB0aGUgZmlyc3QgTFNQIHRoYXQgam9pbnMgdGhlIGFzc29jaWF0aW9uLCBhbmQg Zml0cyB3ZWxsIHdpdGggZGlmZmVyZW50IGJpLWRpcmVjdGlvbmFsIGFzc29jaWF0aW9uIHR5cGVz IGJhc2VkIG9uIHRoZSBleHBlY3RlZCBwcm9jZXNzaW5nIGF0IFBDRSwgYXMgd2VsbCBkbyBub3Qg bGVhZCB0byB0b28gbWFueSBhc3NvY2lhdGlvbiB0eXBlcy4NCg0KVGhvdWdodHM/DQoNCkRocnV2 DQoNCg0KT24gTW9uLCBGZWIgMywgMjAyMCBhdCAyOjIyIEFNIEFkcmlhbiBGYXJyZWwgPGFkcmlh bkBvbGRkb2cuY28udWs+IHdyb3RlOg0KPg0KPiBUaGFua3MgUmFrZXNoLA0KPg0KPg0KPg0KPiBJ dCBzZWVtcyB0byBtZSB0aGF0IGFzc29jaWF0aW5nIGFuIFNSIHBhdGggaW4gb25lIGRpcmVjdGlv biB3aXRoIGFuIFJTVlAtVEUgcGF0aCBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uIGlzICpwb3NzaWJs ZSogYnV0IHNlZW1zIHVubGlrZWx5IGluIHRoZSBleHRyZW1lLiBJIHdvdWxkIG5vdCB3YW50IHRv IHRha2UgYW4gYWN0aW9uIHRoYXQgbWFkZSBpdCBpbXBvc3NpYmxlIHRvIGFkZCB0aGlzIGZlYXR1 cmUgc2hvdWxkIHNvbWVvbmUgY29tZSB1cCB3aXRoIGEgcHJlc3NpbmcgZGVzaXJlLCBidXQgaXQg bG9va3MgbGlrZSBhbiBvZGQgdGhpbmcgdG8gc3BlY2lmaWNhbGx5IGVuZ2luZWVyIGludG8gdGhl IHNvbHV0aW9uIGF0IHRoaXMgc3RhZ2UuDQo+DQo+DQo+DQo+IE9mIGNvdXJzZSwgYSB3YXkgdG8g dGVzdCB0aGlzIHdvdWxkIGJlIHRvIHNlbmQgYW4gZW1haWwgdG8gU1BSSU5HIGFuZCBURUFTIHRv IGFzayB0aGlzIHNwZWNpZmljIHF1ZXN0aW9uLiBBZnRlciBhbGwsIHRoZSBwdXJwb3NlIG9mIFBD RSBpcyB0byBzZXJ2ZSBhcyBhIHRvb2wgdG8gZmFjaWxpdGF0ZSB3aGF0IHRoZSBwZW9wbGUgaW4g dGhvc2UgdHdvIFdHcyBhcmUgdHJ5aW5nIHRvIGRvLg0KPg0KPg0KPg0KPiBUaGUgdHdvIHF1ZXN0 aW9ucyByYWlzZWQgaW4gdGhlIGVhcmxpZXIgdGhyZWFkcyBhcmUgcmVsYXRlZCB0byB0aGlzLCBi dXQgZG8gbm90IHF1aXRlIGNhbmNlbCBlYWNoIG90aGVyIG91dC4NCj4NCj4gRG8gd2UgbmVlZCB0 d28gZGlmZmVyZW50IGFzc29jaWF0aW9uIHR5cGVzLCBvbmUgZm9yIFJTVlAtVEUgYW5kIG9uZSBm b3IgU1I/DQo+IElzIGl0IGFuIGVycm9yIGlmIHRoZXJlIGlzIGFuIGF0dGVtcHQgdG8gYXNzb2Np YXRlIGFuIExTUCB3aXRoIGFuIFNSIHBhdGg/DQo+DQo+DQo+DQo+IEJlc3QsDQo+DQo+IEFkcmlh bg0KPg0KPg0KPg0KPiBGcm9tOiBSYWtlc2ggR2FuZGhpIDxyZ2FuZGhpLmlldGZAZ21haWwuY29t Pg0KPiBTZW50OiAwMSBGZWJydWFyeSAyMDIwIDE2OjQ2DQo+IFRvOiBTdG9uZSwgQW5kcmV3IChO b2tpYSAtIENBL090dGF3YSkgPGFuZHJldy5zdG9uZUBub2tpYS5jb20+DQo+IENjOiBEaHJ1diBE aG9keSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+OyBwY2VAaWV0Zi5vcmc7IEZhcnJlbCBBZHJpYW4g DQo+IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KPiBTdWJqZWN0OiBSZTogW1BjZV0gQWRvcHRpb24g b2YgZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDY/DQo+DQo+DQo+DQo+IFRoYW5rcyBBbmRy ZXcuDQo+DQo+IEFkZGluZyBBZHJpYW4gd2hvIGhhZCBhIHNpbWlsYXIgY29tbWVudCBpbiBhIGRp ZmZlcmVudCB0aHJlYWQuDQo+DQo+DQo+DQo+IEhpIERocnV2LCBDaGVuZywNCj4NCj4NCj4NCj4g Rm9yIGFsbCBvdGhlciBhc3NvY2lhdGlvbiB0eXBlcyAoVk4sIFBvbGljeSwgZGl2ZXJzaXR5LCBl dGMuKSwgd2UgZG8gbm90IGhhdmUgZGlmZmVyZW50IHR5cGVzIGRlZmluZWQgZm9yIFJTVlAgYW5k IFNSLiBJZiB3ZSB1c2UgdGhlIHNhbWUgYXNzb2NpYXRpb24gdHlwZSBhbmQgbGltaXQgdGhlIExT UHMgdG8gYmUgdGhlIHNhbWUgdHlwZSAoUFNUKSBpbiB0aGUgYmlkaXJlY3Rpb25hbCBMU1AsIHRo ZW4gbWF5IGJlIGltcGxlbWVudGF0aW9uIGNhbiBoYW5kbGUgdGhlIGxvZ2ljIGZvciB0aGUgUFNU IHR5cGUgYWNjb3JkaW5nbHk/IEFzIElBTkEgYWxsb2NhdGlvbiBoYXMgbm90IGJlZW4gZG9uZSwg Y3VycmVudCBpbXBsZW1lbnRhdGlvbiBjYW4gYmUgYWRqdXN0ZWQ/DQo+DQo+DQo+DQo+IFRoYW5r cywNCj4NCj4gUmFrZXNoDQo+DQo+DQo+DQo+IE9uIFRodSwgSmFuIDIzLCAyMDIwIGF0IDk6NDAg UE0gU3RvbmUsIEFuZHJldyAoTm9raWEgLSBDQS9PdHRhd2EpIDxhbmRyZXcuc3RvbmVAbm9raWEu Y29tPiB3cm90ZToNCj4NCj4gSGkgUmFrZXNoLA0KPg0KPg0KPg0KPiBUaGFua3MgZm9yIHRoZSBy ZXBseSBhbmQgaW5wdXQuIEkgaW5pdGlhbGx5IGhhZCB0aGUgc2FtZSB0aG91Z2h0IGFzIHdlbGw6 ICJqdXN0IG1pZ3JhdGUgYm90aCBzaWRlcyBhdCB0aGUgc2FtZSB0aW1lIi4gT25seSBjb25jZXJu IGlzIG9mIGNvdXJzZSBzb21lIG1pZ3JhdGlvbiBzdHJhdGVnaWVzIGNob29zZSB0byBtaWdyYXRl IHJlZ2lvbmFsbHkgb3Igbm9kZS1ieS1ub2RlLCByYXRoZXIgdGhhbiB0dW5uZWwgcGFpcnMuIElu IHRoaXMgY2FzZSwgZGVmaW5pdGVseSB3aWxsIGhhdmUgdG8gZG8gYm90aCBzaWRlcyBhdCB0aGUg c2FtZSB0aW1lLiBJdCBtYXkgbm90IGFjdHVhbGx5IGJlIHRoYXQgdHJvdWJsZXNvbWUsIHNpbmNl IEknbSBub3QgYW4gb3BlcmF0b3IganVzdCBnb2luZyBieSB3aGF0IEkndmUgaGVhcmQgZnJvbSBj b2xsZWFndWVzIGFuZCB0aGVvcml6aW5nIHRoZSBzaXR1YXRpb24uDQo+DQo+DQo+DQo+IENoZWVy cw0KPg0KPiBBbmRyZXcNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4NCj4gRnJvbTogUmFrZXNoIEdhbmRoaSA8cmdhbmRoaS5pZXRmQGdtYWlsLmNvbT4NCj4g U2VudDogVGh1cnNkYXksIEphbnVhcnkgMjMsIDIwMjAgMTE6MTIgQU0NCj4gVG86IFN0b25lLCBB bmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSA8YW5kcmV3LnN0b25lQG5va2lhLmNvbT4NCj4gQ2M6 IERocnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbT47IHBjZUBpZXRmLm9yZyA8cGNlQGll dGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW1BjZV0gQWRvcHRpb24gb2YgZHJhZnQtbGktcGNlLXNy LWJpZGlyLXBhdGgtMDY/DQo+DQo+DQo+DQo+IEhpIEFuZHJldywNCj4NCj4NCj4NCj4gTWFueSB0 aGFua3MgZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGJlbG93IHdpdGggPFJH Mj4uLg0KPg0KPg0KPg0KPiBPbiBXZWQsIEphbiAyMiwgMjAyMCBhdCAxMDo1NyBQTSBTdG9uZSwg QW5kcmV3IChOb2tpYSAtIENBL090dGF3YSkgPGFuZHJldy5zdG9uZUBub2tpYS5jb20+IHdyb3Rl Og0KPg0KPiBIaSBEaHJ1diwNCj4NCj4gVGhhbmtzIGFnYWluIGZvciB0aGUgc3BlZWR5IHJlcGx5 LiBDb21tZW50cyBiZWxvdyB1bmRlciA8YW5kcmV3Mj4NCj4NCj4gQ2hlZXJzDQo+IEFuZHJldw0K Pg0KPiDvu79PbiAyMDIwLTAxLTIyLCA4OjAxIEFNLCAiRGhydXYgRGhvZHkiIDxkaHJ1di5pZXRm QGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+ICAgICBIaSBBbmRyZXcsDQo+DQo+ICAgICBPbiBXZWQs IEphbiAyMiwgMjAyMCBhdCAxMjowNiBBTSBTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENBL090dGF3 YSkNCj4gICAgIDxhbmRyZXcuc3RvbmVAbm9raWEuY29tPiB3cm90ZToNCj4gICAgID4NCj4gICAg ID4gSGkgRGhydXYsDQo+ICAgICA+DQo+ICAgICA+IFRoYW5rcyBmb3IgdGhlIHJlcGx5IGFuZCBm ZWVkYmFjay4NCj4gICAgID4NCj4gICAgID4gQ291bGQgYW4gaW1wbGVtZW50YXRpb24gb2YgUENF IG5vdCBzaW1wbHkganVzdCByZXR1cm4gZXJyb3IgZHVyaW5nIHRoYXQgc2l0dWF0aW9uPyBJbiBk aXZlcnNpdHkgaWYgdG9vIG1hbnkgTFNQcyBncm91cGVkIHRvZ2V0aGVyIGFuZCBQQ0UgY29tcHV0 YXRpb25hbGx5IGNhbid0IHN1cHBvcnQgaXQsIGl0IHJldHVybnMgYSBQQ0VSUi4gU28gSSB3b3Vs ZCByZWFzb24gdGhhdCBpZiBiaWRpcmVjdGlvbmFsbHkgYXNzb2NpYXRlZCBhbmQgbm90aWZ5IFBD Q3MgaXMgbmVjZXNzYXJ5LCBidXQgd2FzIGNvbmZpZ3VyZWQgYmV0d2VlbiBTUiBhbmQgUlNWUCwg dGhhdCdzIGFsc28gYW4gZXJyb3IgZHVlIHRvIHRoZSAoY3VycmVudCkgdW5zdXBwb3J0ZWQgZmVh dHVyZSBzZXQuIEkgc2VlIHRoaXMgYXMgdHJ5aW5nIHRvIHByb3RlY3QgYWdhaW5zdCBkYXktMCBt aXNjb25maWcgYnkgY2hhbmdpbmcgdGhlIHdpcmUgZW5jb2Rpbmcgd2l0aGluIHRoZSBwcm90b2Nv bCAod2hpY2ggSSdtIG5vdCBuZWNlc3NhcmlseSBhZ2FpbnN0Li4pLiBXaGlsZSBJIGhhdmUgZG91 YnQgaWYgaXQncyBhIHZhbGlkIHVzZSBjYXNlIG9yIHJlcXVpcmVtZW50IGluIGEgcHJvZHVjdGlv biBkZXBsb3ltZW50LCBhbmQgaXQgbWF5IGhhdmUgYmVlbiBhY2tub3dsZWRnZWQgYmVmb3JlLCBi dXQgdGhpcyBlc3NlbnRpYWxseSBibG9ja3MgYXNzb2NpYXRpbmcgU1IgTFNQIHdpdGggUlNWUCBM U1AgYmlkaXJlY3Rpb25hbGx5IGZvciBQQ0UgdG8gY29tcHV0ZS4NCj4gICAgID4NCj4gICAgID4g U2luY2UgdGhlIG92ZXJhbGwgd29ya2Zsb3cgZG9lc24ndCBjaGFuZ2UgYnkgdGhpcyBuZXcgdHlw ZSBkZWYsIGFuZCBpZiBTUjwtPlJTVlAgYXNzb2NpYXRlZCBpcyBub3QgcmVhc29uYWJsZSByZXF1 aXJlbWVudCwgYW5kIElmIGNvbnNlbnN1cyBoYXMgYWxyZWFkeSBiZWVuIHJlYWNoZWQgb24gdGhp cywgYW5kIGltcGxlbWVudGF0aW9uIGFscmVhZHkgZXhpc3QsIEknbSBva2F5IHdpdGggcGFya2lu ZyB0aGlzIHRvcGljLg0KPiAgICAgPg0KPg0KPiAgICAgVGhlIFNSIGRyYWZ0IGRvZXMgZXhwZWN0 IGFsbCBMU1BzIHRvIGJlIFNSIGZvciB0aGUgbmV3IGFzc29jaWF0aW9uDQo+ICAgICB0eXBlIGFu ZCB0aHVzIGVhc2llciB0byBoYW5kbGUuIElmIHlvdSB1c2UgYSBjb21tb24gYXNzb2NpYXRpb24g dHlwZSwNCj4gICAgIHRoZSBiZWhhdmlvciB3b3VsZCBiZSBkZXBlbmRlbnQgb24gdGhlIFBTVCBm b3IgdGhlIGZpcnN0IExTUCB0aGF0IGlzDQo+ICAgICBhZGRlZCB0byB0aGUgYXNzb2NpYXRpb24u IFdlIGNvdWxkIGVuZCB1cCBpbiBhIHNpdHVhdGlvbiB3aGVyZSBQZWVyIDENCj4gICAgIHdvdWxk IGFkZCBMU1AgMSAoU1IpIGZpcnN0IGFuZCByZWplY3QgTFNQIDIgKFJTVlAtVEUpIGFuZCBwZWVy IDIgd291bGQNCj4gICAgIGFkZCBMU1AgMiAoUlNWUC1URSkgZmlyc3QgYW5kIHJlamVjdCBMU1Ag MSAoU1IpLiBBbHNvIHRoZXJlIG1pZ2h0IGJlIGENCj4gICAgIHVzZSBmb3IgdGhpcyBtaXhlZCBj YXNlcyBpbiBmdXR1cmUsIHdoaWNoIHdvdWxkIHJlcXVpcmUgZGlmZmVyZW50DQo+ICAgICBwcm9j ZXNzaW5nIHRvIGJlIGRlZmluZWQuDQo+DQo+DQo+IDxBbmRyZXcyPg0KPg0KPiBJIHdpbGwgcG9u ZGVyIG9uIHRoaXMgc29tZSBtb3JlLiBJJ20gdW5kZWNpZGVkIHlldCBpZiB0aGUgcmVhc29ucyB0 byBwcm90ZWN0IGNvbmZpZy9iZWhhdmlvdXIgbWlzbWF0Y2gsIG91dHdlaWdoIGp1c3QgaGF2aW5n IG9uZSB0eXBlIGVuY29kaW5nIGFuZCBkZWZpbmluZyB0aGUgaW5kaXZpZHVhbCBiZWhhdmlvdXJz IHNlcGFyYXRlbHksIHdoaWNoIGNvdWxkIGFsc28gYmUgdXAgdG8gdGhlIGxvY2FsIHBvbGljeSBk ZWZpbmVkIGJ5IHRoZSBQQ0UgaW1wbGVtZW50YXRpb24uDQo+DQo+IEl0IGNvdWxkIGJlIHBvc3Np YmxlIHRoYXQgYSBuZXR3b3JrIGhhcyBub2RlcyBjdXJyZW50bHkgcnVubmluZyBSU1ZQLCB3aXRo IHBsYW5zIHRvIG1pZ3JhdGUgdG8gU1ItVEUgd2hpY2ggY291bGQgdGFrZSBhIHZlcnkgbG9uZyB0 aW1lIGR1ZSB0byB0aGUgc2l6ZSBvZiB0aGUgbmV0d29yay4gVGhlIHNvZnR3YXJlIHJ1bm5pbmcg b24gdGhlIG5vZGVzIG1heSBiZSB1cGdyYWRlZCwgb2Ygd2hpY2ggdGhvc2UgUENDcyBtYXkgaGF2 ZSBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGVzZSBiaWRpcmVjdGlvbmFsIGRyYWZ0cywgYnV0IGhh dmUgc3RpbGwgbm90IHlldCBtaWdyYXRlZCB0byBTUi1URS4gQW4gb3BlcmF0b3IgbWF5IHdpc2gg dG8gbGV2ZXJhZ2UgUENFIGZlYXR1cmUgc2V0cyBvbiBuZXdlciBjcmVhdGVkIHNlcnZpY2VzIHNv b25lciB0aGFuIGxhdGVyIChmb3IgZXhhbXBsZSwgYmlkaXJlY3Rpb25hbCBjYXBhYmlsaXR5KSBz byB0aGV5IGJlZ2luIHVzaW5nIGJpZGlyZWN0aW9uYWwgUlNWUCB0byBoYXZlIHN5bW1ldHJpYyBw YXRocyBmb3IgU0xBIHJlYXNvbnMgYW5kIGFpZCBpbiBhdm9pZGluZyBtYW51YWwgdHJhZmZpYyBl bmdpbmVlcmluZy4gT3ZlciB0aW1lLCBhcyB0aGUgbmV0d29yayBpcyBtaWdyYXRlZCB0byBTUi1U RSB0dW5uZWxzIHlvdSBoYXZlIHNvbWUgbm9kZXMgdXNpbmcgU1ItVEUgdHVubmVscyBhbmQgdGhl IHJldmVyc2Ugbm9kZXMgc3RpbGwgb3BlcmF0aW5nIHdpdGggUlNWUC4gRnJvbSBhbiBvcGVyYXRv ciBwLm8udiB0aGUgYmlkaXJlY3Rpb25hbCBub3RpZmljYXRpb24gYmVoYXZpb3VyIGhlcmUgd291 bGRuJ3QgbWF0dGVyLCB0aGV5IGp1c3Qgd2FudCB0aGUgTFNQcyB0byB0YWtlIHRoZSBzYW1lIHJl c291cmNlcyBzeW1tZXRyaWNhbGx5LiBUaGUgZmVhdHVyZSBzZXQgb24gUENFLCBhcyBwZXIgdGhl IGN1cnJlbnQgZHJhZnQgd29yZGluZyBhbmQgdHlwZXMgd2lsbCBiZSBicm9rZW4uDQo+DQo+IDwv ZW5kIGFuZHJldzI+DQo+DQo+DQo+DQo+DQo+DQo+IDxSRzI+IEkgd291bGQgdGhpbmsgdGhhdCB0 aGUgbWlncmF0aW9uIHdvdWxkIGhhcHBlbiBmb3IgdGhlIHdob2xlIGJpZGlyZWN0aW9uYWwgTFNQ IG9uIGJvdGggZW5kcG9pbnRzIGF0IHRoZSBzYW1lIHRpbWUuIFRoaXMgaXMgYmVjYXVzZSwgYWxs IG5vZGVzIHdvdWxkIGhhdmUgbWlncmF0ZWQgdG8gYmUgU1IgYXdhcmUgaW4gb3JkZXIgZm9yIHRo ZSBmb3J3YXJkIHBhdGggdG8gYmUgU1IgcGF0aCAoSSBhbSB0aGlua2luZyBjby1yb3V0ZWQpLiBJ biBhZGRpdGlvbiwgdGhlIGNvbXBsZXhpdHkgdG8gYXNzb2NpYXRlIHRoZSBTUiBhbmQgUlNWUCBw YXRocyBpbnRvIGEgYmlkaXJlY3Rpb25hbCBwYXRoIGlzIG5vdCBzbWFsbCwgZ2l2ZW4gdGhhdCBT UiBwYXRoIGluZ3Jlc3Mgbm9kZSB3b3VsZCBrbm93IHRoZSByZXZlcnNlIHBhdGggdmlhIHNpZ25h bGluZyB3aGVyZWFzIFJTVlAgcGF0aCBpbmdyZXNzIG5vZGUgd291bGQga25vdyB2aWEgUENFUC4g IFdoaWNoIGFsc28gbWVhbnMsIG9uZSB3b3VsZCBuZWVkIHRvIHVwZ3JhZGUgdGhlIFJTVlAgaW5n cmVzcyBub2RlIGFueXdheXMgdG8gbGVhcm4gdGhlIHJldmVyc2UgU1IgcGF0aC4gVHJhZmZpYyBz dGVlcmluZyBhbmQgb3RoZXIgZnVuY3Rpb25zIGZvciB0aGUgUlNWUCBwYXRoIGFuZCBTUiBwYXRo IGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiAoYW5kIHZpY2UgdmVyc2EpIG1heSBicmluZyBhZGRp dGlvbmFsIHdvcmsuDQo+DQo+DQo+DQo+IDxSRzI+IEhhdmluZyBzYWlkIHRoYXQsIHRoZSBzYW1l IGFzc29jaWF0aW9uIGdyb3VwIHR5cGUgY2FuIGJlIHVzZWQgZm9yIFNSIGFuZCBSU1ZQIHBhdGhz IChlLmcuIGJvdGggYXJlIHRoZSBzYW1lIFBTVCkgaW4gdGhlb3J5LCBidXQgZ2l2ZW4gdGhlIGlt cGxlbWVudGF0aW9uIHN0YXR1cyBpbiB0aGUgZHJhZnQsIEkgd2lsbCBsZXQgcmVzcGVjdGl2ZSBj by1hdXRob3JzIGNvbW1lbnQuDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+ICAgICA+IFN0aWxsIGhv cGluZyBmb3IgZmVlZGJhY2sgcmVnYXJkaW5nIG15IGNvbW1lbnRzIG9uIHNlY3Rpb24gNS4gSSBz ZWUgdGhhdCBhcyBiZWluZyBtb3JlIHNpZ25pZmljYW50LCBzaW5jZSBpdCBpbmZsdWVuY2VzIHRo ZSB3b3JrZmxvdyBhbmQgYXQgdGhlIG1vbWVudCBJIGRvbid0IHNlZSB0aGUgZGVwZW5kZW5jeSBv biBkcmFmdC1saS1wY2UtY29udHJvbGxlZC1pZC1zcGFjZSBhcyBuZWNlc3NhcnkgdG8gYWNoaWV2 ZSBub3RpZnlpbmcgUENDcyBvZiByZXZlcnNlIHBhdGhzLg0KPiAgICAgPg0KPg0KPiAgICAgQW5k IEkgd2FzIGhvcGluZyB0aGF0IGF1dGhvcnMgd291bGQgdGFrZSBhIGJpdGUgOikNCj4gICAgIEZy b20gd2hhdCBJIHVuZGVyc3Rvb2QgUExTUC1JRCByZW1haW5zIGEgUENDIGFsbG9jYXRlZCBJRC4g VGhlIHBvaW50DQo+ICAgICB0aGF0IHNlY3Rpb24gNSBpcyBtYWtpbmcgaXMgdGhhdCB0aGUgc2Ft ZSBMU1Agd291bGQgYmUgaWRlbnRpZmllZCBieQ0KPiAgICAgdHdvIFBMU1AtSURzLCBvbmUgYWxs b2NhdGVkIGJ5IEluZ3Jlc3MgYW5kIGFub3RoZXIgYnkgRWdyZXNzIFBDQ3MuDQo+ICAgICBUaGVy ZSBpcyBubyBwcm9wb3NhbCBmb3IgUENFLWNvbnRyb2xsZWQgUExTUC1JRC4gU28gUENFLWluaXQg KyBSIGJpdA0KPiAgICAgaXMgZW5vdWdoICAoYXMgeW91IHN0YXRlKSBhbmQgSSBhbSBpbiBmdWxs IGFncmVlbWVudCB3aXRoIHlvdSB0aGF0DQo+ICAgICBmaWd1cmVzIHdpdGggUExTUC1JRCBjb3Vs ZCBiZSB1c2VmdWwuDQo+DQo+DQo+DQo+DQo+IDxBbmRyZXcyPg0KPg0KPiBUaGFua3MgZm9yIHRo ZSBjb21tZW50cyBhbmQgYWdyZWVtZW50LiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNiBz ZWN0aW9uIDUuMSwgc2F5cyAiUENFIG5lZWRzIHRvIGFsbG9jYXRlIGEgUExTUC1JRCIuIFBlcmhh cHMgaXQgd2FzIGp1c3QgYSB0eXBvIGFuZCBzaG91bGQgaGF2ZSBzYWlkIFBDQy4NCj4NCj4gPT09 Y3VycmVudA0KPiAgICBTaW5jZSB0aGUgUExTUC1JRCBzcGFjZSBpcyBpbmRlcGVuZGVudCBhdCBl YWNoIFBDQywgdGhlIFBMU1AtSUQNCj4gICAgYWxsb2NhdGVkIGJ5IHRoZSBlZ3Jlc3MgUENDIGNh biBub3QgYmUgdXNlZCBmb3IgdGhlIExTUCBhdCB0aGUNCj4gICAgaW5ncmVzcyBQQ0MgKFBMU1At SUQgY29uZmxpY3QgbWF5IG9jY3VyKS4gIEhlbmNlLCB0aGUgUENFIG5lZWRzIHRvDQo+ICAgIGFs bG9jYXRlIGEgUExTUC1JRCBmb3IgTFNQMiBmcm9tIHRoZSBpbmdyZXNzIFBDQydzIFBMU1AtSUQg c3BhY2UgLA0KPiAgICBzYXkgMTAxLiAgU2ltaWxhcmx5IGZvciBMU1AxLCBpdCBoYXMgUExTUC1J RCAxMDAgYXQgdGhlIGluZ3Jlc3MsIGFuZA0KPiAgICBtYXkgaGF2ZSBzYXkgUExTUC1JRCAyMDEg YXQgdGhlIGVncmVzcyBub2RlLg0KPiA9PT09PWVuZCBjdXJyZW50DQo+DQo+DQo+IE1heSBJIHBy b3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0ICAob3Igc29tZXRoaW5nIGxpa2UgaXQpIGluc3RlYWQ6 DQo+DQo+DQo+ID09PW5ldyBwcm9wb3NhbA0KPg0KPiAgICBTaW5jZSB0aGUgUExTUC1JRCBzcGFj ZSBpcyBpbmRlcGVuZGVudCBhdCBlYWNoIFBDQywgdGhlIFBMU1AtSUQNCj4gICAgYWxsb2NhdGVk IGJ5IHRoZSBlZ3Jlc3MgUENDIGNhbm5vdCBiZSB1c2VkIGZvciB0aGUgTFNQIGF0IHRoZQ0KPiAg ICBpbmdyZXNzIFBDQyAoUExTUC1JRCBjb25mbGljdCBtYXkgb2NjdXIpLiBBcyBwZXIgbm9ybWFs IFBDRS1JTklUDQo+ICAgIG9wZXJhdGlvbnMsIFBDQyBhc3NpZ25zIHRoZSBQTFNQLUlEcyBmb3Ig bG9jYWwgTFNQcy4NCj4gICAgSGVuY2UsIHdoZW4gdGhlIFBDRSBub3RpZmllcyBhbiBpbmdyZXNz IFBDQyBvZiB0aGUgcmV2ZXJzZSBlZ3Jlc3MgTFNQLCBpdA0KPiAgICBkb2VzIHNvIHVzaW5nIFBD RS1JTklUIG9wZXJhdGlvbnMgYW5kIHNldHMgUExTUC1JRCB0byB6ZXJvIGFuZCBzZXRzIHRoZSBS IGJpdCBpbiB0aGUgYXNzb2NpYXRpb24NCj4gICAgb2JqZWN0IHRvIGluZGljYXRlIHRoYXQgdGhp cyBQQ0UtSU5JVCBMU1AgaXMgYSByZXZlcnNlIExTUC4gVGhlIFBDQw0KPiAgICB1cG9uIHJlY2Vp dmluZyB0aGUgUENFLUlOSVQgTVVTVCBsb2NhbGx5IGFzc2lnbiBhIFBMU1AtSUQgYW5kIGl0IE1V U1QNCj4gICAgaXNzdWUgYSBQQ1JFUE9SVCB0byBQQ0UgZm9yIHRoaXMgTFNQIGNvbnRhaW5pbmcg dGhlIG5ldyBQTFNQLUlELiBUaGlzDQo+ICAgIExTUCBNVVNUIE5PVCBiZSBpbnN0YW50aWF0ZWQg b24gdGhlIFBDQy4NCj4NCj4gICAgRm9yIGV4YW1wbGUsIGluZ3Jlc3MgUENDMSB3YXkgbWF5IHJl cG9ydCB0byBQQ0UgYW4gTFNQIHdpdGgNCj4gICAgUExTUC1JRCAxMDAuIEVncmVzcyBQQ0MyIG1h eSByZXBvcnQgdG8gUENFIGFuIExTUCB3aXRoIFBMU1AtSUQgMjAwLg0KPiAgICBCb3RoIG9mIHRo ZXNlIExTUHMgYXJlIGJpLWRpcmVjdGlvbmFsIGFzc29jaWF0ZWQuIFdoZW4gUENFDQo+ICAgIG5v dGlmaWVzIFBDQzEgb2YgdGhlIFBDQzIgTFNQLCBpdCBkb2VzIHNvIGJ5IHNlbmRpbmcgYSBQQ0Ut SU5JVCB0byBQQ0MxIHdpdGgNCj4gICAgUExTUC1JRCBzZXQgdG8gemVybyBhbmQgUiBiaXQgc2V0 LiBQQ0MxIHVwb24gcmVjZXB0aW9uIG9mIHRoaXMgZ2VuZXJhdGVzIGEgUExTUC1JRA0KPiAgICAo ZXhhbXBsZSBQTFNQLUlEIDMwMCkgYW5kIGlzc3VlcyBhIFBDUkVQT1JUIHRvIFBDRS4NCj4NCj4g PT09PT1lbmQgbmV3IHByb3Bvc2FsDQo+DQo+DQo+DQo+IDxSRzI+IExvb2tzIGdvb2QgdG8gbWUu IFRoYW5rcyBmb3IgdGhlIHRleHQuDQo+DQo+IDxSRzI+IE1hbnkgdGhhbmtzIERocnV2IGZvciB0 aGUgaW5wdXRzLg0KPg0KPg0KPg0KPiBUaGFua3MsDQo+DQo+IFJha2VzaA0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPiA8L2VuZCBhbmRyZXcyPg0KPg0KPg0KPg0KPg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From nobody Tue Feb 4 18:56:56 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC212001A; Tue, 4 Feb 2020 18:56:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158087141203.15738.290000466063980777@ietfa.amsl.com> Date: Tue, 04 Feb 2020 18:56:52 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-association-bidir-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 02:56:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) Authors : Rakesh Gandhi Colby Barth Bin Wen Filename : draft-ietf-pce-association-bidir-05.txt Pages : 18 Date : 2020-02-04 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. This document defines PCEP extensions for grouping two unidirectional MPLS TE LSPs (one in each direction in the network) into an Associated Bidirectional LSP. The mechanisms defined in this document can be applied using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs, as well as when using a Stateless PCE. The procedures defined are applicable to the LSPs using Resource Reservation Protocol (RSVP) for signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-association-bidir-05 https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-bidir-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-bidir-05 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 Feb 5 05:56:43 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706B21200B3 for ; Wed, 5 Feb 2020 05:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 uAQV7DEh1KHN for ; Wed, 5 Feb 2020 05:56:40 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8952B12004E for ; Wed, 5 Feb 2020 05:56:39 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id f25so2364312ljg.12 for ; Wed, 05 Feb 2020 05:56:39 -0800 (PST) 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=Nd0CqkXDgNo5Kk2M6LUoaHMwftVc8ev+Ynk3pxM9leM=; b=QYBGfRByqn9qzWEHsmUmrljeItXsZ89Nnt7i5N8tUEtbAljnfama5caE9ujip2Xrbn JF82QSuOEWjkHOcmf/RHw9n8Iv7HlsVR9EG85/nm3ZoPzW3s0zR0QGe3BaRgFMItgePL NWlvBzmTWRm08uARTQaurmPvyGLjkT1M/FvJH6wuRsNAgWvPFLcGR+kpy07j0+CFk1RP nZuTfDopEG7csydg5YItoA7YHBO25Glq5Fy3H3XxWAqVkaaBnsJhTPk0cAIPV8+lIwA1 bH83JnC6Xet/kt9U2CPuFT1D8PK5YehExDXi3/E1qz7N1xCi3X0p7trpo3ZsrCcGF3MU W2gA== 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=Nd0CqkXDgNo5Kk2M6LUoaHMwftVc8ev+Ynk3pxM9leM=; b=tOZte2Rx43fO/+De6eeTEjxw3QZdqZSDnS57eC/iC9rDnykTUrhoThbunB0N4JCHGT 2aM4qoyyWozpQJF2JuKEJlMbeHmlPRsIUTWG+T0GXNTmHH89BBEsQpMr6fmiM2iSa6Cn aR4MWzEVCBEXB81cbtzPnHwxUtRizLEjfhJSUnQYWvx0Pl3IBDbutKSkw5QtB6FOT9Z8 cZ6etWe1begf/garm/iGsvCm2NuynGxXec1d9ygZKLBj2Q6DWspAkayDyYFYKkqzJ1o9 Crh47EFTQaRHuwPjTEvj6p1tWIlIt9xuRa9P08PO19b7FR5uxdyd9EoqjIOUXA4GWwIl fMbA== X-Gm-Message-State: APjAAAUTbLPb1P8PrgbIU5WovUX1bfAzx4eh5KPbTYMrY6NP/D22ACM/ H6UHoI5ofYzhglUQ3yUE2LMRKTM6PXdCzGhyfcIPg0UuNw== X-Google-Smtp-Source: APXvYqy9jnDY3Vi44n4O/M6U9gfqtyELxjHNsS0SSMuwxQsBYThNkWctpLMT7iIXiqVupoZHnulS03+AxyV8MhpL/ZM= X-Received: by 2002:a2e:9744:: with SMTP id f4mr16753173ljj.267.1580910997662; Wed, 05 Feb 2020 05:56:37 -0800 (PST) MIME-Version: 1.0 References: <158087141203.15738.290000466063980777@ietfa.amsl.com> In-Reply-To: <158087141203.15738.290000466063980777@ietfa.amsl.com> From: Rakesh Gandhi Date: Wed, 5 Feb 2020 08:56:26 -0500 Message-ID: To: pce@ietf.org Content-Type: multipart/alternative; boundary="0000000000006fef53059dd48658" Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-association-bidir-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 13:56:43 -0000 --0000000000006fef53059dd48658 Content-Type: text/plain; charset="UTF-8" Hi WG, The draft has been updated to align with recent RFC 8697 . Welcome your review comments and suggestions. Thanks, Rakesh On Tue, Feb 4, 2020 at 9:57 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element WG of the IETF. > > Title : PCEP Extensions for Associated Bidirectional > Label Switched Paths (LSPs) > Authors : Rakesh Gandhi > Colby Barth > Bin Wen > Filename : draft-ietf-pce-association-bidir-05.txt > Pages : 18 > Date : 2020-02-04 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > The Stateful PCE extensions allow stateful control of Multiprotocol > Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths > (LSPs) using PCEP. > > This document defines PCEP extensions for grouping two unidirectional > MPLS TE LSPs (one in each direction in the network) into an > Associated Bidirectional LSP. The mechanisms defined in this > document can be applied using a Stateful PCE for both PCE-Initiated > and PCC-Initiated LSPs, as well as when using a Stateless PCE. The > procedures defined are applicable to the LSPs using Resource > Reservation Protocol (RSVP) for signaling. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-pce-association-bidir-05 > https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-bidir-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-bidir-05 > > > 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/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --0000000000006fef53059dd48658 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,
The draft has been updated to align = with recent RFC 8697.
Welcome your review comments and suggestions.
Thanks,
Rakesh


On Tue, Feb 4, 2020 at 9:57 PM <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Path Computation Element WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rake= sh Gandhi
=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 Colby Barth
=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 Bin Wen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-pce-association-bidir-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-02-04

Abstract:
=C2=A0 =C2=A0The Path Computation Element Communication Protocol (PCEP) pro= vides
=C2=A0 =C2=A0mechanisms for Path Computation Elements (PCEs) to perform pat= h
=C2=A0 =C2=A0computations in response to Path Computation Clients (PCCs) re= quests.
=C2=A0 =C2=A0The Stateful PCE extensions allow stateful control of Multipro= tocol
=C2=A0 =C2=A0Label Switching (MPLS) Traffic Engineering (TE) Label Switched= Paths
=C2=A0 =C2=A0(LSPs) using PCEP.

=C2=A0 =C2=A0This document defines PCEP extensions for grouping two unidire= ctional
=C2=A0 =C2=A0MPLS TE LSPs (one in each direction in the network) into an =C2=A0 =C2=A0Associated Bidirectional LSP.=C2=A0 The mechanisms defined in = this
=C2=A0 =C2=A0document can be applied using a Stateful PCE for both PCE-Init= iated
=C2=A0 =C2=A0and PCC-Initiated LSPs, as well as when using a Stateless PCE.= =C2=A0 The
=C2=A0 =C2=A0procedures defined are applicable to the LSPs using Resource =C2=A0 =C2=A0Reservation Protocol (RSVP) for signaling.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-pce-association-bidir/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-iet= f-pce-association-bidir-05
https://datatracker.ietf.or= g/doc/html/draft-ietf-pce-association-bidir-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-pce-association-bidir-05


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/

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--0000000000006fef53059dd48658-- From nobody Wed Feb 5 13:09:05 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA19120823; Wed, 5 Feb 2020 13:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=orange.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 trlm6jjXzldM; Wed, 5 Feb 2020 13:09:02 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1BA12081D; Wed, 5 Feb 2020 13:09:02 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48CZ1S5CgmzFqnN; Wed, 5 Feb 2020 22:09:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1580936940; bh=zGFTxScAG4yLDwMafMzZ8Uy9vwXH9+ZYqzbS4iGz8ns=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; b=rlR0IG74W3hFZp+rtOQVm5G5Arzp3exxsj/lDtBZkV5k47CWF2vMrpl54tnc7awDh KiB809nAigfmgOYkfQTHuEwR5tUOqofcEIHCq2XxwWTRqB9PdDW2buNVv+1t3eeNSL vwe+Mh9DyasLpTfnjmJf+I5V+6RiP0V4n0or42HagDnORHQuQcw2utDMl9u8nDEIsK vAQDltk2B/eZSC5XB07+3DVnY9ohSEwW5mjydlUZtr7K2bBeGI71+bmkMWDjqCVzUm JL/KJe1KRGKyQVymGuj6d53goecQw4PTmAwkbVjJ65SezrRIl2yEVTOkpBOFQXdJs/ hgd3d5MHInzLw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 48CZ1S4GMKz5vN6; Wed, 5 Feb 2020 22:09:00 +0100 (CET) Received: from [10.192.150.143] (10.114.13.247) by exchange-eme6.itn.ftgroup (10.114.13.45) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 5 Feb 2020 22:09:00 +0100 To: , References: From: Organization: Orange Message-ID: <819569dd-0dd9-8980-2235-a2a8e6b70e83@orange.com> Date: Wed, 5 Feb 2020 22:08:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050308060603080002060402" X-Originating-IP: [10.114.13.247] Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 21:09:04 -0000 --------------ms050308060603080002060402 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, This I-D has enough support to be adopted. Before we proceed, we'd like to see an update addressing at least the issue about the number of names on the front page. Authors, please submit a -07 version accordingly, so that we can move the draft forward. Thanks, Dhruv & Julien On 17/01/2020 11:12, julien.meuric@orange.com wrote: > Hi all, > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > Do you believe the I-D is a right foundation for a PCE WG item? Please > use the PCE mailing list to express your comments, support or > disagreement, including applicable rationale, especially for the latter= =2E > > Thanks, > > Dhruv & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --------------ms050308060603080002060402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EmowggTeMIIDxqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMGoxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxJjAkBgNV BAMMHUdyb3VwZSBGcmFuY2UgVGVsZWNvbSBSb290IENBMB4XDTA1MTExNzExMDkzOVoXDTI1 MTExNzExMDkzOVowgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBT QTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAy IDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw8ytv/3/3nS8Xkfrfv3lWqny4 Gd1V8eVOT7B0WxfJMqfWPbu0aoc4WScRhqIhAH61Gmfa6f3AVq+o3PptjJ459kMp/ACaeRp8 DFzW7iNFm/Qfdk81V9dVLXHsbYwWU373j/ksx1Smmk3vsq4fWapeAOLfds70KO4RWP/YVSmO rAFVMiqV4l9f6a+G8Lr2tOZkWaX+3vb3HE6mDG3la3Y6VDpVpioSrz61KPb8pLyOg7TuhhIx OKTNNefEcDwFKx9zfVJax+PHj6zGbFzdGEMWexwGSi3SXkgAV6/CJNtCHHXE2OprWc30JiCY 18GkvPrRgO1XBSqx0xDIam+WpEh/AgMBAAGjggFgMIIBXDAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUNhwzZ9MTXPpbn+qLukRmdEbxd3gwdAYDVR0jBG0w a4AUGpJTyM8zG7bypWB94q8kEkGwmmChUIFOQ049R3JvdXBlIEZyYW5jZSBUZWxlY29tIFJv b3QgQ0EsIE9VPTAwMDIgMzgwMTI5ODY2LCBPPUZyYW5jZSBUZWxlY29tIFNBLCBDPUZSggEA MIGOBgNVHR8EgYYwgYMwQ6BBoD+GPWh0dHA6Ly9pZ2NnZnQtcmNhLWh0dHAuc2kuZnJhbmNl dGVsZWNvbS5mci9jcmwvaWdjZ2Z0X3JjYS5jcmwwPKA6oDiGNmh0dHA6Ly9pZ2NnZnQtcmNh LmZyYW5jZXRlbGVjb20uY29tL2NybC9pZ2NnZnRfcmNhLmNybDATBgNVHSAEDDAKMAgGBiqB egEQDDANBgkqhkiG9w0BAQUFAAOCAQEAlt994iqOFDZH/wQfDU6EQ1W1B/xs/k3xwBuBZgi3 NRWvvb8KhfoOVOyeuoO1r4072jo/AFDphvixN8EZiRp+luqZXQEXEaHrZjwRydCuUDwjPQkw A/DU5NzWn0FrKWRIstQa/MBcN9xniazs41Br3oNzlkUbAyuP2s3GRi5uFp7VV5Y5dU8lqdoL nE/TuBV0LFdre0WOdM7CoWVqNlreb7/zmuK2/zfLIaq2QIcWIOulqiIW1xxFWxc0JZi8p7qV zvysS0+8wevgoefks3PHoUMEaIHCpoSOC14JSkKCVuUMPBvu+ftPasJ+NQz1jUbb0kjUkpGn q33GgLPLSvsK5TCCBsAwggWooAMCAQICEhEhrKTzJoGqMVywoqjNXFnwQTANBgkqhkiG9w0B AQUFADCBljELMAkGA1UEBhMCRlIxGjAYBgNVBAoMEUZyYW5jZSBUZWxlY29tIFNBMSQwIgYD VQQLDBtXZXN0ZXJuRVUgTWlkZGxlRWFzdCBBZnJpY2ExFzAVBgNVBAsMDjAwMDIgMzgwMTI5 ODY2MSwwKgYDVQQDDCNHcm91cGUgRnJhbmNlIFRlbGVjb20gSW50ZXJuYWwgQ0EgMTAeFw0x NzAyMjgwOTQyMDhaFw0yMTAyMjgwOTQyMDhaMGoxCzAJBgNVBAYTAkZSMRowGAYDVQQKExFG cmFuY2UgVGVsZWNvbSBTQTEWMBQGA1UEAwwNTWV1cmljIEp1bGllbjEnMCUGCSqGSIb3DQEJ AQwYanVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA0Pfhby8TRScxVqtTKug3CKgJW1ub3Y7JydhngY8GOXTXy7mUt4aA0V2JsooyqF3+ nO1xcl3D1RZ+l04fRNHCh/CUHhamoNykCFRNoIM/DuzT7NE5h94UR/3RRgZ2qbZoIn5KYIBj bVMacnZnB/qB9DUH61ecMTzrOG0ePtvABWcrhhOZ2S0MvPJkPtAAlL7qvTe9gJwZkBtEuZ0q rJ0D3OXl5ayV7eP9FuRJ/0jf9FdxnmY0Aagm6+r5vsj9dhU9Gf5cA+mh+L7zrCIpTG2GVLLd KaSORJ1cZ+LeZlgpK+hKJ4ho+J/Usqu9Ak8ngAeOgJqTjxRvOimdZZfJ+2E/GQIDAQABo4ID MTCCAy0wDgYDVR0PAQH/BAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCMGA1UdEQQcMBqB GGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCAiEGA1UdHwSCAhgwggIUMIHooIHloIHihoHf bGRhcDovLy9jbj1Hcm91cGUlMjBGcmFuY2UlMjBUZWxlY29tJTIwSW50ZXJuYWwlMjBDQSUy MDEsY249aWdjZ2Z0aSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1mcmFuY2V0ZWxlY29tLERDPWZyP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludDCBqaCBpqCBo4aBoGxkYXA6Ly9pZ2NnZnRpLWNhMS1sZGFwLnNpLmZyYW5jZXRl bGVjb20uZnIvb3U9aWdjZ2Z0aV9jYTEsb3U9Q0Esb3U9Q1JMRFAsb3U9QUNfT04sb3U9SUdD R3JvdXBlLG89RnJhbmNlVGVsZWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Y2xhc3M9cGtpQ2EwNKAyoDCGLmh0dHA6Ly9wa2ktY3JsLml0bi5mdGdyb3VwL2Ny bC9pZ2NnZnRpX2NhMS5jcmwwRaBDoEGGP2h0dHA6Ly9pZ2NnZnRpLWNhMS1odHRwLnNpLmZy YW5jZXRlbGVjb20uZnIvY3JsL2lnY2dmdGlfY2ExLmNybDA+BgNVHSAENzA1MDMGCCqBegEQ DAIDMCcwJQYIKwYBBQUHAgEWGWh0dHA6Ly9wa2ktb3JhbmdlLmNvbS9jcHMwPAYIKwYBBQUH AQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpLW9jc3AuaXRuLmZ0Z3JvdXAvb2NzcDAd BgNVHQ4EFgQUEqE2gJM6hxLi6AlLKQ8kT4r1AlUwHwYDVR0jBBgwFoAUNhwzZ9MTXPpbn+qL ukRmdEbxd3gwDQYJKoZIhvcNAQEFBQADggEBAGxsRCzFlIhen5KnTgZDP6e5jd+ff1MoW3jq wiqxg8v33FldytRqsR5ydg4G5s+mdYhtViuuqm+vOo0F+8oSudj2M70zFIzQR2jMvR8P1oFF 2n+aQlZDW/JY5KqsxbUaR1w5QFE4LCj77OlvTTtaHXn6tZINQqD2rE/28S91ShC4H6WfsTve y2CCLvuYzwUkQ/tPC23rWYxO/hZPkOT/MbgijzIFh4Ys8ENfYNTwkrNSj0LmmJREXIXq50UV EpnsI2v5hE8jXkXlWvT6eXJ7RkocfIjwENvOMvA5/WxE9tvpVCSGq+c5YMWEfyT6o+V2LtTG dtJ3dWNCmsmAgBWXnaswggbAMIIFqKADAgECAhIRIb+AKeqA4nD4aGytIumMzn8wDQYJKoZI hvcNAQEFBQAwgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEk MCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4 MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENBIDEw HhcNMTcwMjI4MDk0MjIxWhcNMjEwMjI4MDk0MjIxWjBqMQswCQYDVQQGEwJGUjEaMBgGA1UE ChMRRnJhbmNlIFRlbGVjb20gU0ExFjAUBgNVBAMMDU1ldXJpYyBKdWxpZW4xJzAlBgkqhkiG 9w0BCQEMGGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMYlaLPYjHfuVjqtO9apWcAd2PIK1MyO7sDYhYw0itPsnsSzsMUa+o7Xjwr/ 9JHcyYEehz2uqzpT0L3bFC8ROTGF3l9sZDPGpUlGeYEFCpNxT2Eg5ZIizYHd5feghGDgbnm0 3UaNldIpi5gtuKSSUHJwLgzZwMykwOdGBkl9dJvj2mccxIlViUATimvjuOj8TES9zrNWuWU7 d1LM9SUrKngkMIA5s801vT4FlvpL/ER7Yt6idZ8rGPXsMdFOhiV3AzLBl1ypaVrQ+OGum/sh c56fMCppmz5okaiGJ2DC9MRR0l4e6ZNrg+nKfm7IhIrCn7wED1TJAfuQfz3YYXKEwO8CAwEA AaOCAzEwggMtMA4GA1UdDwEB/wQEAwIFIDATBgNVHSUEDDAKBggrBgEFBQcDBDAjBgNVHREE HDAagRhqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20wggIhBgNVHR8EggIYMIICFDCB6KCB5aCB 4oaB32xkYXA6Ly8vY249R3JvdXBlJTIwRnJhbmNlJTIwVGVsZWNvbSUyMEludGVybmFsJTIw Q0ElMjAxLGNuPWlnY2dmdGksQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9ZnJhbmNldGVsZWNvbSxEQz1m cj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJp YnV0aW9uUG9pbnQwgamggaaggaOGgaBsZGFwOi8vaWdjZ2Z0aS1jYTEtbGRhcC5zaS5mcmFu Y2V0ZWxlY29tLmZyL291PWlnY2dmdGlfY2ExLG91PUNBLG91PUNSTERQLG91PUFDX09OLG91 PUlHQ0dyb3VwZSxvPUZyYW5jZVRlbGVjb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i YXNlP29iamVjdGNsYXNzPXBraUNhMDSgMqAwhi5odHRwOi8vcGtpLWNybC5pdG4uZnRncm91 cC9jcmwvaWdjZ2Z0aV9jYTEuY3JsMEWgQ6BBhj9odHRwOi8vaWdjZ2Z0aS1jYTEtaHR0cC5z aS5mcmFuY2V0ZWxlY29tLmZyL2NybC9pZ2NnZnRpX2NhMS5jcmwwPgYDVR0gBDcwNTAzBggq gXoBEAwCAjAnMCUGCCsGAQUFBwIBFhlodHRwOi8vcGtpLW9yYW5nZS5jb20vY3BzMDwGCCsG AQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL3BraS1vY3NwLml0bi5mdGdyb3VwL29j c3AwHQYDVR0OBBYEFJpO/hkvlNNchTsRMqcXbFKjr7BjMB8GA1UdIwQYMBaAFDYcM2fTE1z6 W5/qi7pEZnRG8Xd4MA0GCSqGSIb3DQEBBQUAA4IBAQCTgsPIg7wni+YEn7NuxicptWVyoYjn XO9UfYTb4t6M1nizQPrL1ctPCqooEAxUhiH+i8YlnUkG5CHMatTwLtnZJvzGqHkY7q/Ctbki DOqfhaM4b9by+CJp9B5GTKeUzCKAt2Fk0TKqlwbGdKiUfPL9AC58UYOKqjlMUPf6suxqA1fM FyCUBu991kEdwSF7iXbSC/QP2EVsr5Yo1WU9856hAD87Lv/hFp5FjVYKFn9iMQvu325XYLvy EhveODX1HsLj0ohm3/GfPYwyIZpG690uSROq7X8+8WUdX/oplOoaxpEkH5tJO51VAQybQPgj daMD+h/Latx+6W9Dz6oPAxw0MYIEODCCBDQCAQEwga0wgZYxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3Qg QWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5j ZSBUZWxlY29tIEludGVybmFsIENBIDECEhEhrKTzJoGqMVywoqjNXFnwQTANBglghkgBZQME AgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAw MjA1MjEwODU4WjAvBgkqhkiG9w0BCQQxIgQgkud1LoXPkfIFR3BhkvfLkelxMYdCTzqLKHWp 15/hSNQwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwR RnJhbmNlIFRlbGVjb20gU0ExJDAiBgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmlj YTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVs ZWNvbSBJbnRlcm5hbCBDQSAxAhIRIb+AKeqA4nD4aGytIumMzn8wgcAGCyqGSIb3DQEJEAIL MYGwoIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExJDAi BgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmljYTEXMBUGA1UECwwOMDAwMiAzODAx Mjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVsZWNvbSBJbnRlcm5hbCBDQSAxAhIR Ib+AKeqA4nD4aGytIumMzn8wDQYJKoZIhvcNAQEBBQAEggEAfoRzAFo2Q9XWO4bzTmn8Z9D6 XDgl20Br1Dtd25CsQHrIOIFwMvvxaCdfJFoYm93JvEy1kt2JxZxasH/45IIgiC98RKsS32nP 3psMS00oGOtsM16Xq2GLqokflDrikl9yaKGn5f5EBu2morxKNUKBOWx7nsTtdogJG4a/XnuV EyaQSXweQgqt2e4L6SLAl704zSa5igKRJe285nVI8WuSR9tDzaVhz0ByxgidfRXbQDeZsuxH v4Tir1I2rzpV1F+yFUV5LbqcDesB/nx7naesmzWzcE92n6Koz+3QsL5HUGaPEH2JQH4EkWbr 4aGTLVypNeY7DuunqUfzMCB0Kb1IDQAAAAAAAA== --------------ms050308060603080002060402-- From nobody Thu Feb 6 09:36:24 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D951200B9; Thu, 6 Feb 2020 09:36:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158101058299.5078.3200886112217173890@ietfa.amsl.com> Date: Thu, 06 Feb 2020 09:36:23 -0800 Archived-At: Subject: [Pce] I-D Action: draft-li-pce-sr-bidir-path-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 17:36:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths Authors : Cheng Li Mach(Guoyi) Chen Weiqiang Cheng Rakesh Gandhi Quan Xiong Filename : draft-li-pce-sr-bidir-path-07.txt Pages : 16 Date : 2020-02-06 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths in Segment Routing (SR) TE networks. This document defines PCEP extensions for grouping two reverse unidirectional SR Paths into an Associated Bidirectional SR Path when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-li-pce-sr-bidir-path/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-li-pce-sr-bidir-path-07 https://datatracker.ietf.org/doc/html/draft-li-pce-sr-bidir-path-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-li-pce-sr-bidir-path-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 Thu Feb 6 09:41:01 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5D12010F; Thu, 6 Feb 2020 09:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 evypOkpetaRA; Thu, 6 Feb 2020 09:40:58 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E30D12010E; Thu, 6 Feb 2020 09:40:57 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q8so6974164ljj.11; Thu, 06 Feb 2020 09:40:57 -0800 (PST) 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=zMVlAVhOybR8oTooOTJcVTypBFJkW/D+w9AiSwAHd3E=; b=EIAkubSmKl4BJWstd78bCjbUlJsMNgRydvJCDm658u+5bIpo4G4fc/ko6i4+oYndEi fyCQe5Q43dvqZYUmZ0A/RR/ldNugVQ84SXMO5Y5aiFUGpwSBICndJLbtpFV8CrHqAQd2 rffTa5poaY/f9FLE0KzXfbS0+1oDC6kMIxzaVYck/QXL1jRXcHGIRLRMv+dxtcF0tITe UL0G0hJSus2/LXWnymdlf1faqW3/taThRFGBVsEROt8/E9ypflvIwADR5nsf0dTct+R6 fzwbLyZUCptgNcsd7UOO1FMM3Ve2xp1VdloL5/mw3M+xf35nDXaYY3ARmfwLiihIl6hR 67Qw== 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=zMVlAVhOybR8oTooOTJcVTypBFJkW/D+w9AiSwAHd3E=; b=AAlY8hiYWc7sfJ9MBHDePsN2rrGUjSe8QL9MlAdP17LnyHGOWlWjMI2bQ1IWRRGID1 yKRGJPJk8QAtQGHmI2pE+b7+4oKdG5Z35Bstzr9HA0L9SZA5hk0AQMmjejpu3mURsKUf Qr3cR9e5bLwPL802Hzi0PpTpqJHLhuag9Uui8ceP9YYNy9quhLblvtGdSEeTLO6iJtBR udybomg8MfRDoJhX5T/KJ7GKcZUUWhWQZ3HvmdpYoG3iiQD7BcmdDFNRIwPKZCaOr//X w6xnTo3BgyDicQUAyQPbRtXNr5gLSeYcw5Ygv066JIVltGfaaRJDg5PsAuABNyGdOrRh sy1w== X-Gm-Message-State: APjAAAV2LK6ywr9yfl2vk8Qge591QyS9Oa43vk+wbVgXdqmQUxSeM8jp pPf5ylJpGDcHKoXtc4WCLoFzm/MXVA8Mpx4udw== X-Google-Smtp-Source: APXvYqxGd2voCuqgMoe7s9Pxn+MxXhVOCgsOeHrjVjAEI7aLibL+oFUTAvgG95F+wgZA5PLzew6f3wPxULFbuBRFdEs= X-Received: by 2002:a2e:9744:: with SMTP id f4mr2829246ljj.267.1581010855459; Thu, 06 Feb 2020 09:40:55 -0800 (PST) MIME-Version: 1.0 References: <819569dd-0dd9-8980-2235-a2a8e6b70e83@orange.com> In-Reply-To: <819569dd-0dd9-8980-2235-a2a8e6b70e83@orange.com> From: Rakesh Gandhi Date: Thu, 6 Feb 2020 12:40:44 -0500 Message-ID: To: Julien Meuric Cc: pce@ietf.org, draft-li-pce-sr-bidir-path@ietf.org Content-Type: multipart/alternative; boundary="0000000000006cfda7059debc6d8" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 17:41:00 -0000 --0000000000006cfda7059debc6d8 Content-Type: text/plain; charset="UTF-8" Hi Julien, We have posted a revised draft 07 to address the comment on the author list. We plan to address the remained comments in the adopted revision. Please let us know if ok to post draft-ietf-pce-sr-bidir-path-00. There are also htmlized versions available at: https://tools.ietf.org/html/draft-li-pce-sr-bidir-path-07 https://datatracker.ietf.org/doc/html/draft-li-pce-sr-bidir-path-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-li-pce-sr-bidir-path-07 Thanks, Rakesh (behalf of authors) On Wed, Feb 5, 2020 at 4:09 PM wrote: > Hi all, > > This I-D has enough support to be adopted. > > Before we proceed, we'd like to see an update addressing at least the > issue about the number of names on the front page. Authors, please > submit a -07 version accordingly, so that we can move the draft forward. > > Thanks, > > Dhruv & Julien > > > On 17/01/2020 11:12, julien.meuric@orange.com wrote: > > Hi all, > > > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > > Do you believe the I-D is a right foundation for a PCE WG item? Please > > use the PCE mailing list to express your comments, support or > > disagreement, including applicable rationale, especially for the latter. > > > > Thanks, > > > > Dhruv & Julien > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --0000000000006cfda7059debc6d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Julien,
We have posted a revised draft 0= 7 to address the comment on the author list.
We plan to addr= ess the remained comments in the adopted revision.
Please le= t us know if ok to post draft-ietf-pce-sr-bidir-path-00.
Thanks,
Rake= sh (behalf of authors)



On Wed, Feb 5, 20= 20 at 4:09 PM <julien.meuric= @orange.com> wrote:
Hi all,

This I-D has enough support to be adopted.

Before we proceed, we'd like to see an update addressing at least the issue about the number of names on the front page. Authors, please
submit a -07 version accordingly, so that we can move the draft forward.
Thanks,

Dhruv & Julien


On 17/01/2020 11:12, julien.meuric@orange.com wrote:
> Hi all,
>
> It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.=
> Do you believe the I-D is a right foundation for a PCE WG item? Please=
> use the PCE mailing list to express your comments, support or
> disagreement, including applicable rationale, especially for the latte= r.
>
> Thanks,
>
> Dhruv & Julien
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--0000000000006cfda7059debc6d8-- From nobody Fri Feb 7 00:58:52 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4379120143; Fri, 7 Feb 2020 00:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, 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=orange.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 nweuCa43Yx94; Fri, 7 Feb 2020 00:58:49 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D521200DE; Fri, 7 Feb 2020 00:58:48 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 48DTjz24bSz10Fd; Fri, 7 Feb 2020 09:58:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581065927; bh=8Vdm5CyxKxxaHY7bqXayFvHkjvpKwfLebTkgcME2fgE=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=f+/s8+E+x+XRP40J+1OsC9c+9CTtiwDFiHqxbJPNjJg21QaEYrcq7TyK2ZM11kiNw lWANG6al1BzLk1xwE+E4FLZko7/8z0nlUHrLxghooSE8IaAtX8kBiLVv945zBN4UV6 Hmw3NhRgfCzxYHiRmPOMM5FHTSIHVYJI2L2GcyF8Mwha0SjE9VXS+QJB1zUFHJhmWq 3sTqBo8FjnptGyRB2bZYW011wQrlZjc5wmJc9bOhH9qR2o1v3jFGG3R2eRb9GaXpVP ZM8bn2EoGdzIg3Km6qf4SKf/E+GJ2z8V+1gFbP8jMkUmASyoIHQ00dJwug2vwKuWHl l76142mWhJ/5A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 48DTjz1M81zDq9G; Fri, 7 Feb 2020 09:58:47 +0100 (CET) Received: from [10.193.71.21] (10.114.13.247) by exchange-eme6.itn.ftgroup (10.114.13.104) with Microsoft SMTP Server (TLS) id 14.3.468.0; Fri, 7 Feb 2020 09:58:46 +0100 To: Rakesh Gandhi CC: , References: <819569dd-0dd9-8980-2235-a2a8e6b70e83@orange.com> From: Organization: Orange Message-ID: <20962_1581065927_5E3D26C7_20962_123_20_0fc2168b-e272-c28b-2b13-f577a63c6248@orange.com> Date: Fri, 7 Feb 2020 09:58:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.114.13.247] Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 08:58:51 -0000 Hi Rakesh, Thanks for the quick update. We're ready to adopt this version. You may now submit it as draft-ietf-pce-sr-bidir-path-00. Cheers, Dhruv & Julien On 06/02/2020 18:40, Rakesh Gandhi wrote: > Hi Julien, > We have posted a revised draft 07 to address the comment on the author > list. > We plan to address the remained comments in the adopted revision. > Please let us know if ok to post draft-ietf-pce-sr-bidir-path-00. > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-li-pce-sr-bidir-path-07 > https://datatracker.ietf.org/doc/html/draft-li-pce-sr-bidir-path-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-li-pce-sr-bidir-path-07 > > Thanks, > Rakesh (behalf of authors) > > > > On Wed, Feb 5, 2020 at 4:09 PM > wrote: > > Hi all, > > This I-D has enough support to be adopted. > > Before we proceed, we'd like to see an update addressing at least the > issue about the number of names on the front page. Authors, please > submit a -07 version accordingly, so that we can move the draft > forward. > > Thanks, > > Dhruv & Julien > > > On 17/01/2020 11:12, julien.meuric@orange.com > wrote: > > Hi all, > > > > It is time to share your thoughts about > draft-li-pce-sr-bidir-path-06. > > Do you believe the I-D is a right foundation for a PCE WG item? > Please > > use the PCE mailing list to express your comments, support or > > disagreement, including applicable rationale, especially for the > latter. > > > > Thanks, > > > > Dhruv & Julien > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Feb 7 06:17:04 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AD712013A; Fri, 7 Feb 2020 06:17:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158108502322.11714.1431018591356429595@ietfa.amsl.com> Date: Fri, 07 Feb 2020 06:17:03 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-sr-bidir-path-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 14:17:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths Authors : Cheng Li Mach(Guoyi) Chen Weiqiang Cheng Rakesh Gandhi Quan Xiong Filename : draft-ietf-pce-sr-bidir-path-00.txt Pages : 16 Date : 2020-02-07 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths in Segment Routing (SR) TE networks. This document defines PCEP extensions for grouping two reverse unidirectional SR Paths into an Associated Bidirectional SR Path when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-00 https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-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 Fri Feb 7 06:27:43 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62D7120048; Fri, 7 Feb 2020 06:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 F5o_mqxzSvYu; Fri, 7 Feb 2020 06:27:41 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 8552C12013D; Fri, 7 Feb 2020 06:27:40 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id 203so1628583lfa.12; Fri, 07 Feb 2020 06:27:40 -0800 (PST) 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=pwYBe0dY5Y7rh2JhC2S6srd/ZRrbhSy67Fo4Y2U4jTE=; b=i0J8Kb6Hf8LpjHv42DNUCEDWz9HkAEL1v7D7LZqON4OCXogVagUrGYeuVBOOA1tDt4 l/Y6bKqKYo7C32XmM1yqBhZdVoZizmL6u1zAFzglslkxsdB5oHM0P9GZWJ6XJfOqKBLT EdoI6GVevb+P9KZjHrzfIHNVGchUUXdgQMMrDxfecohnGclH0eUnOdOi/UeyCPj3bM6e OM8Thn/dotlEUgmHKEmQSL30nDAXgZysMyzw4wYp+7vwiJglcnEw3h7mMeLBZQ1gZU1k APoPXvm5UMXB8pmWwAd3P04Kji17J7KYtybQHK933zoR2eSjBuJWfAGIPgf+nIw01f0d ezkA== 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=pwYBe0dY5Y7rh2JhC2S6srd/ZRrbhSy67Fo4Y2U4jTE=; b=JDyfR1H86r5cxCHAdvyiQ4FBMZ28YE3GmjMOz3VSQGijw1CYAJhiDGA/qJoXeDzqJe ctdfoHaLY2rRwinsZgNCgO7a4iYZQnDuD2TGyleyltVM+etAeFbKMMWjbz/n/3RAIwZb G+TpjypbjdE1QrcU/pDq9CqheIs9IxfS5jFtyUTeN1VeuRHJxunJHQe3aKMIa792scJ5 B+ijid0KFwZwbLLKqMIuMT/+daIov0EP1NFUhi1znfQ9EUZfV9KJy5hJhUbWwhrHYYnP IE0GSrWQRBtEnoUjtGh0OaqY/jPQloPinAx/RmxO+7N04XfTznMPdKSP7zuFmeuDLcJJ Y9dA== X-Gm-Message-State: APjAAAXXkM6qSDfXwmlHHik1CAdtJrk0d1xDIewIxAiB7fS8DiutDTR3 MsTpan85vYQWSypkAn6xHuAa9fDCK8pIYMpgkQ== X-Google-Smtp-Source: APXvYqxf1fXwqOUGy7gikK3zVn728HnGpZgkWiu7UpozmsL2U5WM83AG3E9bZZPLu2D2HVRuM0h7oBweMHoklBLZJ+0= X-Received: by 2002:a19:7d04:: with SMTP id y4mr4643646lfc.111.1581085658761; Fri, 07 Feb 2020 06:27:38 -0800 (PST) MIME-Version: 1.0 References: <819569dd-0dd9-8980-2235-a2a8e6b70e83@orange.com> <20962_1581065927_5E3D26C7_20962_123_20_0fc2168b-e272-c28b-2b13-f577a63c6248@orange.com> In-Reply-To: <20962_1581065927_5E3D26C7_20962_123_20_0fc2168b-e272-c28b-2b13-f577a63c6248@orange.com> From: Rakesh Gandhi Date: Fri, 7 Feb 2020 09:27:26 -0500 Message-ID: To: Julien Meuric Cc: pce@ietf.org, draft-li-pce-sr-bidir-path@ietf.org Content-Type: multipart/alternative; boundary="0000000000000cd046059dfd3178" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 14:27:43 -0000 --0000000000000cd046059dfd3178 Content-Type: text/plain; charset="UTF-8" Hi Julien, WG, We have posted the draft with new name: https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-00 https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-00 Thanks, Rakesh (behalf of authors) On Fri, Feb 7, 2020 at 3:58 AM wrote: > Hi Rakesh, > > Thanks for the quick update. We're ready to adopt this version. You may > now submit it as draft-ietf-pce-sr-bidir-path-00. > > Cheers, > > Dhruv & Julien > > > On 06/02/2020 18:40, Rakesh Gandhi wrote: > > Hi Julien, > > We have posted a revised draft 07 to address the comment on the author > > list. > > We plan to address the remained comments in the adopted revision. > > Please let us know if ok to post draft-ietf-pce-sr-bidir-path-00. > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-li-pce-sr-bidir-path-07 > > https://datatracker.ietf.org/doc/html/draft-li-pce-sr-bidir-path-07 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-li-pce-sr-bidir-path-07 > > > > Thanks, > > Rakesh (behalf of authors) > > > > > > > > On Wed, Feb 5, 2020 at 4:09 PM > > wrote: > > > > Hi all, > > > > This I-D has enough support to be adopted. > > > > Before we proceed, we'd like to see an update addressing at least the > > issue about the number of names on the front page. Authors, please > > submit a -07 version accordingly, so that we can move the draft > > forward. > > > > Thanks, > > > > Dhruv & Julien > > > > > > On 17/01/2020 11:12, julien.meuric@orange.com > > wrote: > > > Hi all, > > > > > > It is time to share your thoughts about > > draft-li-pce-sr-bidir-path-06. > > > Do you believe the I-D is a right foundation for a PCE WG item? > > Please > > > use the PCE mailing list to express your comments, support or > > > disagreement, including applicable rationale, especially for the > > latter. > > > > > > Thanks, > > > > > > Dhruv & Julien > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@ietf.org > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > --0000000000000cd046059dfd3178 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Julien, WG,
We have posted the draft wit= h new name:

Thanks,=
Rakesh (behalf of authors)


On Fri, Feb 7, 2020 at 3:58 AM <julien.meuric@orange.com> wrote:
Hi Rakesh,

Thanks for the quick update. We're ready to adopt this version. You may=
now submit it as draft-ietf-pce-sr-bidir-path-00.

Cheers,

Dhruv & Julien


On 06/02/2020 18:40, Rakesh Gandhi wrote:
> Hi Julien,
> We have posted a revised draft 07 to address the comment on the author=
> list.
> We plan to address the remained comments in the adopted revision.
> Please let us know if ok to post draft-ietf-pce-sr-bidir-path-00.
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-li-p= ce-sr-bidir-path-07
> https://datatracker.ietf.org= /doc/html/draft-li-pce-sr-bidir-path-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-li-pce-sr-bidir-path-07
>
> Thanks,
> Rakesh (behalf of authors)
>
>
>
> On Wed, Feb 5, 2020 at 4:09 PM <julien.meuric@orange.com
> <mailto:julien.meuric@orange.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi all,
>
>=C2=A0 =C2=A0 =C2=A0This I-D has enough support to be adopted.
>
>=C2=A0 =C2=A0 =C2=A0Before we proceed, we'd like to see an update a= ddressing at least the
>=C2=A0 =C2=A0 =C2=A0issue about the number of names on the front page. = Authors, please
>=C2=A0 =C2=A0 =C2=A0submit a -07 version accordingly, so that we can mo= ve the draft
>=C2=A0 =C2=A0 =C2=A0forward.
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>
>=C2=A0 =C2=A0 =C2=A0Dhruv & Julien
>
>
>=C2=A0 =C2=A0 =C2=A0On 17/01/2020 11:12, julien.meuric@orange.com
>=C2=A0 =C2=A0 =C2=A0<mailto:julien.meuric@orange.com> wrote:
>=C2=A0 =C2=A0 =C2=A0> Hi all,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> It is time to share your thoughts about
>=C2=A0 =C2=A0 =C2=A0draft-li-pce-sr-bidir-path-06.
>=C2=A0 =C2=A0 =C2=A0> Do you believe the I-D is a right foundation f= or a PCE WG item?
>=C2=A0 =C2=A0 =C2=A0Please
>=C2=A0 =C2=A0 =C2=A0> use the PCE mailing list to express your comme= nts, support or
>=C2=A0 =C2=A0 =C2=A0> disagreement, including applicable rationale, = especially for the
>=C2=A0 =C2=A0 =C2=A0latter.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Dhruv & Julien
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0> Pce mailing list
>=C2=A0 =C2=A0 =C2=A0> Pce@ietf.org <mailto:Pce@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/l= istinfo/pce
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Pce mailing list
>=C2=A0 =C2=A0 =C2=A0P= ce@ietf.org <mailto:Pce@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/pce
>


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

--0000000000000cd046059dfd3178-- From nobody Sat Feb 8 08:22:31 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 281DF120047; Sat, 8 Feb 2020 08:22:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158117893808.21727.12205534863212341515@ietfa.amsl.com> Date: Sat, 08 Feb 2020 08:22:18 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-enhanced-errors-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 16:22:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications Authors : Helia Pouyllau Remi Theillaud Julien Meuric Haomian Zheng (Editor) Xian Zhang Filename : draft-ietf-pce-enhanced-errors-07.txt Pages : 22 Date : 2020-02-08 Abstract: This document defines new error and notification TLVs for the PCE Communication Protocol (PCEP) specified in RFC5440, and will update it. It identifies the possible PCEP behaviors in case of error or notification. Thus, this draft defines types of errors and how they are disclosed to other PCEs in order to support predefined PCEP behaviors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-enhanced-errors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-enhanced-errors-07 https://datatracker.ietf.org/doc/html/draft-ietf-pce-enhanced-errors-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-enhanced-errors-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 Tue Feb 11 10:58:25 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EADD31209DB; Tue, 11 Feb 2020 10:58:11 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , db3546@att.com, draft-ietf-pce-association-diversity@ietf.org, pce@ietf.org, pce-chairs@ietf.org, rfc-editor@rfc-editor.org, Julien Meuric , julien.meuric@orange.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158144749195.20027.17641622648895455696.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2020 10:58:11 -0800 Archived-At: Subject: [Pce] Protocol Action: 'Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling' to Proposed Standard (draft-ietf-pce-association-diversity-14.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 18:58:12 -0000 The IESG has approved the following document: - 'Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling' (draft-ietf-pce-association-diversity-14.txt) as Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ Technical Summary This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) Communication Protocol (PCEP) with the purpose of computing diverse paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a PCE that a particular LSP belongs to a disjoint-group, thus the PCE knows that LSPs in the same group need to be disjoint from each other. Working Group Summary Nothing of note. Document Quality At least 3 implementations have been placed on product roadmaps. Personnel Who is the Document Shepherd for this document? Julien Meuric Who is the Responsible Area Director? Deborah Brungard From nobody Wed Feb 12 13:19:10 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F275120954 for ; Wed, 12 Feb 2020 13:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gVOJc0q_4JW for ; Wed, 12 Feb 2020 13:19:04 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 EC5CB120116 for ; Wed, 12 Feb 2020 13:19:03 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id p23so4120723edr.5 for ; Wed, 12 Feb 2020 13:19:03 -0800 (PST) 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=A804XqbD3qtxDsdizNnCuDr+/mhsvrhLskTWFtWk2uk=; b=SOziul2qB6ce5q51RyEVU8KhRYUy4GCdvMnf2it14OUFha95V7xSDV2tjy4of+wQYY Z9tPV/HGznN56Y7V4D0KLPNejRHxuq6fs0IQVt8/076nsgwtbFhIgcdg7Alaz/FWgJBY EmKW4MaA7xhNT5RGO0+JOnJwyCtk4Wrtl+Mmb42FgY/Lfvkaf4iTRMtNf6RWuk93PS5S Ar+NngRfDF0BwDVe2gj3vvhF66AyE4OGMa2RoBEId8V/wxhkP86P6cxcQnoodBz7SHeG HVQG6zu007dxFxOukO5BfvUv5dJ7ovtrhonwglfrpgjYQAYkKYw27uB7UHGR7rsWc+xB uHTw== 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=A804XqbD3qtxDsdizNnCuDr+/mhsvrhLskTWFtWk2uk=; b=lD/orGLbbzVLxdyY0+b/UWhIJVz5NI7Y06pvX3glS8vrRCPVsmf3lqFelQIGImnPcn 4JJRZViskhE8g3OFmZezFCXU+7iDwoUj0p4e/F2RUCtcmLHCM0byFeGAwBiZWOPATzNA KZ3gzgBzPu+GhdpE+9q1DD+PxUWUWgEjMlpyg++QufaYZLlgjTzAVQPThooJoVacxYfU g0FOMXIqyPrNWV8g+BmkAUUoRDCMkLnsVVfIgQulxrUY9Pls1c0kao9B5dpnsTzeWc2+ etr7w4BpFvM4dQfyoYeSbIrM5LHhxAhuTm+qS8HyMrjblufXHy2FxExQIOruQc6I6C50 WO1g== X-Gm-Message-State: APjAAAVY7sAtRVkDE8CLKQ3JEoOIG2pcr8pDo9FP8HofTkRC4rbBo3OD /fOPKAIrDzuTVKyAx5yCF5LOzJ3QQ6y10XHEgH8= X-Google-Smtp-Source: APXvYqznMWgkAdxP4NHQMkr29EBEoOSa7lInuoAFNxUIwSr8bTypGFRP5OLHPlBVWwxt/0QBtaDoE3a2sQh8bMHgsg8= X-Received: by 2002:a17:906:1903:: with SMTP id a3mr13436425eje.102.1581542342251; Wed, 12 Feb 2020 13:19:02 -0800 (PST) MIME-Version: 1.0 References: <89FB1D82-8245-490A-BEF9-6AD5268A3FBC@nokia.com> <5F7FCDF4-0561-46D8-9253-63753704FC7C@nokia.com> In-Reply-To: <5F7FCDF4-0561-46D8-9253-63753704FC7C@nokia.com> From: Cyril Margaria Date: Wed, 12 Feb 2020 21:18:50 +0000 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: Dhruv Dhody , "pce@ietf.org" Content-Type: multipart/alternative; boundary="00000000000081d832059e6785df" Archived-At: Subject: Re: [Pce] Multipath / replication segment comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 21:19:08 -0000 --00000000000081d832059e6785df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please see inline On Thu, 19 Dec 2019 at 17:19, Stone, Andrew (Nokia - CA/Ottawa) < andrew.stone@nokia.com> wrote: > Few comments below, > > Cheers > Andrew > > =EF=BB=BFOn 2019-12-19, 6:52 AM, "Dhruv Dhody" wro= te: > > Hi Andrew, > > Speaking as a WG contributor... > > On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) > wrote: > > > > Hi all, > > > > > > > > In Singapore I made a remark about draft-koldychev-pce-multipath > that it=E2=80=99s a helpful draft and is also applicable to the replicati= on segment. > > > > > > > > I received a follow up question emailed directly, asking about > whether =E2=80=9CEROs need to share same source and destination=E2=80=9D = and how/if this > could be related to RFC 8623. > > > > > > > > For openness, sending my thoughts/comments here to the WG: > > > > > > > > There is no requirement listed in draft-koldychev-pce-multipath tha= t > I can see which requires EROs to terminate on the same source/destination= , > I haven=E2=80=99t seen that expectation anywhere, and in my opinion there= should > not be. > > [Dhruv] You are right, this is not explicit in the I-D. But based on > the scope of past discussion IMHO it was always about multiple paths > (ERO) for a single tunnel and thus finding a way to encode them withi= n > a single report/update in a PCEP message. > > [Andrew] True, the original intent of multiple paths within the same > tunnel in a single report/update, but that could still be leveraged in th= e > replication case, i.e I want a single report/update to modify the state o= f > a replication segment. I think it becomes a gray area in interpretation o= f > whether or not a replication segment creates a P2MP tunnel or if it's > actually just creating multiple P2P tunnels from a single ingress label. = If > the interpretation is it's a P2MP tunnel, then using multiple EROs to > define the forwarding of a P2MP. Tunnel requires those EROs to terminate = on > different nods. > > [Cyril] There is a related work that ties one tunnel to multiple path, list of hops : RFC8697, and draft-ietf-pce-stateful-path-protection-11. Given the mechanism used (and flexibility in term of the individual legs), would it make sense to reuse the path protection mechanisms to tie those multiple EROs together? In addition it addresses the backup path already. Where is the requirement of updating all the segment-list of an SR-Candidate together coming from? On an unrelated note, why is it called Candidate-path and not candidate-multipath, if there are multiple path? > The new ERO-ATTRIB object in the I-D is just a separator between > several ERO objects in a existing PCEP message which reports/update a > particular LSP (identified by PLSP-ID in the LSP object). > > > For example, one of the use cases of draft-koldychev-pce-multipath > is for SR Policy to support multiple SID lists, combine that with use cas= e > such as SR-EPE, you could have multiple SID lists and have weighted ECMP > traffic out different egress nodes intentionally to load balance across > different peer nodes. > > [Dhruv] As per the SR policy as it is currently defined - End point i= s > the property of the SR Policy. Each segment-list inside a candidate > path would be a specific source-routed path from the headend to the > endpoint of the corresponding SR policy. That said, in this use case > perhaps you would use an anycast address but still the same endpoint > from the SR policy point of view. > > > [Andrew] Coincidentally this was just mentioned in SPRING mailing list, > whether in SR Policy endpoint is the tunnel termination vs a prefix/route > to reach (which I kind of have to agree with), which seemed to have been > raised because there's the concept of null/0.0.0.0 (and some wording on > whether or not this is a valid "endpoint"). Anyways, in an EPE case I don= 't > need to specify a path to reach the absolute endpoint, I just need to > specify a path to steer to an egress peer, and with last label in the sta= ck > being an EPE Peer link or node, and that egress peer can take over the > packet (likely not MPLS encaped anymore) and steer, forward or tunnel > however it chooses. In this regard the SID list specified on the headend = SR > Policy "stops early" before the "real endpoint". From this perspective > whether my ECMP SID lists stop on different routers or not is not really > relevant for reaching the "real endpoint". Section 4.7 in > draft-ietf-spring-segment-routing-central-epe-10 briefly comments on this= , > in the sense that to reach an internet route a SID list comprised of only > SID(s) to reach the border node, and a SID to specify the peering router = is > sufficient. In this regard the path terminates on the peering router, > despite the fact that my endpoint is much further in the network / perhap= s > across the internet. > > > > Another example, with ingress replication, is the multipath ERO can > also be re-used to describe the egress downstream paths which will be goi= ng > to different receiver(s), for either further replication or consumption. > > > > > > > > My comment regarding multipath to be used for ingress replication i= s > because there is a need in replication segment to be able to program back= up > paths for each egress ERO. There were comments on this in the earlier > sr-replication draft in spring wg, but appears the wording has been redon= e > / drafts are still in a state of change. None the less, the multipath > backup TLV via the ERO attributes object in draft-koldychev-pce-multipath > permits the relation between the normal ERO and the backup (PCE computed) > ERO, something that the current RFC 8623 does not. There=E2=80=99s a desi= re to > build this into replication segment and draft-hsd-pce-sr-p2mp-policy-01 = is > leveraging this construct (probably need further remarks on this in the > drafts to describe this intention). Comparing to RFC 8623, considering al= l > of the nuances of replication segment (p2mp-lsp-identifier-tlv, > replication-sid/binding-label, backup eros) it seems reasonable to me tha= t > draft-hsd-pce-sr-p2mp-policy defines the replication segment > (draft-hsd-pce-sr-p2mp-policy-01 section 3.3) while leveraging > existing/other common constructs, and defining it=E2=80=99s behaviour, ra= ther than > trying to just use all of RFC8623 and attempt to update and squeeze in (o= r > out) other elements of the RFC. > > > > > > [Dhruv]: For the SR-P2MP usecase you have two building blocks in PCEP > (1) PCEP-SR for P2P (2) PCEP-RSVP-TE for P2MP. I would suggest you to > build on both of these. The (1) offers you SR-ERO, SR-Policy > association etc. The (2) offers you P2MP END-POINT object with > multiple destination, S2LS object to report status to each leaf etc. > > Regarding backup, Protection Association could be used even for P2MP > as well. I would not look only at a feature like 'backup' to make thi= s > fundamental judgment on how to encode SR-P2MP in PCEP. > > I like the fact that as far as PCEP message encoding is concerned, > there is a minimal difference between SR and RSVP-TE. I would like to > see if we can continue to keep that true for SR-P2MP as well :) > > [Andrew] ACK, something I guess that will need to be discussed further in > the shaping of PCEP replication segment draft. Configuring stitched > replication segments (and each replication segment does not perform any > network signalling), one could leverage independent RSVP LSP(s) in betwee= n > replication segments along their unicast path, but it's not clear to me i= f > there could/would/should be RSVP signalling for the replication segment > itself, so I'm not sure how directly mapped to an RSVP use case it is, as > the current focus is SR-MPLS/SRv6-like functionality. Keeping data models > and message encoding the same as much as possible, I do agree with, and t= he > replication segment draft has attempted to do that by re-using the model > encoding from all the previous IETF work. Side note, the separation of th= e > P2MP Policy vs Replication Segment in PCEP is also key to keeping the > solution manageable in PCEP to handle cases of mbb, redundancy and > transport re-usability - it's not clear to me how that split looks like i= f > one were to completely build on the RFC 8623. > > > Thanks! > Dhruv > > > > > Cheers > > > > Andrew > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --00000000000081d832059e6785df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please see inline

On Thu, 19 Dec 2019 at 1= 7:19, Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com> wrote:
Few comments below,

Cheers
Andrew

=EF=BB=BFOn 2019-12-19, 6:52 AM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wr= ote:

=C2=A0 =C2=A0 Hi Andrew,

=C2=A0 =C2=A0 Speaking as a WG contributor...

=C2=A0 =C2=A0 On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ot= tawa)
=C2=A0 =C2=A0 <andrew.stone@nokia.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi all,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In Singapore I made a remark about draft-koldychev-pce-m= ultipath that it=E2=80=99s a helpful draft and is also applicable to the re= plication segment.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I received a follow up question emailed directly, asking= about whether =E2=80=9CEROs need to share same source and destination=E2= =80=9D and how/if this could be related to RFC 8623.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > For openness, sending my thoughts/comments here to the W= G:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > There is no requirement listed in draft-koldychev-pce-mu= ltipath that I can see which requires EROs to terminate on the same source/= destination, I haven=E2=80=99t seen that expectation anywhere, and in my op= inion there should not be.

=C2=A0 =C2=A0 [Dhruv] You are right, this is not explicit in the I-D. But b= ased on
=C2=A0 =C2=A0 the scope of past discussion IMHO it was always about multipl= e paths
=C2=A0 =C2=A0 (ERO) for a single tunnel and thus finding a way to encode th= em within
=C2=A0 =C2=A0 a single report/update in a PCEP message.

[Andrew] True, the original intent of multiple paths within the same tunnel= in a single report/update, but that could still be leveraged in the replic= ation case, i.e I want a single report/update to modify the state of a repl= ication segment. I think it becomes a gray area in interpretation of whethe= r or not a replication segment creates a P2MP tunnel or if it's actuall= y just creating multiple P2P tunnels from a single ingress label. If the in= terpretation is it's a P2MP tunnel, then using multiple EROs to define = the forwarding of a P2MP. Tunnel requires those EROs to terminate on differ= ent nods.

[Cyril] There is a related work that ties one tunnel = to multiple path, list of hops :=C2=A0 RFC8697, and=C2=A0draft-ietf-pce-sta= teful-path-protection-11. Given the mechanism used (and flexibility in term= of the individual legs), would it make sense to reuse the path protection = mechanisms to tie those multiple EROs together? In addition it addresses th= e backup path already.=C2=A0

Where is the requirement of updating al= l the segment-list of an SR-Candidate together coming from?

<= /div><= td style=3D"font-family:"Times New Roman",times,serif;font-size:1= 1pt;vertical-align:top;padding:1px">On an unrelated note, why is it called = Candidate-path and not candidate-multipath, if there are multiple path?

= =C2=A0=C2=A0
=C2=A0 =C2=A0 The new ERO-ATTRIB object in the I-D is just a separator betw= een
=C2=A0 =C2=A0 several ERO objects in a existing PCEP message which reports/= update a
=C2=A0 =C2=A0 particular LSP (identified by PLSP-ID in the LSP object).

=C2=A0 =C2=A0 > For example, one of the use cases of draft-koldychev-pce= -multipath is for SR Policy to support multiple SID lists, combine that wit= h use case such as SR-EPE, you could have multiple SID lists and have weigh= ted ECMP traffic out different egress nodes intentionally to load balance a= cross different peer nodes.

=C2=A0 =C2=A0 [Dhruv] As per the SR policy as it is currently defined - End= point is
=C2=A0 =C2=A0 the property of the SR Policy. Each segment-list inside a can= didate
=C2=A0 =C2=A0 path would be a specific source-routed path from the headend = to the
=C2=A0 =C2=A0 endpoint of the corresponding SR policy. That said, in this u= se case
=C2=A0 =C2=A0 perhaps you would use an anycast address but still the same e= ndpoint
=C2=A0 =C2=A0 from the SR policy point of view.


[Andrew] Coincidentally this was just mentioned in SPRING mailing list, whe= ther in SR Policy endpoint is the tunnel termination vs a prefix/route to r= each (which I kind of have to agree with), which seemed to have been raised= because there's the concept of null/0.0.0.0 (and some wording on whether or n= ot this is a valid "endpoint"). Anyways, in an EPE case I don'= ;t need to specify a path to reach the absolute endpoint, I just need to sp= ecify a path to steer to an egress peer, and with last label in the stack b= eing an EPE Peer link or node, and that egress peer can take over the packe= t (likely not MPLS encaped anymore) and steer, forward or tunnel however it= chooses. In this regard the SID list specified on the headend SR Policy &q= uot;stops early" before the "real endpoint". From this persp= ective whether my ECMP SID lists stop on different routers or not is not re= ally relevant for reaching the "real endpoint". Section 4.7 in dr= aft-ietf-spring-segment-routing-central-epe-10 briefly comments on this, in= the sense that to reach an internet route a SID list comprised of only SID= (s) to reach the border node, and a SID to specify the peering router is su= fficient. In this regard the path terminates on the peering router, despite= the fact that my endpoint is much further in the network / perhaps across = the internet.


=C2=A0 =C2=A0 > Another example, with ingress replication, is the multip= ath ERO can also be re-used to describe the egress downstream paths which w= ill be going to different receiver(s), for either further replication or co= nsumption.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > My comment regarding multipath to be used for ingress re= plication is because there is a need in replication segment to be able to p= rogram backup paths for each egress ERO. There were comments on this in the= earlier sr-replication draft in spring wg, but appears the wording has bee= n redone / drafts are still in a state of change. None the less, the multip= ath backup TLV via the ERO attributes object in draft-koldychev-pce-multipa= th permits the relation between the normal ERO and the backup (PCE computed= ) ERO, something that the current RFC 8623 does not. There=E2=80=99s a desi= re to build this into replication segment and draft-hsd-pce-sr-p2mp-policy-= 01=C2=A0 is leveraging this construct (probably need further remarks on thi= s in the drafts to describe this intention). Comparing to RFC 8623, conside= ring all of the nuances of replication segment (p2mp-lsp-identifier-tlv, re= plication-sid/binding-label, backup eros) it seems reasonable to me that dr= aft-hsd-pce-sr-p2mp-policy defines the replication segment (draft-hsd-pce-s= r-p2mp-policy-01 section 3.3) while leveraging existing/other common constr= ucts, and defining it=E2=80=99s behaviour, rather than trying to just use a= ll of RFC8623 and attempt to update and squeeze in (or out) other elements = of the RFC.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 [Dhruv]: For the SR-P2MP usecase you have two building blocks= in PCEP
=C2=A0 =C2=A0 (1) PCEP-SR for P2P (2) PCEP-RSVP-TE for P2MP. I would sugges= t you to
=C2=A0 =C2=A0 build on both of these. The (1) offers you SR-ERO, SR-Policy<= br> =C2=A0 =C2=A0 association etc. The (2) offers you P2MP END-POINT object wit= h
=C2=A0 =C2=A0 multiple destination, S2LS object to report status to each le= af etc.

=C2=A0 =C2=A0 Regarding backup, Protection Association could be used even f= or P2MP
=C2=A0 =C2=A0 as well. I would not look only at a feature like 'backup&= #39; to make this
=C2=A0 =C2=A0 fundamental judgment on how to encode SR-P2MP in PCEP.

=C2=A0 =C2=A0 I like the fact that as far as PCEP message encoding is conce= rned,
=C2=A0 =C2=A0 there is a minimal difference between SR and RSVP-TE. I would= like to
=C2=A0 =C2=A0 see if we can continue to keep that true for SR-P2MP as well = :)

[Andrew] ACK, something I guess that will need to be discussed further in t= he shaping of PCEP replication segment draft. Configuring stitched replicat= ion segments (and each replication segment does not perform any network sig= nalling), one could leverage independent RSVP LSP(s) in between replication= segments along their unicast path, but it's not clear to me if there c= ould/would/should be RSVP signalling for the replication segment itself, so= I'm not sure how directly mapped to an RSVP use case it is, as the cur= rent focus is SR-MPLS/SRv6-like functionality. Keeping data models and mess= age encoding the same as much as possible, I do agree with, and the replica= tion segment draft has attempted to do that by re-using the model encoding = from all the previous IETF work. Side note, the separation of the P2MP Poli= cy vs Replication Segment in PCEP is also key to keeping the solution manag= eable in PCEP to handle cases of mbb, redundancy and transport re-usability= - it's not clear to me how that split looks like if one were to comple= tely build on the RFC 8623.


=C2=A0 =C2=A0 Thanks!
=C2=A0 =C2=A0 Dhruv

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Cheers
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Andrew
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Pce mailing list
=C2=A0 =C2=A0 > Pce@ie= tf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/pc= e


_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--00000000000081d832059e6785df-- From nobody Wed Feb 12 14:45:26 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73720120019 for ; Wed, 12 Feb 2020 14:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 bHWblAQFncp4 for ; Wed, 12 Feb 2020 14:45:22 -0800 (PST) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 E15FC120013 for ; Wed, 12 Feb 2020 14:45:21 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id j11so1968470ybt.8 for ; Wed, 12 Feb 2020 14:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=bjl/GEbCHbZRSGGeas/tGPVUvs2FZlGXMeZyPbcWAWo=; b=CwQIXGJ2dtaNEAGoQCWZWbRcEu4bLTfl41U0g34PztNcUb60f+EYNAs2ksGPoQclv2 AliiAJNu47r6PoM6r5lSQ9WxNQN4swpnWuQfmmyRWvbRi9pcOj56ot+cGElKYDc6/pkD +lVx5BD+U2F8YIIa4t771fKciVFGOSdUmxdOj4Fhb5ouClmZp/DqyGUfJJJvq1WRKWrO SjCVuHMfQaXgEaMURtyUmsjPdMs45+wnCIjEsNooc90giI03WQnhKC01hxtF7KAbr4Mh 3b4LFFUxmEut/jhGC9giwiYuOEqOM7DSeD39wvh9GuV4c/BT0kauB9l7k/bPsXeHBaXf 97pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=bjl/GEbCHbZRSGGeas/tGPVUvs2FZlGXMeZyPbcWAWo=; b=O5zvxc/dBAYPTvVkWWmheyfvjf2rauGTfFwVYp6rRGxMV0/0Uc5IIUVEWRrp30r23c hDdJ2Dy9LnnwdmcZlQbAiIxAVjyHDvt0Uphn7tG10557LS4aDRV0lQhAxnLtNSMp+ZZJ ULVUDsUSbQ79hGLmYemRVdAwNzY497j+3wPpC7K1vBJSXgfpI6rTtsbSBMTNjPE2+EH6 5d9SiO+2DhUBP7vSOo5RsWMJ/z+EgRHYDfhL5IhXaDKZBkkTcv50oR8M5WN3PXsyc6SQ oDb7A5wz4ivs20UMObFxjm5si4WEoe1wsgyxVq3JQEUh/DMQZx5EY4//pasJGEIB/XuP xAbA== X-Gm-Message-State: APjAAAVbH4eCYviAp0XZAVmqThqQiFeSDJWPAYqm1XpuYD1eF7ma/Jkx fU5mqNJ9uABT68DtxgotDFA= X-Google-Smtp-Source: APXvYqwLHHdWIjAlxuI/s2HV1UOTj4GZNHDmpiFx29Ozgafl+ezErT1Gvz87haNBfFqr9EOJ2wa4qQ== X-Received: by 2002:a25:2e0e:: with SMTP id u14mr13847647ybu.16.1581547520957; Wed, 12 Feb 2020 14:45:20 -0800 (PST) Received: from MN2PR19MB3167.namprd19.prod.outlook.com ([2603:1036:302:409e::5]) by smtp.gmail.com with ESMTPSA id o4sm217482ywd.5.2020.02.12.14.45.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Feb 2020 14:45:19 -0800 (PST) From: Tarek Saad To: Cyril Margaria , "Stone, Andrew (Nokia - CA/Ottawa)" CC: "pce@ietf.org" Thread-Topic: [Pce] Multipath / replication segment comment Thread-Index: AUMyRjQyAyA3OATfKhhztsfrjcHN1lFmM0IxQzM1NDRRM2V3d54w+Vhm X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 12 Feb 2020 22:45:17 +0000 Message-ID: References: <89FB1D82-8245-490A-BEF9-6AD5268A3FBC@nokia.com> <5F7FCDF4-0561-46D8-9253-63753704FC7C@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_MN2PR19MB31676F98A15367281D259698FC1B0MN2PR19MB3167namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Multipath / replication segment comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 22:45:24 -0000 --_000_MN2PR19MB31676F98A15367281D259698FC1B0MN2PR19MB3167namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpTb21lIGlucHV0IGlubGluZS4uDQoNCkZyb206IFBjZSA8cGNlLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDeXJpbCBNYXJnYXJpYSA8Y3lyaWwubWFyZ2FyaWFAZ21h aWwuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAyMCBhdCA0OjE5IFBNDQpU bzogIlN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSIgPGFuZHJldy5zdG9uZUBub2tp YS5jb20+DQpDYzogInBjZUBpZXRmLm9yZyIgPHBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb UGNlXSBNdWx0aXBhdGggLyByZXBsaWNhdGlvbiBzZWdtZW50IGNvbW1lbnQNCg0KUGxlYXNlIHNl ZSBpbmxpbmUNCg0KT24gVGh1LCAxOSBEZWMgMjAxOSBhdCAxNzoxOSwgU3RvbmUsIEFuZHJldyAo Tm9raWEgLSBDQS9PdHRhd2EpIDxhbmRyZXcuc3RvbmVAbm9raWEuY29tPG1haWx0bzphbmRyZXcu c3RvbmVAbm9raWEuY29tPj4gd3JvdGU6DQpGZXcgY29tbWVudHMgYmVsb3csDQoNCkNoZWVycw0K QW5kcmV3DQoNCu+7v09uIDIwMTktMTItMTksIDY6NTIgQU0sICJEaHJ1diBEaG9keSIgPGRocnV2 LmlldGZAZ21haWwuY29tPG1haWx0bzpkaHJ1di5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQog ICAgSGkgQW5kcmV3LA0KDQogICAgU3BlYWtpbmcgYXMgYSBXRyBjb250cmlidXRvci4uLg0KDQog ICAgT24gV2VkLCBEZWMgMTgsIDIwMTkgYXQgMTE6NTggUE0gU3RvbmUsIEFuZHJldyAoTm9raWEg LSBDQS9PdHRhd2EpDQogICAgPGFuZHJldy5zdG9uZUBub2tpYS5jb208bWFpbHRvOmFuZHJldy5z dG9uZUBub2tpYS5jb20+PiB3cm90ZToNCiAgICA+DQogICAgPiBIaSBhbGwsDQogICAgPg0KICAg ID4NCiAgICA+DQogICAgPiBJbiBTaW5nYXBvcmUgSSBtYWRlIGEgcmVtYXJrIGFib3V0IGRyYWZ0 LWtvbGR5Y2hldi1wY2UtbXVsdGlwYXRoIHRoYXQgaXTigJlzIGEgaGVscGZ1bCBkcmFmdCBhbmQg aXMgYWxzbyBhcHBsaWNhYmxlIHRvIHRoZSByZXBsaWNhdGlvbiBzZWdtZW50Lg0KICAgID4NCiAg ICA+DQogICAgPg0KICAgID4gSSByZWNlaXZlZCBhIGZvbGxvdyB1cCBxdWVzdGlvbiBlbWFpbGVk IGRpcmVjdGx5LCBhc2tpbmcgYWJvdXQgd2hldGhlciDigJxFUk9zIG5lZWQgdG8gc2hhcmUgc2Ft ZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9u4oCdIGFuZCBob3cvaWYgdGhpcyBjb3VsZCBiZSByZWxh dGVkIHRvIFJGQyA4NjIzLg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gRm9yIG9wZW5uZXNz LCBzZW5kaW5nIG15IHRob3VnaHRzL2NvbW1lbnRzIGhlcmUgdG8gdGhlIFdHOg0KICAgID4NCiAg ICA+DQogICAgPg0KICAgID4gVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgbGlzdGVkIGluIGRyYWZ0 LWtvbGR5Y2hldi1wY2UtbXVsdGlwYXRoIHRoYXQgSSBjYW4gc2VlIHdoaWNoIHJlcXVpcmVzIEVS T3MgdG8gdGVybWluYXRlIG9uIHRoZSBzYW1lIHNvdXJjZS9kZXN0aW5hdGlvbiwgSSBoYXZlbuKA mXQgc2VlbiB0aGF0IGV4cGVjdGF0aW9uIGFueXdoZXJlLCBhbmQgaW4gbXkgb3BpbmlvbiB0aGVy ZSBzaG91bGQgbm90IGJlLg0KDQogICAgW0RocnV2XSBZb3UgYXJlIHJpZ2h0LCB0aGlzIGlzIG5v dCBleHBsaWNpdCBpbiB0aGUgSS1ELiBCdXQgYmFzZWQgb24NCiAgICB0aGUgc2NvcGUgb2YgcGFz dCBkaXNjdXNzaW9uIElNSE8gaXQgd2FzIGFsd2F5cyBhYm91dCBtdWx0aXBsZSBwYXRocw0KICAg IChFUk8pIGZvciBhIHNpbmdsZSB0dW5uZWwgYW5kIHRodXMgZmluZGluZyBhIHdheSB0byBlbmNv ZGUgdGhlbSB3aXRoaW4NCiAgICBhIHNpbmdsZSByZXBvcnQvdXBkYXRlIGluIGEgUENFUCBtZXNz YWdlLg0KDQpbQW5kcmV3XSBUcnVlLCB0aGUgb3JpZ2luYWwgaW50ZW50IG9mIG11bHRpcGxlIHBh dGhzIHdpdGhpbiB0aGUgc2FtZSB0dW5uZWwgaW4gYSBzaW5nbGUgcmVwb3J0L3VwZGF0ZSwgYnV0 IHRoYXQgY291bGQgc3RpbGwgYmUgbGV2ZXJhZ2VkIGluIHRoZSByZXBsaWNhdGlvbiBjYXNlLCBp LmUgSSB3YW50IGEgc2luZ2xlIHJlcG9ydC91cGRhdGUgdG8gbW9kaWZ5IHRoZSBzdGF0ZSBvZiBh IHJlcGxpY2F0aW9uIHNlZ21lbnQuIEkgdGhpbmsgaXQgYmVjb21lcyBhIGdyYXkgYXJlYSBpbiBp bnRlcnByZXRhdGlvbiBvZiB3aGV0aGVyIG9yIG5vdCBhIHJlcGxpY2F0aW9uIHNlZ21lbnQgY3Jl YXRlcyBhIFAyTVAgdHVubmVsIG9yIGlmIGl0J3MgYWN0dWFsbHkganVzdCBjcmVhdGluZyBtdWx0 aXBsZSBQMlAgdHVubmVscyBmcm9tIGEgc2luZ2xlIGluZ3Jlc3MgbGFiZWwuIElmIHRoZSBpbnRl cnByZXRhdGlvbiBpcyBpdCdzIGEgUDJNUCB0dW5uZWwsIHRoZW4gdXNpbmcgbXVsdGlwbGUgRVJP cyB0byBkZWZpbmUgdGhlIGZvcndhcmRpbmcgb2YgYSBQMk1QLiBUdW5uZWwgcmVxdWlyZXMgdGhv c2UgRVJPcyB0byB0ZXJtaW5hdGUgb24gZGlmZmVyZW50IG5vZHMuDQpbQ3lyaWxdIFRoZXJlIGlz IGEgcmVsYXRlZCB3b3JrIHRoYXQgdGllcyBvbmUgdHVubmVsIHRvIG11bHRpcGxlIHBhdGgsIGxp c3Qgb2YgaG9wcyA6ICBSRkM4Njk3LCBhbmQgZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGF0aC1w cm90ZWN0aW9uLTExLiBHaXZlbiB0aGUgbWVjaGFuaXNtIHVzZWQgKGFuZCBmbGV4aWJpbGl0eSBp biB0ZXJtIG9mIHRoZSBpbmRpdmlkdWFsIGxlZ3MpLCB3b3VsZCBpdCBtYWtlIHNlbnNlIHRvIHJl dXNlIHRoZSBwYXRoIHByb3RlY3Rpb24gbWVjaGFuaXNtcyB0byB0aWUgdGhvc2UgbXVsdGlwbGUg RVJPcyB0b2dldGhlcj8gSW4gYWRkaXRpb24gaXQgYWRkcmVzc2VzIHRoZSBiYWNrdXAgcGF0aCBh bHJlYWR5Lg0KDQpbVFNdOiBDb25zaWRlciB0aGUgY2FzZSBvZiBhIFBDRSBkZWxlZ2F0ZWQgU1Ig UG9saWN5IENhbmRpZGF0ZSBQYXRoLiBUaGUgUENDIGRlc2lyZXMgYW4gU1IgcGF0aCBjb21wdXRh dGlvbiBmcm9tIGEgUENFIHRoYXQgaXMgc3ViamVjdCB0byBjb25zdHJhaW50cyDigJMgVGhlIFBD QyBoYXMgbm8gYS1wcmlvcmkgaWRlYSAqKmhvdyBtYW55KiogU2VnbWVudC1MaXN0cyAoU0xzKSB0 aGUgUENFIHBhdGggY29tcHV0YXRpb24gd2lsbCByZXN1bHQgaW4tLSBzbyBpdCBkb2VzIG5vdCBr bm93IGhvdyBtYW55IChvciB3aGV0aGVyIGl0IHNob3VsZCBhdCBhbGwpIGNyZWF0ZSBtdWx0aXBs ZSBQTFNQcyB3aXRoIE5PLUVSTyBhbmQgcmVwb3J0IHRoZW0gc28gUENFIGNhbiByZXNwb25kIHRv IGVhY2guDQpUaGUgUENDIGNyZWF0ZXMgKm9uZSogUExTUCBhbmQgcmVwb3J0cyB0byB0aGUgUENF IHRoZSBMU1AgZG93biAod2l0aCBOTy1FUk8pIGFsb25nIHdpdGggdGhlIHNwZWNpZmllZCB1c2Vy IGNvbnN0cmFpbnRzLiBUaGUgUENFIGNvbXB1dGVzIGFuZCBkZXRlcm1pbmVzIHRoZSBmZWFzaWJs ZSBudW1iZXIgb2YgU0xzLiBOb3csIGl0IHdvdWxkIGJlIGF3a3dhcmQgZm9yIHRoZSBQQ0UgdG8g aW5zdGFudGlhdGUgUExTUHMg4oCTIGRpZmZlcmVudCBmcm9tIHRoZSBvbmUgb3JpZ2luYWxseSBk ZWxlZ2F0ZWQgYnkgdGhlIFBDQ+KAlHNvIHRvIGVuY29kZSBlYWNoIFNMIGluIGl0cyBvd24gUExT UCBhbmQgbWFrZSB1c2UgdGhlIOKAnGFzc29jaWF0aW9uIG9iamVjdOKAnSBtZXRob2QuLiBJIGNh biBhbHNvIGltYWdpbmUgY29tcGxleGl0aWVzIGluIHdoYXQgZWFjaCBQTFNQIExTUCB3b3VsZCBj YXJyeSBpbiB0ZXJtcyBvZiBjb25zdHJhaW50cyDigJMgZXNwZWNpYWxseSBhZnRlciBzb21lIGNv bmZpZ3VyYXRpb24gY2hhbmdlIG9uIHRoZSBQQ0PigKYNCg0KVGhlIHByb3Bvc2FsIGluIGRyYWZ0 LWtvbGR5Y2hldi1wY2UtbXVsdGlwYXRoIGluZGVlZCBwcm9wb3NlcyBlbGVnYW50IHdheSB0byBl bmNvZGUgYWxsIGNvbXB1dGVkIFNMcyAoYXMgbXVsdGlwbGUgU0VSTyBsaXN0cykgaW50byBhIHNp bmdsZSBQTFNQIOKAkyB0aGUgb25lIG9yaWdpbmFsbHkgcmVwb3J0ZWQgYnkgdGhlIGRlbGVnYXRl ZCBQTFNQLiBJbiBmYWN0LCB0aGlzIG1ldGhvZCBhbGxvd3MgYXQgYW55dGltZSB0aGUgUENFIHRv IHNlbmQgUENVcGQgdG8gYWRkL3JlbW92ZS91cGRhdGUgU0wocykgd2l0aGluIGEgc2luZ2xlIFBM U1AgZnJlZWx5IOKAkyB3aGljaCBJTU8gaXMgcG93ZXJmdWwuDQoNCkkgdGhpbmsgdGhlIHNhbWUg YXJndW1lbnQgYXBwbGllcyB0byBiYWNrdXAgcGF0aHMvU0xzIHRvby4uIFRoZSBQQ0Mgd291bGQg bm90IGtub3cgaG93IG1hbnkgU0wocykgY2FuIHByb3RlY3QgYSBzaW5nbGUgcGF0aCwgc28gaXQg d291bGQgbm90IGJlIGFibGUgdG8gYS1wcmlvcmkgY3JlYXRlIFBMU1BzIGFuZCB1c2UgYXNzb2Np YXRpb24gb2JqZWN0Lg0KDQpXaGVyZSBpcyB0aGUgcmVxdWlyZW1lbnQgb2YgdXBkYXRpbmcgYWxs IHRoZSBzZWdtZW50LWxpc3Qgb2YgYW4gU1ItQ2FuZGlkYXRlIHRvZ2V0aGVyIGNvbWluZyBmcm9t Pw0KDQpPbiBhbiB1bnJlbGF0ZWQgbm90ZSwgd2h5IGlzIGl0IGNhbGxlZCBDYW5kaWRhdGUtcGF0 aCBhbmQgbm90IGNhbmRpZGF0ZS1tdWx0aXBhdGgsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBwYXRo Pw0KDQpbVFNdOiBwbGVhc2UgcmVmZXIgdG8gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLXBvbGljeSB3aGljaCBkZWZpbmVzIHN1Y2ggdGVybXPigKYNCg0KUmVnYXJkcywNClRhcmVr DQoNCg0KDQogICAgVGhlIG5ldyBFUk8tQVRUUklCIG9iamVjdCBpbiB0aGUgSS1EIGlzIGp1c3Qg YSBzZXBhcmF0b3IgYmV0d2Vlbg0KICAgIHNldmVyYWwgRVJPIG9iamVjdHMgaW4gYSBleGlzdGlu ZyBQQ0VQIG1lc3NhZ2Ugd2hpY2ggcmVwb3J0cy91cGRhdGUgYQ0KICAgIHBhcnRpY3VsYXIgTFNQ IChpZGVudGlmaWVkIGJ5IFBMU1AtSUQgaW4gdGhlIExTUCBvYmplY3QpLg0KDQogICAgPiBGb3Ig ZXhhbXBsZSwgb25lIG9mIHRoZSB1c2UgY2FzZXMgb2YgZHJhZnQta29sZHljaGV2LXBjZS1tdWx0 aXBhdGggaXMgZm9yIFNSIFBvbGljeSB0byBzdXBwb3J0IG11bHRpcGxlIFNJRCBsaXN0cywgY29t YmluZSB0aGF0IHdpdGggdXNlIGNhc2Ugc3VjaCBhcyBTUi1FUEUsIHlvdSBjb3VsZCBoYXZlIG11 bHRpcGxlIFNJRCBsaXN0cyBhbmQgaGF2ZSB3ZWlnaHRlZCBFQ01QIHRyYWZmaWMgb3V0IGRpZmZl cmVudCBlZ3Jlc3Mgbm9kZXMgaW50ZW50aW9uYWxseSB0byBsb2FkIGJhbGFuY2UgYWNyb3NzIGRp ZmZlcmVudCBwZWVyIG5vZGVzLg0KDQogICAgW0RocnV2XSBBcyBwZXIgdGhlIFNSIHBvbGljeSBh cyBpdCBpcyBjdXJyZW50bHkgZGVmaW5lZCAtIEVuZCBwb2ludCBpcw0KICAgIHRoZSBwcm9wZXJ0 eSBvZiB0aGUgU1IgUG9saWN5LiBFYWNoIHNlZ21lbnQtbGlzdCBpbnNpZGUgYSBjYW5kaWRhdGUN CiAgICBwYXRoIHdvdWxkIGJlIGEgc3BlY2lmaWMgc291cmNlLXJvdXRlZCBwYXRoIGZyb20gdGhl IGhlYWRlbmQgdG8gdGhlDQogICAgZW5kcG9pbnQgb2YgdGhlIGNvcnJlc3BvbmRpbmcgU1IgcG9s aWN5LiBUaGF0IHNhaWQsIGluIHRoaXMgdXNlIGNhc2UNCiAgICBwZXJoYXBzIHlvdSB3b3VsZCB1 c2UgYW4gYW55Y2FzdCBhZGRyZXNzIGJ1dCBzdGlsbCB0aGUgc2FtZSBlbmRwb2ludA0KICAgIGZy b20gdGhlIFNSIHBvbGljeSBwb2ludCBvZiB2aWV3Lg0KDQoNCltBbmRyZXddIENvaW5jaWRlbnRh bGx5IHRoaXMgd2FzIGp1c3QgbWVudGlvbmVkIGluIFNQUklORyBtYWlsaW5nIGxpc3QsIHdoZXRo ZXIgaW4gU1IgUG9saWN5IGVuZHBvaW50IGlzIHRoZSB0dW5uZWwgdGVybWluYXRpb24gdnMgYSBw cmVmaXgvcm91dGUgdG8gcmVhY2ggKHdoaWNoIEkga2luZCBvZiBoYXZlIHRvIGFncmVlIHdpdGgp LCB3aGljaCBzZWVtZWQgdG8gaGF2ZSBiZWVuIHJhaXNlZCBiZWNhdXNlIHRoZXJlJ3MgdGhlIGNv bmNlcHQgb2YgbnVsbC8wLjAuMC4wPGh0dHA6Ly8wLjAuMC4wPiAoYW5kIHNvbWUgd29yZGluZyBv biB3aGV0aGVyIG9yIG5vdCB0aGlzIGlzIGEgdmFsaWQgImVuZHBvaW50IikuIEFueXdheXMsIGlu IGFuIEVQRSBjYXNlIEkgZG9uJ3QgbmVlZCB0byBzcGVjaWZ5IGEgcGF0aCB0byByZWFjaCB0aGUg YWJzb2x1dGUgZW5kcG9pbnQsIEkganVzdCBuZWVkIHRvIHNwZWNpZnkgYSBwYXRoIHRvIHN0ZWVy IHRvIGFuIGVncmVzcyBwZWVyLCBhbmQgd2l0aCBsYXN0IGxhYmVsIGluIHRoZSBzdGFjayBiZWlu ZyBhbiBFUEUgUGVlciBsaW5rIG9yIG5vZGUsIGFuZCB0aGF0IGVncmVzcyBwZWVyIGNhbiB0YWtl IG92ZXIgdGhlIHBhY2tldCAobGlrZWx5IG5vdCBNUExTIGVuY2FwZWQgYW55bW9yZSkgYW5kIHN0 ZWVyLCBmb3J3YXJkIG9yIHR1bm5lbCBob3dldmVyIGl0IGNob29zZXMuIEluIHRoaXMgcmVnYXJk IHRoZSBTSUQgbGlzdCBzcGVjaWZpZWQgb24gdGhlIGhlYWRlbmQgU1IgUG9saWN5ICJzdG9wcyBl YXJseSIgYmVmb3JlIHRoZSAicmVhbCBlbmRwb2ludCIuIEZyb20gdGhpcyBwZXJzcGVjdGl2ZSB3 aGV0aGVyIG15IEVDTVAgU0lEIGxpc3RzIHN0b3Agb24gZGlmZmVyZW50IHJvdXRlcnMgb3Igbm90 IGlzIG5vdCByZWFsbHkgcmVsZXZhbnQgZm9yIHJlYWNoaW5nIHRoZSAicmVhbCBlbmRwb2ludCIu IFNlY3Rpb24gNC43IGluIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFs LWVwZS0xMCBicmllZmx5IGNvbW1lbnRzIG9uIHRoaXMsIGluIHRoZSBzZW5zZSB0aGF0IHRvIHJl YWNoIGFuIGludGVybmV0IHJvdXRlIGEgU0lEIGxpc3QgY29tcHJpc2VkIG9mIG9ubHkgU0lEKHMp IHRvIHJlYWNoIHRoZSBib3JkZXIgbm9kZSwgYW5kIGEgU0lEIHRvIHNwZWNpZnkgdGhlIHBlZXJp bmcgcm91dGVyIGlzIHN1ZmZpY2llbnQuIEluIHRoaXMgcmVnYXJkIHRoZSBwYXRoIHRlcm1pbmF0 ZXMgb24gdGhlIHBlZXJpbmcgcm91dGVyLCBkZXNwaXRlIHRoZSBmYWN0IHRoYXQgbXkgZW5kcG9p bnQgaXMgbXVjaCBmdXJ0aGVyIGluIHRoZSBuZXR3b3JrIC8gcGVyaGFwcyBhY3Jvc3MgdGhlIGlu dGVybmV0Lg0KDQoNCiAgICA+IEFub3RoZXIgZXhhbXBsZSwgd2l0aCBpbmdyZXNzIHJlcGxpY2F0 aW9uLCBpcyB0aGUgbXVsdGlwYXRoIEVSTyBjYW4gYWxzbyBiZSByZS11c2VkIHRvIGRlc2NyaWJl IHRoZSBlZ3Jlc3MgZG93bnN0cmVhbSBwYXRocyB3aGljaCB3aWxsIGJlIGdvaW5nIHRvIGRpZmZl cmVudCByZWNlaXZlcihzKSwgZm9yIGVpdGhlciBmdXJ0aGVyIHJlcGxpY2F0aW9uIG9yIGNvbnN1 bXB0aW9uLg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gTXkgY29tbWVudCByZWdhcmRpbmcg bXVsdGlwYXRoIHRvIGJlIHVzZWQgZm9yIGluZ3Jlc3MgcmVwbGljYXRpb24gaXMgYmVjYXVzZSB0 aGVyZSBpcyBhIG5lZWQgaW4gcmVwbGljYXRpb24gc2VnbWVudCB0byBiZSBhYmxlIHRvIHByb2dy YW0gYmFja3VwIHBhdGhzIGZvciBlYWNoIGVncmVzcyBFUk8uIFRoZXJlIHdlcmUgY29tbWVudHMg b24gdGhpcyBpbiB0aGUgZWFybGllciBzci1yZXBsaWNhdGlvbiBkcmFmdCBpbiBzcHJpbmcgd2cs IGJ1dCBhcHBlYXJzIHRoZSB3b3JkaW5nIGhhcyBiZWVuIHJlZG9uZSAvIGRyYWZ0cyBhcmUgc3Rp bGwgaW4gYSBzdGF0ZSBvZiBjaGFuZ2UuIE5vbmUgdGhlIGxlc3MsIHRoZSBtdWx0aXBhdGggYmFj a3VwIFRMViB2aWEgdGhlIEVSTyBhdHRyaWJ1dGVzIG9iamVjdCBpbiBkcmFmdC1rb2xkeWNoZXYt cGNlLW11bHRpcGF0aCBwZXJtaXRzIHRoZSByZWxhdGlvbiBiZXR3ZWVuIHRoZSBub3JtYWwgRVJP IGFuZCB0aGUgYmFja3VwIChQQ0UgY29tcHV0ZWQpIEVSTywgc29tZXRoaW5nIHRoYXQgdGhlIGN1 cnJlbnQgUkZDIDg2MjMgZG9lcyBub3QuIFRoZXJl4oCZcyBhIGRlc2lyZSB0byBidWlsZCB0aGlz IGludG8gcmVwbGljYXRpb24gc2VnbWVudCBhbmQgZHJhZnQtaHNkLXBjZS1zci1wMm1wLXBvbGlj eS0wMSAgaXMgbGV2ZXJhZ2luZyB0aGlzIGNvbnN0cnVjdCAocHJvYmFibHkgbmVlZCBmdXJ0aGVy IHJlbWFya3Mgb24gdGhpcyBpbiB0aGUgZHJhZnRzIHRvIGRlc2NyaWJlIHRoaXMgaW50ZW50aW9u KS4gQ29tcGFyaW5nIHRvIFJGQyA4NjIzLCBjb25zaWRlcmluZyBhbGwgb2YgdGhlIG51YW5jZXMg b2YgcmVwbGljYXRpb24gc2VnbWVudCAocDJtcC1sc3AtaWRlbnRpZmllci10bHYsIHJlcGxpY2F0 aW9uLXNpZC9iaW5kaW5nLWxhYmVsLCBiYWNrdXAgZXJvcykgaXQgc2VlbXMgcmVhc29uYWJsZSB0 byBtZSB0aGF0IGRyYWZ0LWhzZC1wY2Utc3ItcDJtcC1wb2xpY3kgZGVmaW5lcyB0aGUgcmVwbGlj YXRpb24gc2VnbWVudCAoZHJhZnQtaHNkLXBjZS1zci1wMm1wLXBvbGljeS0wMSBzZWN0aW9uIDMu Mykgd2hpbGUgbGV2ZXJhZ2luZyBleGlzdGluZy9vdGhlciBjb21tb24gY29uc3RydWN0cywgYW5k IGRlZmluaW5nIGl04oCZcyBiZWhhdmlvdXIsIHJhdGhlciB0aGFuIHRyeWluZyB0byBqdXN0IHVz ZSBhbGwgb2YgUkZDODYyMyBhbmQgYXR0ZW1wdCB0byB1cGRhdGUgYW5kIHNxdWVlemUgaW4gKG9y IG91dCkgb3RoZXIgZWxlbWVudHMgb2YgdGhlIFJGQy4NCiAgICA+DQogICAgPg0KDQogICAgW0Ro cnV2XTogRm9yIHRoZSBTUi1QMk1QIHVzZWNhc2UgeW91IGhhdmUgdHdvIGJ1aWxkaW5nIGJsb2Nr cyBpbiBQQ0VQDQogICAgKDEpIFBDRVAtU1IgZm9yIFAyUCAoMikgUENFUC1SU1ZQLVRFIGZvciBQ Mk1QLiBJIHdvdWxkIHN1Z2dlc3QgeW91IHRvDQogICAgYnVpbGQgb24gYm90aCBvZiB0aGVzZS4g VGhlICgxKSBvZmZlcnMgeW91IFNSLUVSTywgU1ItUG9saWN5DQogICAgYXNzb2NpYXRpb24gZXRj LiBUaGUgKDIpIG9mZmVycyB5b3UgUDJNUCBFTkQtUE9JTlQgb2JqZWN0IHdpdGgNCiAgICBtdWx0 aXBsZSBkZXN0aW5hdGlvbiwgUzJMUyBvYmplY3QgdG8gcmVwb3J0IHN0YXR1cyB0byBlYWNoIGxl YWYgZXRjLg0KDQogICAgUmVnYXJkaW5nIGJhY2t1cCwgUHJvdGVjdGlvbiBBc3NvY2lhdGlvbiBj b3VsZCBiZSB1c2VkIGV2ZW4gZm9yIFAyTVANCiAgICBhcyB3ZWxsLiBJIHdvdWxkIG5vdCBsb29r IG9ubHkgYXQgYSBmZWF0dXJlIGxpa2UgJ2JhY2t1cCcgdG8gbWFrZSB0aGlzDQogICAgZnVuZGFt ZW50YWwganVkZ21lbnQgb24gaG93IHRvIGVuY29kZSBTUi1QMk1QIGluIFBDRVAuDQoNCiAgICBJ IGxpa2UgdGhlIGZhY3QgdGhhdCBhcyBmYXIgYXMgUENFUCBtZXNzYWdlIGVuY29kaW5nIGlzIGNv bmNlcm5lZCwNCiAgICB0aGVyZSBpcyBhIG1pbmltYWwgZGlmZmVyZW5jZSBiZXR3ZWVuIFNSIGFu ZCBSU1ZQLVRFLiBJIHdvdWxkIGxpa2UgdG8NCiAgICBzZWUgaWYgd2UgY2FuIGNvbnRpbnVlIHRv IGtlZXAgdGhhdCB0cnVlIGZvciBTUi1QMk1QIGFzIHdlbGwgOikNCg0KW0FuZHJld10gQUNLLCBz b21ldGhpbmcgSSBndWVzcyB0aGF0IHdpbGwgbmVlZCB0byBiZSBkaXNjdXNzZWQgZnVydGhlciBp biB0aGUgc2hhcGluZyBvZiBQQ0VQIHJlcGxpY2F0aW9uIHNlZ21lbnQgZHJhZnQuIENvbmZpZ3Vy aW5nIHN0aXRjaGVkIHJlcGxpY2F0aW9uIHNlZ21lbnRzIChhbmQgZWFjaCByZXBsaWNhdGlvbiBz ZWdtZW50IGRvZXMgbm90IHBlcmZvcm0gYW55IG5ldHdvcmsgc2lnbmFsbGluZyksIG9uZSBjb3Vs ZCBsZXZlcmFnZSBpbmRlcGVuZGVudCBSU1ZQIExTUChzKSBpbiBiZXR3ZWVuIHJlcGxpY2F0aW9u IHNlZ21lbnRzIGFsb25nIHRoZWlyIHVuaWNhc3QgcGF0aCwgYnV0IGl0J3Mgbm90IGNsZWFyIHRv IG1lIGlmIHRoZXJlIGNvdWxkL3dvdWxkL3Nob3VsZCBiZSBSU1ZQIHNpZ25hbGxpbmcgZm9yIHRo ZSByZXBsaWNhdGlvbiBzZWdtZW50IGl0c2VsZiwgc28gSSdtIG5vdCBzdXJlIGhvdyBkaXJlY3Rs eSBtYXBwZWQgdG8gYW4gUlNWUCB1c2UgY2FzZSBpdCBpcywgYXMgdGhlIGN1cnJlbnQgZm9jdXMg aXMgU1ItTVBMUy9TUnY2LWxpa2UgZnVuY3Rpb25hbGl0eS4gS2VlcGluZyBkYXRhIG1vZGVscyBh bmQgbWVzc2FnZSBlbmNvZGluZyB0aGUgc2FtZSBhcyBtdWNoIGFzIHBvc3NpYmxlLCBJIGRvIGFn cmVlIHdpdGgsIGFuZCB0aGUgcmVwbGljYXRpb24gc2VnbWVudCBkcmFmdCBoYXMgYXR0ZW1wdGVk IHRvIGRvIHRoYXQgYnkgcmUtdXNpbmcgdGhlIG1vZGVsIGVuY29kaW5nIGZyb20gYWxsIHRoZSBw cmV2aW91cyBJRVRGIHdvcmsuIFNpZGUgbm90ZSwgdGhlIHNlcGFyYXRpb24gb2YgdGhlIFAyTVAg UG9saWN5IHZzIFJlcGxpY2F0aW9uIFNlZ21lbnQgaW4gUENFUCBpcyBhbHNvIGtleSB0byBrZWVw aW5nIHRoZSBzb2x1dGlvbiBtYW5hZ2VhYmxlIGluIFBDRVAgdG8gaGFuZGxlIGNhc2VzIG9mIG1i YiwgcmVkdW5kYW5jeSBhbmQgdHJhbnNwb3J0IHJlLXVzYWJpbGl0eSAtIGl0J3Mgbm90IGNsZWFy IHRvIG1lIGhvdyB0aGF0IHNwbGl0IGxvb2tzIGxpa2UgaWYgb25lIHdlcmUgdG8gY29tcGxldGVs eSBidWlsZCBvbiB0aGUgUkZDIDg2MjMuDQoNCg0KICAgIFRoYW5rcyENCiAgICBEaHJ1dg0KDQog ICAgPg0KICAgID4gQ2hlZXJzDQogICAgPg0KICAgID4gQW5kcmV3DQogICAgPg0KICAgID4NCiAg ICA+DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgID4gUGNlIG1haWxpbmcgbGlzdA0KICAgID4gUGNlQGlldGYub3JnPG1haWx0bzpQY2VA aWV0Zi5vcmc+DQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bj ZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQ Y2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmc8bWFpbHRvOlBjZUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= --_000_MN2PR19MB31676F98A15367281D259698FC1B0MN2PR19MB3167namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+U29tZSBpbnB1dCBpbmxpbmUuLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5QY2UgJmx0O3BjZS1ib3VuY2Vz QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQ3lyaWwgTWFyZ2FyaWEgJmx0O2N5cmlsLm1hcmdh cmlhQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBGZWJydWFyeSAx MiwgMjAyMCBhdCA0OjE5IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtTdG9uZSwgQW5kcmV3IChO b2tpYSAtIENBL090dGF3YSkmcXVvdDsgJmx0O2FuZHJldy5zdG9uZUBub2tpYS5jb20mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj4mcXVvdDtwY2VAaWV0Zi5vcmcmcXVvdDsgJmx0O3BjZUBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtQY2VdIE11bHRpcGF0aCAvIHJlcGxpY2F0aW9u IHNlZ21lbnQgY29tbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UGxlYXNlIHNlZSBpbmxpbmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gVGh1LCAxOSBEZWMgMjAxOSBhdCAxNzoxOSwgU3RvbmUs IEFuZHJldyAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmV3LnN0 b25lQG5va2lhLmNvbSI+YW5kcmV3LnN0b25lQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCkZldyBjb21tZW50cyBiZWxvdyw8YnI+DQo8YnI+ DQpDaGVlcnM8YnI+DQpBbmRyZXc8YnI+DQo8YnI+DQrvu79PbiAyMDE5LTEyLTE5LCA2OjUyIEFN LCAmcXVvdDtEaHJ1diBEaG9keSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRocnV2LmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGhydXYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEhpIEFuZHJldyw8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IFNwZWFraW5nIGFzIGEgV0cgY29udHJpYnV0b3IuLi48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IE9uIFdlZCwgRGVjIDE4LCAyMDE5IGF0IDExOjU4IFBNIFN0b25lLCBBbmRyZXcg KE5va2lhIC0gQ0EvT3R0YXdhKTxicj4NCiZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0 bzphbmRyZXcuc3RvbmVAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5kcmV3LnN0b25lQG5v a2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyBIaSBhbGwsPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IEluIFNpbmdhcG9yZSBJIG1hZGUgYSByZW1hcmsgYWJvdXQgZHJhZnQta29sZHljaGV2LXBj ZS1tdWx0aXBhdGggdGhhdCBpdOKAmXMgYSBoZWxwZnVsIGRyYWZ0IGFuZCBpcyBhbHNvIGFwcGxp Y2FibGUgdG8gdGhlIHJlcGxpY2F0aW9uIHNlZ21lbnQuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IEkgcmVjZWl2ZWQgYSBmb2xsb3cgdXAgcXVlc3Rpb24gZW1haWxlZCBk aXJlY3RseSwgYXNraW5nIGFib3V0IHdoZXRoZXIg4oCcRVJPcyBuZWVkIHRvIHNoYXJlIHNhbWUg c291cmNlIGFuZCBkZXN0aW5hdGlvbuKAnSBhbmQgaG93L2lmIHRoaXMgY291bGQgYmUgcmVsYXRl ZCB0byBSRkMgODYyMy48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7 ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgRm9y IG9wZW5uZXNzLCBzZW5kaW5nIG15IHRob3VnaHRzL2NvbW1lbnRzIGhlcmUgdG8gdGhlIFdHOjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUaGVyZSBpcyBubyByZXF1aXJl bWVudCBsaXN0ZWQgaW4gZHJhZnQta29sZHljaGV2LXBjZS1tdWx0aXBhdGggdGhhdCBJIGNhbiBz ZWUgd2hpY2ggcmVxdWlyZXMgRVJPcyB0byB0ZXJtaW5hdGUgb24gdGhlIHNhbWUgc291cmNlL2Rl c3RpbmF0aW9uLCBJIGhhdmVu4oCZdCBzZWVuIHRoYXQgZXhwZWN0YXRpb24gYW55d2hlcmUsIGFu ZCBpbiBteSBvcGluaW9uIHRoZXJlIHNob3VsZCBub3QgYmUuPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBbRGhydXZdIFlvdSBhcmUgcmlnaHQsIHRoaXMgaXMgbm90IGV4cGxpY2l0IGluIHRoZSBJ LUQuIEJ1dCBiYXNlZCBvbjxicj4NCiZuYnNwOyAmbmJzcDsgdGhlIHNjb3BlIG9mIHBhc3QgZGlz Y3Vzc2lvbiBJTUhPIGl0IHdhcyBhbHdheXMgYWJvdXQgbXVsdGlwbGUgcGF0aHM8YnI+DQombmJz cDsgJm5ic3A7IChFUk8pIGZvciBhIHNpbmdsZSB0dW5uZWwgYW5kIHRodXMgZmluZGluZyBhIHdh eSB0byBlbmNvZGUgdGhlbSB3aXRoaW48YnI+DQombmJzcDsgJm5ic3A7IGEgc2luZ2xlIHJlcG9y dC91cGRhdGUgaW4gYSBQQ0VQIG1lc3NhZ2UuPGJyPg0KPGJyPg0KW0FuZHJld10gVHJ1ZSwgdGhl IG9yaWdpbmFsIGludGVudCBvZiBtdWx0aXBsZSBwYXRocyB3aXRoaW4gdGhlIHNhbWUgdHVubmVs IGluIGEgc2luZ2xlIHJlcG9ydC91cGRhdGUsIGJ1dCB0aGF0IGNvdWxkIHN0aWxsIGJlIGxldmVy YWdlZCBpbiB0aGUgcmVwbGljYXRpb24gY2FzZSwgaS5lIEkgd2FudCBhIHNpbmdsZSByZXBvcnQv dXBkYXRlIHRvIG1vZGlmeSB0aGUgc3RhdGUgb2YgYSByZXBsaWNhdGlvbiBzZWdtZW50LiBJIHRo aW5rIGl0IGJlY29tZXMNCiBhIGdyYXkgYXJlYSBpbiBpbnRlcnByZXRhdGlvbiBvZiB3aGV0aGVy IG9yIG5vdCBhIHJlcGxpY2F0aW9uIHNlZ21lbnQgY3JlYXRlcyBhIFAyTVAgdHVubmVsIG9yIGlm IGl0J3MgYWN0dWFsbHkganVzdCBjcmVhdGluZyBtdWx0aXBsZSBQMlAgdHVubmVscyBmcm9tIGEg c2luZ2xlIGluZ3Jlc3MgbGFiZWwuIElmIHRoZSBpbnRlcnByZXRhdGlvbiBpcyBpdCdzIGEgUDJN UCB0dW5uZWwsIHRoZW4gdXNpbmcgbXVsdGlwbGUgRVJPcyB0byBkZWZpbmUNCiB0aGUgZm9yd2Fy ZGluZyBvZiBhIFAyTVAuIFR1bm5lbCByZXF1aXJlcyB0aG9zZSBFUk9zIHRvIHRlcm1pbmF0ZSBv biBkaWZmZXJlbnQgbm9kcy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bQ3lyaWxdIFRo ZXJlIGlzIGEgcmVsYXRlZCB3b3JrIHRoYXQgdGllcyBvbmUgdHVubmVsIHRvIG11bHRpcGxlIHBh dGgsIGxpc3Qgb2YgaG9wcyA6Jm5ic3A7IFJGQzg2OTcsIGFuZCZuYnNwO2RyYWZ0LWlldGYtcGNl LXN0YXRlZnVsLXBhdGgtcHJvdGVjdGlvbi0xMS4gR2l2ZW4gdGhlIG1lY2hhbmlzbSB1c2VkIChh bmQgZmxleGliaWxpdHkgaW4gdGVybSBvZiB0aGUgaW5kaXZpZHVhbA0KIGxlZ3MpLCB3b3VsZCBp dCBtYWtlIHNlbnNlIHRvIHJldXNlIHRoZSBwYXRoIHByb3RlY3Rpb24gbWVjaGFuaXNtcyB0byB0 aWUgdGhvc2UgbXVsdGlwbGUgRVJPcyB0b2dldGhlcj8gSW4gYWRkaXRpb24gaXQgYWRkcmVzc2Vz IHRoZSBiYWNrdXAgcGF0aCBhbHJlYWR5LiZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPltU U106IENvbnNpZGVyIHRoZSBjYXNlIG9mIGEgUENFIGRlbGVnYXRlZCBTUiBQb2xpY3kgQ2FuZGlk YXRlIFBhdGguIFRoZSBQQ0MgZGVzaXJlcyBhbiBTUiBwYXRoIGNvbXB1dGF0aW9uIGZyb20gYSBQ Q0UgdGhhdCBpcyBzdWJqZWN0IHRvIGNvbnN0cmFpbnRzIOKAkyBUaGUgUENDIGhhcyBubyBhLXBy aW9yaSBpZGVhICoqaG93IG1hbnkqKiBTZWdtZW50LUxpc3RzDQogKFNMcykgdGhlIFBDRSBwYXRo IGNvbXB1dGF0aW9uIHdpbGwgcmVzdWx0IGluLS0gc28gaXQgZG9lcyBub3Qga25vdyBob3cgbWFu eSAob3Igd2hldGhlciBpdCBzaG91bGQgYXQgYWxsKSBjcmVhdGUgbXVsdGlwbGUgUExTUHMgd2l0 aCBOTy1FUk8gYW5kIHJlcG9ydCB0aGVtIHNvIFBDRSBjYW4gcmVzcG9uZCB0byBlYWNoLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UaGUgUENDIGNyZWF0ZXMgKjxiPm9uZTwvYj4qIFBMU1AgYW5kIHJlcG9y dHMgdG8gdGhlIFBDRSB0aGUgTFNQIGRvd24gKHdpdGggTk8tRVJPKSBhbG9uZyB3aXRoIHRoZSBz cGVjaWZpZWQgdXNlciBjb25zdHJhaW50cy4gVGhlIFBDRSBjb21wdXRlcyBhbmQgZGV0ZXJtaW5l cyB0aGUgZmVhc2libGUgbnVtYmVyIG9mIFNMcy4gTm93LCBpdCB3b3VsZCBiZSBhd2t3YXJkDQog Zm9yIHRoZSBQQ0UgdG8gaW5zdGFudGlhdGUgUExTUHMg4oCTIGRpZmZlcmVudCBmcm9tIHRoZSBv bmUgb3JpZ2luYWxseSBkZWxlZ2F0ZWQgYnkgdGhlIFBDQ+KAlHNvIHRvIGVuY29kZSBlYWNoIFNM IGluIGl0cyBvd24gUExTUCBhbmQgbWFrZSB1c2UgdGhlIOKAnGFzc29jaWF0aW9uIG9iamVjdOKA nSBtZXRob2QuLiBJIGNhbiBhbHNvIGltYWdpbmUgY29tcGxleGl0aWVzIGluIHdoYXQgZWFjaCBQ TFNQIExTUCB3b3VsZCBjYXJyeSBpbiB0ZXJtcyBvZiBjb25zdHJhaW50cw0KIOKAkyBlc3BlY2lh bGx5IGFmdGVyIHNvbWUgY29uZmlndXJhdGlvbiBjaGFuZ2Ugb24gdGhlIFBDQ+KApjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhlIHByb3Bvc2FsIGluIGRyYWZ0 LWtvbGR5Y2hldi1wY2UtbXVsdGlwYXRoIGluZGVlZCBwcm9wb3NlcyBlbGVnYW50IHdheSB0byBl bmNvZGUgYWxsIGNvbXB1dGVkIFNMcyAoYXMgbXVsdGlwbGUgU0VSTyBsaXN0cykgaW50byBhIHNp bmdsZSBQTFNQIOKAkyB0aGUgb25lIG9yaWdpbmFsbHkgcmVwb3J0ZWQgYnkgdGhlIGRlbGVnYXRl ZCBQTFNQLiBJbiBmYWN0LA0KIHRoaXMgbWV0aG9kIGFsbG93cyBhdCBhbnl0aW1lIHRoZSBQQ0Ug dG8gc2VuZCBQQ1VwZCB0byBhZGQvcmVtb3ZlL3VwZGF0ZSBTTChzKSB3aXRoaW4gYSBzaW5nbGUg UExTUCBmcmVlbHkg4oCTIHdoaWNoIElNTyBpcyBwb3dlcmZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkkgdGhpbmsgdGhlIHNhbWUgYXJndW1lbnQgYXBwbGll cyB0byBiYWNrdXAgcGF0aHMvU0xzIHRvby4uIFRoZSBQQ0Mgd291bGQgbm90IGtub3cgaG93IG1h bnkgU0wocykgY2FuIHByb3RlY3QgYSBzaW5nbGUgcGF0aCwgc28gaXQgd291bGQgbm90IGJlIGFi bGUgdG8gYS1wcmlvcmkgY3JlYXRlIFBMU1BzIGFuZCB1c2UgYXNzb2NpYXRpb24gb2JqZWN0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48YnI+DQpXaGVyZSBpcyB0aGUgcmVxdWlyZW1lbnQgb2YgdXBkYXRpbmcgYWxs IHRoZSBzZWdtZW50LWxpc3Qgb2YgYW4gU1ItQ2FuZGlkYXRlIHRvZ2V0aGVyIGNvbWluZyBmcm9t PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNjI0IiBzdHlsZT0id2lkdGg6Ni41aW47bWFyZ2luLWxlZnQ6LjVpbiI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPk9uIGFuIHVucmVsYXRl ZCBub3RlLCB3aHkgaXMgaXQgY2FsbGVkIENhbmRpZGF0ZS1wYXRoIGFuZCBub3QgY2FuZGlkYXRl LW11bHRpcGF0aCwgaWYgdGhlcmUgYXJlIG11bHRpcGxlIHBhdGg/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5bVFNdOiBwbGVh c2UgcmVmZXIgdG8gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeSB3aGlj aCBkZWZpbmVzIHN1Y2ggdGVybXPigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRhcmVrPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyAmbmJzcDsgVGhlIG5l dyBFUk8tQVRUUklCIG9iamVjdCBpbiB0aGUgSS1EIGlzIGp1c3QgYSBzZXBhcmF0b3IgYmV0d2Vl bjxicj4NCiZuYnNwOyAmbmJzcDsgc2V2ZXJhbCBFUk8gb2JqZWN0cyBpbiBhIGV4aXN0aW5nIFBD RVAgbWVzc2FnZSB3aGljaCByZXBvcnRzL3VwZGF0ZSBhPGJyPg0KJm5ic3A7ICZuYnNwOyBwYXJ0 aWN1bGFyIExTUCAoaWRlbnRpZmllZCBieSBQTFNQLUlEIGluIHRoZSBMU1Agb2JqZWN0KS48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgRm9yIGV4YW1wbGUsIG9uZSBvZiB0aGUgdXNlIGNh c2VzIG9mIGRyYWZ0LWtvbGR5Y2hldi1wY2UtbXVsdGlwYXRoIGlzIGZvciBTUiBQb2xpY3kgdG8g c3VwcG9ydCBtdWx0aXBsZSBTSUQgbGlzdHMsIGNvbWJpbmUgdGhhdCB3aXRoIHVzZSBjYXNlIHN1 Y2ggYXMgU1ItRVBFLCB5b3UgY291bGQgaGF2ZSBtdWx0aXBsZSBTSUQgbGlzdHMgYW5kIGhhdmUg d2VpZ2h0ZWQgRUNNUCB0cmFmZmljIG91dCBkaWZmZXJlbnQgZWdyZXNzIG5vZGVzIGludGVudGlv bmFsbHkNCiB0byBsb2FkIGJhbGFuY2UgYWNyb3NzIGRpZmZlcmVudCBwZWVyIG5vZGVzLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgW0RocnV2XSBBcyBwZXIgdGhlIFNSIHBvbGljeSBhcyBpdCBp cyBjdXJyZW50bHkgZGVmaW5lZCAtIEVuZCBwb2ludCBpczxicj4NCiZuYnNwOyAmbmJzcDsgdGhl IHByb3BlcnR5IG9mIHRoZSBTUiBQb2xpY3kuIEVhY2ggc2VnbWVudC1saXN0IGluc2lkZSBhIGNh bmRpZGF0ZTxicj4NCiZuYnNwOyAmbmJzcDsgcGF0aCB3b3VsZCBiZSBhIHNwZWNpZmljIHNvdXJj ZS1yb3V0ZWQgcGF0aCBmcm9tIHRoZSBoZWFkZW5kIHRvIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsg ZW5kcG9pbnQgb2YgdGhlIGNvcnJlc3BvbmRpbmcgU1IgcG9saWN5LiBUaGF0IHNhaWQsIGluIHRo aXMgdXNlIGNhc2U8YnI+DQombmJzcDsgJm5ic3A7IHBlcmhhcHMgeW91IHdvdWxkIHVzZSBhbiBh bnljYXN0IGFkZHJlc3MgYnV0IHN0aWxsIHRoZSBzYW1lIGVuZHBvaW50PGJyPg0KJm5ic3A7ICZu YnNwOyBmcm9tIHRoZSBTUiBwb2xpY3kgcG9pbnQgb2Ygdmlldy48YnI+DQo8YnI+DQo8YnI+DQpb QW5kcmV3XSBDb2luY2lkZW50YWxseSB0aGlzIHdhcyBqdXN0IG1lbnRpb25lZCBpbiBTUFJJTkcg bWFpbGluZyBsaXN0LCB3aGV0aGVyIGluIFNSIFBvbGljeSBlbmRwb2ludCBpcyB0aGUgdHVubmVs IHRlcm1pbmF0aW9uIHZzIGEgcHJlZml4L3JvdXRlIHRvIHJlYWNoICh3aGljaCBJIGtpbmQgb2Yg aGF2ZSB0byBhZ3JlZSB3aXRoKSwgd2hpY2ggc2VlbWVkIHRvIGhhdmUgYmVlbiByYWlzZWQgYmVj YXVzZSB0aGVyZSdzIHRoZSBjb25jZXB0IG9mDQogbnVsbC88YSBocmVmPSJodHRwOi8vMC4wLjAu MCIgdGFyZ2V0PSJfYmxhbmsiPjAuMC4wLjA8L2E+IChhbmQgc29tZSB3b3JkaW5nIG9uIHdoZXRo ZXIgb3Igbm90IHRoaXMgaXMgYSB2YWxpZCAmcXVvdDtlbmRwb2ludCZxdW90OykuIEFueXdheXMs IGluIGFuIEVQRSBjYXNlIEkgZG9uJ3QgbmVlZCB0byBzcGVjaWZ5IGEgcGF0aCB0byByZWFjaCB0 aGUgYWJzb2x1dGUgZW5kcG9pbnQsIEkganVzdCBuZWVkIHRvIHNwZWNpZnkgYSBwYXRoIHRvIHN0 ZWVyIHRvIGFuIGVncmVzcw0KIHBlZXIsIGFuZCB3aXRoIGxhc3QgbGFiZWwgaW4gdGhlIHN0YWNr IGJlaW5nIGFuIEVQRSBQZWVyIGxpbmsgb3Igbm9kZSwgYW5kIHRoYXQgZWdyZXNzIHBlZXIgY2Fu IHRha2Ugb3ZlciB0aGUgcGFja2V0IChsaWtlbHkgbm90IE1QTFMgZW5jYXBlZCBhbnltb3JlKSBh bmQgc3RlZXIsIGZvcndhcmQgb3IgdHVubmVsIGhvd2V2ZXIgaXQgY2hvb3Nlcy4gSW4gdGhpcyBy ZWdhcmQgdGhlIFNJRCBsaXN0IHNwZWNpZmllZCBvbiB0aGUgaGVhZGVuZCBTUg0KIFBvbGljeSAm cXVvdDtzdG9wcyBlYXJseSZxdW90OyBiZWZvcmUgdGhlICZxdW90O3JlYWwgZW5kcG9pbnQmcXVv dDsuIEZyb20gdGhpcyBwZXJzcGVjdGl2ZSB3aGV0aGVyIG15IEVDTVAgU0lEIGxpc3RzIHN0b3Ag b24gZGlmZmVyZW50IHJvdXRlcnMgb3Igbm90IGlzIG5vdCByZWFsbHkgcmVsZXZhbnQgZm9yIHJl YWNoaW5nIHRoZSAmcXVvdDtyZWFsIGVuZHBvaW50JnF1b3Q7LiBTZWN0aW9uIDQuNyBpbiBkcmFm dC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUtMTAgYnJpZWZseQ0KIGNv bW1lbnRzIG9uIHRoaXMsIGluIHRoZSBzZW5zZSB0aGF0IHRvIHJlYWNoIGFuIGludGVybmV0IHJv dXRlIGEgU0lEIGxpc3QgY29tcHJpc2VkIG9mIG9ubHkgU0lEKHMpIHRvIHJlYWNoIHRoZSBib3Jk ZXIgbm9kZSwgYW5kIGEgU0lEIHRvIHNwZWNpZnkgdGhlIHBlZXJpbmcgcm91dGVyIGlzIHN1ZmZp Y2llbnQuIEluIHRoaXMgcmVnYXJkIHRoZSBwYXRoIHRlcm1pbmF0ZXMgb24gdGhlIHBlZXJpbmcg cm91dGVyLCBkZXNwaXRlIHRoZSBmYWN0IHRoYXQNCiBteSBlbmRwb2ludCBpcyBtdWNoIGZ1cnRo ZXIgaW4gdGhlIG5ldHdvcmsgLyBwZXJoYXBzIGFjcm9zcyB0aGUgaW50ZXJuZXQuIDxicj4NCjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBBbm90aGVyIGV4YW1wbGUsIHdpdGggaW5ncmVz cyByZXBsaWNhdGlvbiwgaXMgdGhlIG11bHRpcGF0aCBFUk8gY2FuIGFsc28gYmUgcmUtdXNlZCB0 byBkZXNjcmliZSB0aGUgZWdyZXNzIGRvd25zdHJlYW0gcGF0aHMgd2hpY2ggd2lsbCBiZSBnb2lu ZyB0byBkaWZmZXJlbnQgcmVjZWl2ZXIocyksIGZvciBlaXRoZXIgZnVydGhlciByZXBsaWNhdGlv biBvciBjb25zdW1wdGlvbi48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsg TXkgY29tbWVudCByZWdhcmRpbmcgbXVsdGlwYXRoIHRvIGJlIHVzZWQgZm9yIGluZ3Jlc3MgcmVw bGljYXRpb24gaXMgYmVjYXVzZSB0aGVyZSBpcyBhIG5lZWQgaW4gcmVwbGljYXRpb24gc2VnbWVu dCB0byBiZSBhYmxlIHRvIHByb2dyYW0gYmFja3VwIHBhdGhzIGZvciBlYWNoIGVncmVzcyBFUk8u IFRoZXJlIHdlcmUgY29tbWVudHMgb24gdGhpcyBpbiB0aGUgZWFybGllciBzci1yZXBsaWNhdGlv biBkcmFmdCBpbiBzcHJpbmcgd2csIGJ1dA0KIGFwcGVhcnMgdGhlIHdvcmRpbmcgaGFzIGJlZW4g cmVkb25lIC8gZHJhZnRzIGFyZSBzdGlsbCBpbiBhIHN0YXRlIG9mIGNoYW5nZS4gTm9uZSB0aGUg bGVzcywgdGhlIG11bHRpcGF0aCBiYWNrdXAgVExWIHZpYSB0aGUgRVJPIGF0dHJpYnV0ZXMgb2Jq ZWN0IGluIGRyYWZ0LWtvbGR5Y2hldi1wY2UtbXVsdGlwYXRoIHBlcm1pdHMgdGhlIHJlbGF0aW9u IGJldHdlZW4gdGhlIG5vcm1hbCBFUk8gYW5kIHRoZSBiYWNrdXAgKFBDRSBjb21wdXRlZCkgRVJP LA0KIHNvbWV0aGluZyB0aGF0IHRoZSBjdXJyZW50IFJGQyA4NjIzIGRvZXMgbm90LiBUaGVyZeKA mXMgYSBkZXNpcmUgdG8gYnVpbGQgdGhpcyBpbnRvIHJlcGxpY2F0aW9uIHNlZ21lbnQgYW5kIGRy YWZ0LWhzZC1wY2Utc3ItcDJtcC1wb2xpY3ktMDEmbmJzcDsgaXMgbGV2ZXJhZ2luZyB0aGlzIGNv bnN0cnVjdCAocHJvYmFibHkgbmVlZCBmdXJ0aGVyIHJlbWFya3Mgb24gdGhpcyBpbiB0aGUgZHJh ZnRzIHRvIGRlc2NyaWJlIHRoaXMgaW50ZW50aW9uKS4gQ29tcGFyaW5nDQogdG8gUkZDIDg2MjMs IGNvbnNpZGVyaW5nIGFsbCBvZiB0aGUgbnVhbmNlcyBvZiByZXBsaWNhdGlvbiBzZWdtZW50IChw Mm1wLWxzcC1pZGVudGlmaWVyLXRsdiwgcmVwbGljYXRpb24tc2lkL2JpbmRpbmctbGFiZWwsIGJh Y2t1cCBlcm9zKSBpdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIHRoYXQgZHJhZnQtaHNkLXBjZS1z ci1wMm1wLXBvbGljeSBkZWZpbmVzIHRoZSByZXBsaWNhdGlvbiBzZWdtZW50IChkcmFmdC1oc2Qt cGNlLXNyLXAybXAtcG9saWN5LTAxDQogc2VjdGlvbiAzLjMpIHdoaWxlIGxldmVyYWdpbmcgZXhp c3Rpbmcvb3RoZXIgY29tbW9uIGNvbnN0cnVjdHMsIGFuZCBkZWZpbmluZyBpdOKAmXMgYmVoYXZp b3VyLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8ganVzdCB1c2UgYWxsIG9mIFJGQzg2MjMgYW5kIGF0 dGVtcHQgdG8gdXBkYXRlIGFuZCBzcXVlZXplIGluIChvciBvdXQpIG90aGVyIGVsZW1lbnRzIG9m IHRoZSBSRkMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBbRGhydXZdOiBGb3IgdGhlIFNSLVAyTVAgdXNlY2Fz ZSB5b3UgaGF2ZSB0d28gYnVpbGRpbmcgYmxvY2tzIGluIFBDRVA8YnI+DQombmJzcDsgJm5ic3A7 ICgxKSBQQ0VQLVNSIGZvciBQMlAgKDIpIFBDRVAtUlNWUC1URSBmb3IgUDJNUC4gSSB3b3VsZCBz dWdnZXN0IHlvdSB0bzxicj4NCiZuYnNwOyAmbmJzcDsgYnVpbGQgb24gYm90aCBvZiB0aGVzZS4g VGhlICgxKSBvZmZlcnMgeW91IFNSLUVSTywgU1ItUG9saWN5PGJyPg0KJm5ic3A7ICZuYnNwOyBh c3NvY2lhdGlvbiBldGMuIFRoZSAoMikgb2ZmZXJzIHlvdSBQMk1QIEVORC1QT0lOVCBvYmplY3Qg d2l0aDxicj4NCiZuYnNwOyAmbmJzcDsgbXVsdGlwbGUgZGVzdGluYXRpb24sIFMyTFMgb2JqZWN0 IHRvIHJlcG9ydCBzdGF0dXMgdG8gZWFjaCBsZWFmIGV0Yy48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IFJlZ2FyZGluZyBiYWNrdXAsIFByb3RlY3Rpb24gQXNzb2NpYXRpb24gY291bGQgYmUgdXNl ZCBldmVuIGZvciBQMk1QPGJyPg0KJm5ic3A7ICZuYnNwOyBhcyB3ZWxsLiBJIHdvdWxkIG5vdCBs b29rIG9ubHkgYXQgYSBmZWF0dXJlIGxpa2UgJ2JhY2t1cCcgdG8gbWFrZSB0aGlzPGJyPg0KJm5i c3A7ICZuYnNwOyBmdW5kYW1lbnRhbCBqdWRnbWVudCBvbiBob3cgdG8gZW5jb2RlIFNSLVAyTVAg aW4gUENFUC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgbGlrZSB0aGUgZmFjdCB0aGF0IGFz IGZhciBhcyBQQ0VQIG1lc3NhZ2UgZW5jb2RpbmcgaXMgY29uY2VybmVkLDxicj4NCiZuYnNwOyAm bmJzcDsgdGhlcmUgaXMgYSBtaW5pbWFsIGRpZmZlcmVuY2UgYmV0d2VlbiBTUiBhbmQgUlNWUC1U RS4gSSB3b3VsZCBsaWtlIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyBzZWUgaWYgd2UgY2FuIGNvbnRp bnVlIHRvIGtlZXAgdGhhdCB0cnVlIGZvciBTUi1QMk1QIGFzIHdlbGwgOik8YnI+DQo8YnI+DQpb QW5kcmV3XSBBQ0ssIHNvbWV0aGluZyBJIGd1ZXNzIHRoYXQgd2lsbCBuZWVkIHRvIGJlIGRpc2N1 c3NlZCBmdXJ0aGVyIGluIHRoZSBzaGFwaW5nIG9mIFBDRVAgcmVwbGljYXRpb24gc2VnbWVudCBk cmFmdC4gQ29uZmlndXJpbmcgc3RpdGNoZWQgcmVwbGljYXRpb24gc2VnbWVudHMgKGFuZCBlYWNo IHJlcGxpY2F0aW9uIHNlZ21lbnQgZG9lcyBub3QgcGVyZm9ybSBhbnkgbmV0d29yayBzaWduYWxs aW5nKSwgb25lIGNvdWxkIGxldmVyYWdlIGluZGVwZW5kZW50DQogUlNWUCBMU1AocykgaW4gYmV0 d2VlbiByZXBsaWNhdGlvbiBzZWdtZW50cyBhbG9uZyB0aGVpciB1bmljYXN0IHBhdGgsIGJ1dCBp dCdzIG5vdCBjbGVhciB0byBtZSBpZiB0aGVyZSBjb3VsZC93b3VsZC9zaG91bGQgYmUgUlNWUCBz aWduYWxsaW5nIGZvciB0aGUgcmVwbGljYXRpb24gc2VnbWVudCBpdHNlbGYsIHNvIEknbSBub3Qg c3VyZSBob3cgZGlyZWN0bHkgbWFwcGVkIHRvIGFuIFJTVlAgdXNlIGNhc2UgaXQgaXMsIGFzIHRo ZSBjdXJyZW50DQogZm9jdXMgaXMgU1ItTVBMUy9TUnY2LWxpa2UgZnVuY3Rpb25hbGl0eS4gS2Vl cGluZyBkYXRhIG1vZGVscyBhbmQgbWVzc2FnZSBlbmNvZGluZyB0aGUgc2FtZSBhcyBtdWNoIGFz IHBvc3NpYmxlLCBJIGRvIGFncmVlIHdpdGgsIGFuZCB0aGUgcmVwbGljYXRpb24gc2VnbWVudCBk cmFmdCBoYXMgYXR0ZW1wdGVkIHRvIGRvIHRoYXQgYnkgcmUtdXNpbmcgdGhlIG1vZGVsIGVuY29k aW5nIGZyb20gYWxsIHRoZSBwcmV2aW91cyBJRVRGIHdvcmsuIFNpZGUNCiBub3RlLCB0aGUgc2Vw YXJhdGlvbiBvZiB0aGUgUDJNUCBQb2xpY3kgdnMgUmVwbGljYXRpb24gU2VnbWVudCBpbiBQQ0VQ IGlzIGFsc28ga2V5IHRvIGtlZXBpbmcgdGhlIHNvbHV0aW9uIG1hbmFnZWFibGUgaW4gUENFUCB0 byBoYW5kbGUgY2FzZXMgb2YgbWJiLCByZWR1bmRhbmN5IGFuZCB0cmFuc3BvcnQgcmUtdXNhYmls aXR5IC0gaXQncyBub3QgY2xlYXIgdG8gbWUgaG93IHRoYXQgc3BsaXQgbG9va3MgbGlrZSBpZiBv bmUgd2VyZSB0byBjb21wbGV0ZWx5DQogYnVpbGQgb24gdGhlIFJGQyA4NjIzLiA8YnI+DQo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoYW5rcyE8YnI+DQombmJzcDsgJm5ic3A7IERocnV2PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IENoZWVy czxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBBbmRyZXc8 YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZndDsgUGNl IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YSBocmVmPSJtYWlsdG86UGNl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UGNlQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3BjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGNlPC9hPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KUGNlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpQY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5QY2VAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_MN2PR19MB31676F98A15367281D259698FC1B0MN2PR19MB3167namp_-- From nobody Wed Feb 12 16:03:22 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A63120046 for ; Wed, 12 Feb 2020 16:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 r-MbSgXhIT17 for ; Wed, 12 Feb 2020 16:03:18 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 8092F12002F for ; Wed, 12 Feb 2020 16:03:17 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id p23so4559228edr.5 for ; Wed, 12 Feb 2020 16:03:17 -0800 (PST) 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=AU+ryTiVYmIniaj8UDT6rLZaXYHcwKY90i/3YJd0jcQ=; b=t/TGQwVLVq6WkBmGSxx2Lcl8k4EkRPT9cta8aU0Zjbxif/XFGy4cAYnvn49BGAt/hB x80eWsFJxN6kFN8yrpN2sqFRI7KZ2a1nY2SuZFtNvgMFZtrFn7yp9XdiY1O5GbT77OH8 7zpxs3BhLRU2yzLmCgB6S/pPYzeg58gr0geER710WDpMbBBdnlr/LiqI6+Ym5yduRe8B KHjFG5uSwlcvJyR6cf7MLbKapH8T0zMaDJvzqFgvCF78BxQgwwYfeoWb3fRZzfwPXtCa IXEZDmzY9rGVHZ+HXQF+nH5VIa373cqm+RCYlJGuNaFJ4YXskqYJgIac2jCkiaChXWka rrMg== 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=AU+ryTiVYmIniaj8UDT6rLZaXYHcwKY90i/3YJd0jcQ=; b=HLG1WI91mxpFbH2ELAvyRhc/Mrrbo9j9pDDf1ZokX69Zs89sGrlOWRwEDX7CX7b/R9 UPgjM9dWChVya1FLVAXiBhx6yywlZxCKU4Bcz4hvarq+xW80EMurz2xVqnrkAmfTUt03 pk7GhvFYzgkkdyADzxlKv/4wYBUXy1Ms6pmNTVx/9m1P/SXQyM68E54JNmg8aqaSAyUz iDc94yj4I2awkBp4/7xjUwhrugBdPr/tNG9ZHuI8nRN88im4OlJu/VFhVQDTjgj+Milk mKGI05tcP7C4VFIpr983Pxr16XbLeXhAfG1+WypM7ynsZhrcsebAOlEQsWi8ryJXtwle GSMg== X-Gm-Message-State: APjAAAUl6iOLE9WdV624QEthLvHg0ZfWVmO0GZRwijts/3o7RK6+jYG4 ilrZeeH6rDLQVO3sUMpMCDlzcsnjLnVWh7Apequg8r/HhYknfg== X-Google-Smtp-Source: APXvYqxYrysyrERV3ne4Qrelc/ziYRn+rVxqQ0m+d09ZOTFfpuN5AWmfnIaqyGrgmgK6n7px9T6gkfCGPga0ElO5rYY= X-Received: by 2002:aa7:ccc7:: with SMTP id y7mr13118003edt.45.1581552195910; Wed, 12 Feb 2020 16:03:15 -0800 (PST) MIME-Version: 1.0 References: <89FB1D82-8245-490A-BEF9-6AD5268A3FBC@nokia.com> <5F7FCDF4-0561-46D8-9253-63753704FC7C@nokia.com> In-Reply-To: From: Cyril Margaria Date: Thu, 13 Feb 2020 00:03:04 +0000 Message-ID: To: Tarek Saad Cc: "Stone, Andrew (Nokia - CA/Ottawa)" , "pce@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d4c0bf059e69d00d" Archived-At: Subject: Re: [Pce] Multipath / replication segment comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 00:03:21 -0000 --000000000000d4c0bf059e69d00d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable continued inline , > > [Cyril] There is a related work that ties one tunnel to multiple path, > list of hops : RFC8697, and draft-ietf-pce-stateful-path-protection-11. > Given the mechanism used (and flexibility in term of the individual legs)= , > would it make sense to reuse the path protection mechanisms to tie those > multiple EROs together? In addition it addresses the backup path already. > > [TS]: Consider the case of a PCE delegated SR Policy Candidate Path. The > PCC desires an SR path computation from a PCE that is subject to > constraints =E2=80=93 The PCC has no a-priori idea **how many** Segment-L= ists (SLs) > the PCE path computation will result in-- so it does not know how many (o= r > whether it should at all) create multiple PLSPs with NO-ERO and report th= em > so PCE can respond to each. > The PCC can use a PCReq, PCRep, that allows multiple ERO. What is the drawback of delegating the maximum set of Supported Segment List with no ERO, the association may carry an attribute to indicate to the PCE "Minimize the number of LSP with route" (or it can be a METRIC). The PCC knows how many segment-list per candidate path are supported though (whereas the PCE does not a priori) > The PCC creates **one** PLSP and reports to the PCE the LSP down (with > NO-ERO) along with the specified user constraints. The PCE computes and > determines the feasible number of SLs. Now, it would be awkward for the P= CE > to instantiate PLSPs =E2=80=93 different from the one originally delegate= d by the > PCC=E2=80=94so to encode each SL in its own PLSP and make use the =E2=80= =9Cassociation > object=E2=80=9D method.. I can also imagine complexities in what each PLS= P LSP > would carry in terms of constraints =E2=80=93 especially after some confi= guration > change on the PCC=E2=80=A6 > s/one/all/ and that works with: - limited extensions - reuse the path protection for protection - Any OAM extension and procedure works (as its per path) - The PCC has the freedom to have policies for per (set of) segment-list constraints - The function desired is more the shared control of the number of path between the PCC and the PCE. Stateless PCE uses the LOAD-BALANCING for that, but stateful has a more restrictive definition. A possibility is to reuse the original multiple ERO defined, What is currently a TE-Path, but adapt it to stateful: - allow LOAD-BALANCING (please refer to RFC5440) in PCRpt - the PCE May use multiple ERO and LOAD-BALANCING to *suggest* some alternative paths to the PCC, in case of a candidate path the PCC should create the other PLSPs - The PCE can update the LOAD-BALANCING and suggested ERO, the PCC should update its set of LSPs It keeps the PCE-Controlled number of paths, it can work for other kind of associations that groups traffic together (RSVP, GMPLS) , you can keep OAM and constraints freedom, scenarios like per-destination or region-chain PCE delegation is still allowed The PCC can have more control and options, or keep one LSP with LOAD-BALANCING + candidate path > > The proposal in draft-koldychev-pce-multipath indeed proposes elegant way > to encode all computed SLs (as multiple SERO lists) into a single PLSP = =E2=80=93 > the one originally reported by the delegated PLSP. In fact, this method > allows at anytime the PCE to send PCUpd to add/remove/update SL(s) within= a > single PLSP freely =E2=80=93 which IMO is powerful. > I understand that people like to map their management objects directly, but Its awkward to say that one path is not one path, Anyhow in term of TE and OAM, each segment-list is kind of independent. PCCreate works equally well for a PCE to create/delete paths, the LOAD-BALANCING and suggested EROs offer more flexibility from PCE and PCC. > > > I think the same argument applies to backup paths/SLs too.. The PCC would > not know how many SL(s) can protect a single path, so it would not be abl= e > to a-priori create PLSPs and use association object. > > > Where is the requirement of updating all the segment-list of an > SR-Candidate together coming from? > > > > On an unrelated note, why is it called Candidate-path and not > candidate-multipath, if there are multiple path? > > > > [TS]: please refer to draft-ietf-spring-segment-routing-policy which > defines such terms=E2=80=A6 > > > The draft does not say why its considered a single path when it has multiple physical paths, nor the use of association with multiple PLSP contradict contradict the unit of signaling (the unit of signaling being the association parameters) . --000000000000d4c0bf059e69d00d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
continued inline

<cut>= ,

[Cyril] There is a relat= ed work that ties one tunnel to multiple path, list of hops :=C2=A0 RFC8697= , and=C2=A0draft-ietf-pce-stateful-path-protection-11. Given the mechanism = used (and flexibility in term of the individual legs), would it make sense to reuse the path protection mechanisms to tie = those multiple EROs together? In addition it addresses the backup path alre= ady.=C2=A0

[TS]: Consider the ca= se of a PCE delegated SR Policy Candidate Path. The PCC desires an SR path = computation from a PCE that is subject to constraints =E2=80=93 The PCC has= no a-priori idea **how many** Segment-Lists (SLs) the PCE path computation will result in-- so it does not know how ma= ny (or whether it should at all) create multiple PLSPs with NO-ERO and repo= rt them so PCE can respond to each.


The PCC can use a PCReq, PCRep, that allo= ws multiple ERO. What is the drawback of delegating the maximum set of Supp= orted Segment List with no ERO, the association may carry an attribute to i= ndicate to the PCE "Minimize the number of LSP with route" (or it= can be a METRIC). The PCC knows how many segment-list per candidate path a= re supported though (whereas the PCE does not a priori)=C2=A0
=C2=A0
<= div>

The PCC creates *one* PLSP and rep= orts to the PCE the LSP down (with NO-ERO) along with the specified user co= nstraints. The PCE computes and determines the feasible number of SLs. Now,= it would be awkward for the PCE to instantiate PLSPs =E2=80=93 different from the one original= ly delegated by the PCC=E2=80=94so to encode each SL in its own PLSP and ma= ke use the =E2=80=9Cassociation object=E2=80=9D method.. I can also imagine= complexities in what each PLSP LSP would carry in terms of constraints =E2=80=93 especially after some configuration change on the PCC=E2=80=A6


s/one/all/= and that works with:
=C2=A0 - limited extensions=C2=A0
=C2=A0= - reuse the path protection for protection=C2=A0
=C2=A0 - Any OA= M extension and procedure works (as its per path)=C2=A0
=C2=A0 - = The PCC has the freedom to have policies for per (set of) segment-list cons= traints
=C2=A0 -=C2=A0
=C2=A0
The function desired is more = the shared control of the number of path between the PCC and the PCE. State= less PCE uses the LOAD-BALANCING for that, but stateful has a more restrict= ive definition.=C2=A0
A possibility is to reuse the original mult= iple ERO defined, What is currently a TE-Path, but adapt it to stateful:
=C2=A0 =C2=A0- allow LOAD-BALANCING (please refer to RFC5440) in PC= Rpt=C2=A0
=C2=A0 =C2=A0- the PCE May use multiple ERO and LOAD-BALANCING= to *suggest* some alternative paths to the PCC, in case of a candidate pat= h the PCC should create the other PLSPs=C2=A0
=C2=A0 =C2=A0- The = PCE can update the LOAD-BALANCING and suggested ERO, the PCC should update = its set of LSPs=C2=A0

It keeps the PCE-Controlled = number of paths, it can work for other kind of associations that groups tra= ffic together (RSVP, GMPLS) , you can keep OAM and constraints freedom, sce= narios like per-destination or region-chain PCE delegation is still allowed= =C2=A0
The PCC can have more control and options, or keep one LSP= with LOAD-BALANCING=C2=A0+ candidate path=C2=A0

=C2=A0<= /span>

The proposal in draft-koldychev-pce-multipath indeed= proposes elegant way to encode all computed SLs (as multiple SERO lists) i= nto a single PLSP =E2=80=93 the one originally reported by the delegated PL= SP. In fact, this method allows at anytime the PCE to send PCUpd to add/remove/update S= L(s) within a single PLSP freely =E2=80=93 which IMO is powerful.

=

I understand that= people like to map their management objects directly, but=C2=A0Its awkward= to say that one path is not one path, Anyhow in term of TE and OAM, each s= egment-list is kind of independent.=C2=A0
PCCreate works equally well fo= r a PCE to create/delete paths, the LOAD-BALANCING and suggested EROs offer= more flexibility from PCE and PCC.

=C2=A0

=C2=A0<= /span>

I think the same argu= ment applies to backup paths/SLs too.. The PCC would not know how many SL(s= ) can protect a single path, so it would not be able to a-priori create PLS= Ps and use association object.


Where is the requirement of updating all the segment-list of an SR-Candidat= e together coming from?

=C2=A0

On an unrelated note, why is it called Candidate-path= and not candidate-multipath, if there are multiple path?

=C2=A0

[TS]: please refer to= draft-ietf-spring-segment-routing-policy which defines such terms=E2=80=A6=

=C2=A0

The draft does not say why= its considered a single path when it has multiple physical paths,=C2=A0 no= r the use of association with multiple PLSP contradict contradict the unit = of signaling (the unit of signaling being the association parameters) .



--000000000000d4c0bf059e69d00d-- From nobody Fri Feb 14 07:15:03 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23D1200D7 for ; Fri, 14 Feb 2020 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 YpH314iIGYjZ for ; Fri, 14 Feb 2020 07:15:01 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FFE1200B4 for ; Fri, 14 Feb 2020 07:15:01 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 48Jxkq55TYzykC for ; Fri, 14 Feb 2020 16:14:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581693299; bh=DrNts5bYG8ivrp5cfbjQn8Z3MAIYIoOa0syZq9eG2tU=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=IMoJuQcRJsR4ub4miq1RezgWQWIbbr+/HPw2+zs6YIdES4h5L2HqK7cJdholbPE/g gFuU/p+rFcnq3p0JckXMyOpOCAAMkmtWIOdsailBNSCJOGmTyKwFKnKH1wDV+TkH0O DC0qcETD3CI/QyFlPD6KdC5UBFqU20Yy8A4iY1/okGY3SwM44jzmaHqA55ablGkGfh puoDo2g6tnMKKE3YOxWACom69T52ToC4jsIKPuG/2Za9J5AEFZz0NPRAmHOyaI4Fij Fcxl697D8jDhbG4506CAwWL9qnJjz7OMdBMzrovVwe3J+4PKhpNLH6wMyJz2Ma5Goy oBKePMJ2pLepw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48Jxkq4SHGz8sYR for ; Fri, 14 Feb 2020 16:14:59 +0100 (CET) Received: from [10.193.71.21] (10.114.13.245) by exchange-eme6.itn.ftgroup (10.114.13.104) with Microsoft SMTP Server (TLS) id 14.3.468.0; Fri, 14 Feb 2020 16:14:59 +0100 References: <158169272336.16169.4878680099399918174.idtracker@ietfa.amsl.com> To: "pce@ietf.org" From: Organization: Orange X-Forwarded-Message-Id: <158169272336.16169.4878680099399918174.idtracker@ietfa.amsl.com> Message-ID: <15419_1581693299_5E46B973_15419_300_1_836e19a0-53d7-66d4-f680-88d953a52b52@orange.com> Date: Fri, 14 Feb 2020 16:14:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <158169272336.16169.4878680099399918174.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.114.13.245] Archived-At: Subject: [Pce] Fwd: Last Call: (Working Group GitHub Administration) to Informational RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 15:15:02 -0000 FYI -------- Forwarded Message -------- Subject: Last Call: (Working Group GitHub Administration) to Informational RFC From: The IESG Reply-To: last-call@ietf.org The IESG has received a request from the GitHub Integration and Tooling WG (git) to consider the following document: - 'Working Group GitHub Administration' as Informational RFC 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-02-28. 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 The use of GitHub in IETF working group processes is increasing. This document describes possible uses and conventions for working groups which are considering starting to use GitHub. It does not mandate any processes, and does not require changes to the processes used by current and future working groups not using GitHub. Discussion of this document takes place on the ietf-and-github mailing list (ietf-and-github@ietf.org), which is archived at . The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-git-github-wg-configuration/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-git-github-wg-configuration/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Feb 14 08:02:59 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B66A21200C7; Fri, 14 Feb 2020 08:02:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158169617764.16223.10685629691297573472@ietfa.amsl.com> Date: Fri, 14 Feb 2020 08:02:57 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-sr-bidir-path-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 16:02:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths Authors : Cheng Li Mach(Guoyi) Chen Weiqiang Cheng Rakesh Gandhi Quan Xiong Filename : draft-ietf-pce-sr-bidir-path-01.txt Pages : 16 Date : 2020-02-14 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing (SR) Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single Associated Bidirectional SR Path. The mechanisms defined in this document can also be applied using a Stateful PCE for both PCE- Initiated and PCC-Initiated LSPs, as well as when using a Stateless PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-01 https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-sr-bidir-path-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 Mon Feb 17 21:54:26 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B91112001A; Mon, 17 Feb 2020 21:54:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158200525403.4986.13158417827408275488@ietfa.amsl.com> Date: Mon, 17 Feb 2020 21:54:14 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 05:54:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extension for Native IP Network Authors : Aijun Wang Boris Khasanov Sheng Fang Chun Zhu Filename : draft-ietf-pce-pcep-extension-native-ip-05.txt Pages : 11 Date : 2020-02-17 Abstract: This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. The scenario and framework of CCDR in native IP is described in [I-D.ietf-teas-native-ip-scenarios] and [I-D.ietf-teas-pce-native-ip]. This draft describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in Native IP network under central control mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-05 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-05 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 Feb 20 00:03:45 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FF2120111; Wed, 19 Feb 2020 10:14:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Dhruv Dhody" , "Julien Meuric" , "Stewart Bryant" , "Fatai Zhang" , "Daniele Ceccarelli" , "Andrew Malis" , "Loa Andersson" , "Lou Berger" , "Vishnu Pavan Beeram" , "Tarek Saad" , "Nicolai Leymann" Cc: Deborah Brungard , Julien Meuric , Multiprotocol Label Switching Discussion List , Dhruv Dhody , Pseudowire And LDP-enabled Services Discussion List , Andrew Malis , Common Control and Measurement Plane Discussion List , Traffic Engineering Architecture and Signaling Discussion List , Martin Vigoureux , Scott Mansfield , sshew@ciena.com, Fatai Zhang , Nicolai Leymann , John Drake , Loa Andersson , Daniele Ceccarelli , Vishnu Beeram , Stewart Bryant , Path Computation Element Discussion List , Lou Berger , Tarek Saad , itu-t-liaison@iab.org, Alvaro Retana X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158213607762.17596.1750884122514290928.idtracker@ietfa.amsl.com> Date: Wed, 19 Feb 2020 10:14:37 -0800 Archived-At: X-Mailman-Approved-At: Thu, 20 Feb 2020 00:03:43 -0800 Subject: [Pce] New Liaison Statement, "LS on OTNT Standardization Work Plan Issue 27" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 18:14:38 -0000 Title: LS on OTNT Standardization Work Plan Issue 27 Submission Date: 2020-02-19 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1673/ Please reply by 2020-08-20 From: Hiroshi Ota To: Vishnu Pavan Beeram , Lou Berger ,Andrew Malis ,Stewart Bryant ,Loa Andersson ,Nicolai Leymann ,Tarek Saad ,Julien Meuric ,Dhruv Dhody ,Daniele Ceccarelli ,Fatai Zhang Cc: Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,Dhruv Dhody ,Pseudowire And LDP-enabled Services Discussion List ,Andrew Malis ,Common Control and Measurement Plane Discussion List ,Traffic Engineering Architecture and Signaling Discussion List ,John Drake ,Scott Mansfield ,Fatai Zhang ,Nicolai Leymann ,Martin Vigoureux ,Loa Andersson ,Daniele Ceccarelli ,Vishnu Beeram ,Stewart Bryant ,Path Computation Element Discussion List ,Lou Berger ,Tarek Saad ,itu-t-liaison@iab.org,Alvaro Retana Response Contacts: sshew@ciena.com Technical Contacts: Purpose: For action Body: Attached is Issue 27 of the OTNT SWP, the latest version updated by the SG15 during a plenary meeting in February 2020. We would appreciate updates to the material relevant to your SDO. Attachment: Optical Transport Networks & Technologies Standardization Work Plan Issue 27, February 2020 Attachments: SG15-LS245 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-02-19-itu-t-sg-15-mpls-ccamp-pce-pals-teas-ls-on-otnt-standardization-work-plan-issue-27-attachment-1.pdf SG15-LS245-Att-OTN-issue27 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-02-19-itu-t-sg-15-mpls-ccamp-pce-pals-teas-ls-on-otnt-standardization-work-plan-issue-27-attachment-2.pdf From nobody Tue Feb 25 01:27:45 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED93A02BC; Tue, 25 Feb 2020 01:27:44 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGN_UIbJcasy; Tue, 25 Feb 2020 01:27:41 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 0B8833A02BB; Tue, 25 Feb 2020 01:27:40 -0800 (PST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id BD92F462712F9405FF7A; Tue, 25 Feb 2020 17:27:33 +0800 (CST) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 01P9QtGb078445; Tue, 25 Feb 2020 17:26:55 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Tue, 25 Feb 2020 17:26:54 +0800 (CST) Date: Tue, 25 Feb 2020 17:26:54 +0800 (CST) X-Zmail-TransId: 2af95e54e85e4b743708 X-Mailer: Zmail v1.0 Message-ID: <202002251726543181089@zte.com.cn> In-Reply-To: <158261731278.24343.18211608434891003715.idtracker@ietfa.amsl.com> References: 158261731278.24343.18211608434891003715.idtracker@ietfa.amsl.com Mime-Version: 1.0 From: To: , Cc: , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 01P9QtGb078445 Archived-At: Subject: [Pce] =?utf-8?q?=5BPCE=5D_New_Version_Notification_for_draft-pen?= =?utf-8?q?g-pce-entropy-label-position-02=2Etxt?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 09:27:44 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQoNCg0KDQoNCg0KDQpJIGhhdmUgdXBkYXRlZCB0aGUgdmVyc2lvbiBvZiBkcmFm dC1wZW5nLXBjZS1lbnRyb3B5LWxhYmVsLXBvc2l0aW9uLg0KDQoNClRoaXMgZHJhZnQgaGFzIGJl ZW4gcHJlc2VudGVkIGluIElFVEYjMTA2IG1lZXRpbmcuIFRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr LiBJdCBpcyB2ZXJ5IGFwcHJlY2lhdGVkLg0KDQoNCkkgd291bGQgbGlrZSB0byBtYWtlIGNsYXJp ZmljYXRpb24gYXMgZm9sbG93cyBhbmQgZGlzY3Vzc2lvbnMgYXJlIHZlcnkgd2VsY29tZS4NCg0K DQoNCg0KDQoNCkZpcnN0LCBSRkM4NjYyIHdoaWNoIGhhcyBiZWVuIGp1c3QgcmVsZWFzZWQgcHJv cG9zZXMgdG8gdXNlIGVudHJvcHkgbGFiZWxzIGZvciBTUi1NUExTIG5ldHdvcmtzIGFuZCB0aGUg U1IgaW5ncmVzcyBub2RlIGhhcyB0aGUgY2FwYWJpbGl0eSB0byBpbnNlcnQgbXVsdGlwbGUgRUxJ LyBFTCBwYWlycyBpbiB0aGUgU1ItTVBMUyBsYWJlbCBzdGFjay4NCg0KDQoNCg0KDQoNClNlY29u ZCwgdGhlIFBDRSBpcyB1c2VmdWxsIGVzcGVjaWFsbHkgZm9yIGludGVyLWRvbWFpbiBzY2VuYXJp b3MgdG8gcGVyZm9ybSB0aGUgVEUgcGF0aCBjb21wdXRhdGlvbiBhcyB3ZWxsIGFzIHRoZSBFbnRy b3B5IExhYmVsIFBvc2l0aW9uDQoNCg0KICAgKEVMUCkgYXMgdGhlIFBDRSBjb3VsZCBnZXQgdGhl IE1TRCAsIEVSTEQgYW5kIG1vcmUgb3RoZXIgaW5mb3JtYXRpb24uDQoNCg0KDQoNCg0KDQpUaGly ZCwgb3VyIGRyYWZ0IGhhcyBleHRlbmQgdGhlIE9QRU4gbWVzc2FnZSB0byBpbmRpY2F0ZSB0aGUg aW5ncmVzcyBzdXBwb3J0cyB0aGUgY2FwYWJpbGl0eSBvZiBpbnNlcnRpbmcgbXVsdGlwbGUgRUxJ L0VMIHBhaXJzIGFuZCBhbmQgc3VwcG9ydHMgdGhlIHJlc3VsdHMgb2YgU1IgcGF0aCB3aXRoIEVM UCBmcm9tIFBDRS4NCg0KDQoNCg0KDQoNCkZpbmFsbHksIHJlZ2FyZGluZyB0aGUgZXh0ZW5kZWQg ZmxhZywgSSBoYXZlIG1vdmUgdGhhdCB0byBhIG5ldyBkcmFmdCB3aGljaCBoYXMgYmVlbiBkaXNj dXNzZWQgaW4gdGhlIG1haWxpbmcgbGlzdC4NCg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC14aW9uZy1wY2UtbHNwLWZsYWcvDQoNCg0KDQoNCg0KDQoNCg0KDQpCZXN0 IFJlZ2FyZHMsDQoNCg0KUXVhbg0KDQoNCg0KDQoNCg0KDQoNCg0KDQrljp/lp4vpgq7ku7YNCg0K DQoNCuWPkeS7tuS6uu+8mmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPg0K5pS25Lu25Lq677ya5b2t5bCR5a+MMTAwNTM4MTU7RmVuZ3dlaSBRaW4gPHFp bmZlbmd3ZWlAY2hpbmFtb2JpbGUuY29tPjvnhorms4kwMDA5MTA2NTsNCuaXpSDmnJ8g77yaMjAy MOW5tDAy5pyIMjXml6UgMTU6NTUNCuS4uyDpopgg77yaTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1wZW5nLXBjZS1lbnRyb3B5LWxhYmVsLXBvc2l0aW9uLTAyLnR4dA0KDQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBlbmctcGNlLWVudHJvcHktbGFiZWwtcG9zaXRp b24tMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFF1YW4gWGlvbmcg YW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgIGRyYWZ0 LXBlbmctcGNlLWVudHJvcHktbGFiZWwtcG9zaXRpb24NClJldmlzaW9uOiAgICAwMg0KVGl0bGU6 ICAgICAgICBQQ0VQIEV4dGVuc2lvbiBmb3IgU1ItTVBMUyBFbnRyb3B5IExhYmVsIFBvc2l0aW9u DQpEb2N1bWVudCBkYXRlOiAgICAyMDIwLTAyLTI0DQpHcm91cDogICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICA4DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBlbmctcGNlLWVudHJvcHktbGFiZWwtcG9z aXRpb24tMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcGVuZy1wY2UtZW50cm9weS1sYWJlbC1wb3NpdGlvbi8NCkh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVuZy1wY2UtZW50cm9weS1s YWJlbC1wb3NpdGlvbi0wMg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcGVuZy1wY2UtZW50cm9weS1sYWJlbC1wb3NpdGlvbg0KRGlm ZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wZW5n LXBjZS1lbnRyb3B5LWxhYmVsLXBvc2l0aW9uLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1 bWVudCBwcm9wb3NlcyBhIHNldCBvZiBleHRlbnNpb25zIGZvciBQQ0VQIHRvIGNvbmZpZ3VyZSB0 aGUNCiAgIGVudHJvcHkgbGFiZWwgcG9zaXRpb24gZm9yIFNSLU1QTFMgbmV0d29ya3MuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZh bWlseTphcmlhbDsiPkhpIGFsbCw8YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250 LWZhbWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFt aWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMjBweDsiPkkgaGF2ZSB1cGRhdGVk IHRoZSB2ZXJzaW9uIG9mJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogc2Fu cy1zZXJpZjsiPmRyYWZ0LXBlbmctcGNlLWVudHJvcHktbGFiZWwtcG9zaXRpb24uPC9zcGFuPjwv cD48cCBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyI+VGhpcyBkcmFmdCBoYXMgYmVlbiBwcmVzZW50 ZWQgaW4gSUVURiMxMDYgbWVldGluZy4gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suIEl0IGlzIHZl cnkgYXBwcmVjaWF0ZWQuPC9wPjxwIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij5JIHdvdWxkIGxp a2UgdG8gbWFrZSBjbGFyaWZpY2F0aW9uIGFzIGZvbGxvd3MgYW5kIGRpc2N1c3Npb25zIGFyZSB2 ZXJ5IHdlbGNvbWUuPC9wPjxwIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij48YnI+PC9wPjxwIHN0 eWxlPSJmb250LXNpemU6IDIwcHg7Ij5GaXJzdCwmbmJzcDtSRkM4NjYyIHdoaWNoIGhhcyBiZWVu IGp1c3QgcmVsZWFzZWQgcHJvcG9zZXMgdG8gdXNlIGVudHJvcHkgbGFiZWxzIGZvciBTUi1NUExT IG5ldHdvcmtzIGFuZCB0aGUgU1IgaW5ncmVzcyBub2RlIGhhcyB0aGUgY2FwYWJpbGl0eSB0byBp bnNlcnQgbXVsdGlwbGUgRUxJLyZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij5F TCBwYWlycyBpbiZuYnNwO3RoZSBTUi1NUExTIGxhYmVsIHN0YWNrLjwvc3Bhbj48L3A+PHAgc3R5 bGU9ImZvbnQtc2l6ZTogMjBweDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij48YnI+ PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMjBweDsiPlNlY29uZCwgdGhlIFBDRSBpcyB1c2VmdWxsJm5ic3A7PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDMwcHg7Ij5lc3BlY2lhbGx5IGZvciBpbnRl ci1kb21haW4gc2NlbmFyaW9zIHRvJm5ic3A7PC9zcGFuPjwvc3Bhbj5wZXJmb3JtIHRoZSBURSBw YXRoIGNvbXB1dGF0aW9uIGFzIHdlbGwgYXMgdGhlIEVudHJvcHkgTGFiZWwgUG9zaXRpb248L3A+ PHAgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMjBweDsiPiZuYnNwOyAmbmJzcDsoRUxQKSBhcyB0aGUgUENFIGNv dWxkIGdldCZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAz MHB4OyI+dGhlIE1TRCAsIEVSTEQgYW5kIG1vcmUgb3RoZXIgaW5mb3JtYXRpb24uPC9zcGFuPjwv c3Bhbj48L3A+PHAgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMjBweDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDIwcHg7IGxpbmUtaGVpZ2h0OiAzMHB4OyI+PGJyPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxl PSJsaW5lLWhlaWdodDogMjFweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAzMHB4OyI+VGhpcmQsIG91ciBkcmFmdCBoYXMg ZXh0ZW5kIHRoZSBPUEVOIG1lc3NhZ2UgdG8mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMjBweDsiPmluZGljYXRlIHRoZSBpbmdyZXNzIHN1cHBvcnRzIHRoZSBjYXBhYmlsaXR5 IG9mIGluc2VydGluZyBtdWx0aXBsZSBFTEkvRUwgcGFpcnMgYW5kIGFuZCBzdXBwb3J0cyB0aGUg cmVzdWx0cyBvZiBTUiBwYXRoIHdpdGggRUxQIGZyb20gUENFLjwvc3Bhbj48L3A+PHAgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMjBweDsiPjxicj48L3NwYW4+PC9wPjxwIHN0eWxlPSJsaW5lLWhlaWdodDogMjFw eDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij5G aW5hbGx5LCByPC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsgZm9udC1zaXpl OiAyMHB4OyI+ZWdhcmRpbmcgdGhlIGV4dGVuZGVkIGZsYWcsIEkgaGF2ZSBtb3ZlIHRoYXQgdG8g YSBuZXcgZHJhZnQgd2hpY2ggaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBtYWlsaW5nIGxpc3Qu PC9zcGFuPjwvcD48cCBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7IHdoaXRlLXNwYWNlOiBub3Jt YWw7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7IGZvbnQtc2l6ZTogMjBweDsiPjxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpb25nLXBjZS1s c3AtZmxhZy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpb25nLXBj ZS1sc3AtZmxhZy88L2E+PC9zcGFuPjwvcD48cCBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7IHdo aXRlLXNwYWNlOiBub3JtYWw7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyI+PC9zcGFu PjwvcD48cCBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMzBweDsiPjwvc3Bhbj48 YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij5CZXN0IFJlZ2FyZHMsPC9wPjxwIHN0 eWxlPSJmb250LXNpemU6IDIwcHg7Ij5RdWFuPC9wPjxwIHN0eWxlPSJmb250LXNpemU6IDIwcHg7 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyI+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IHNhbnMtc2VyaWY7Ij48YnI+PC9zcGFuPjwvcD48ZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Um93 IiBzdHlsZT0iZGlzcGxheTpibG9jayI+PGRpdiBjbGFzcz0iemhpc3RvcnlEZXMiIHN0eWxlPSJ3 aWR0aDogMTAwJTsgaGVpZ2h0OiAyOHB4OyBsaW5lLWhlaWdodDogMjhweDsgYmFja2dyb3VuZC1j b2xvcjogI0UwRTVFOTsgY29sb3I6ICMxMzg4RkY7IHRleHQtYWxpZ246IGNlbnRlcjsiIGxhbmd1 YWdlLWRhdGE9Ikhpc3RvcnlPcmdUeHQiPuWOn+Wni+mCruS7tjwvZGl2PjxkaXYgaWQ9Inp3cml0 ZUhpc3RvcnlDb250YWluZXIiPjxkaXYgY2xhc3M9ImNvbnRyb2wtZ3JvdXAgemhpc3RvcnlQYW5l bCI+PGRpdiBjbGFzcz0iemhpc3RvcnlIZWFkZXIiIHN0eWxlPSJwYWRkaW5nOiA4cHg7IGJhY2tn cm91bmQtY29sb3I6ICNGNUY2Rjg7Ij48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9y eVNlbmRlclR4dCI+5Y+R5Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5h bWUiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyAmbHQ7aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Jmd0Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVRPVHh0 Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9 ImRpc3BsYXk6IGlubGluZTsiPuW9reWwkeWvjDEwMDUzODE1O0Zlbmd3ZWkgUWluICZsdDtxaW5m ZW5nd2VpQGNoaW5hbW9iaWxlLmNvbSZndDs754aK5rOJMDAwOTEwNjU7PC9zcGFuPjwvZGl2Pjxk aXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5RGF0ZVR4dCI+5pelIOacnyDvvJo8L3N0 cm9uZz48c3BhbiBjbGFzcz0iIj4yMDIw5bm0MDLmnIgyNeaXpSAxNTo1NTwvc3Bhbj48L2Rpdj48 ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVN1YmplY3RUeHQiPuS4uyDpopgg77ya PC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0bGUiPjxzdHJvbmc+TmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1wZW5nLXBjZS1lbnRyb3B5LWxhYmVsLXBvc2l0aW9uLTAyLnR4 dDwvc3Ryb25nPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRlbnQi PjxkaXY+PGJyPkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDtJLUQsJm5ic3A7 ZHJhZnQtcGVuZy1wY2UtZW50cm9weS1sYWJlbC1wb3NpdGlvbi0wMi50eHQ8YnI+aGFzJm5ic3A7 YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNwO2J5Jm5ic3A7UXVhbiZu YnNwO1hpb25nJm5ic3A7YW5kJm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJzcDt0aGU8YnI+SUVURiZu YnNwO3JlcG9zaXRvcnkuPGJyPjxicj5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LXBlbmctcGNlLWVudHJvcHktbGFiZWwtcG9zaXRpb248 YnI+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MDI8YnI+VGl0bGU6Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UENFUCZuYnNwO0V4dGVuc2lv biZuYnNwO2ZvciZuYnNwO1NSLU1QTFMmbmJzcDtFbnRyb3B5Jm5ic3A7TGFiZWwmbmJzcDtQb3Np dGlvbjxicj5Eb2N1bWVudCZuYnNwO2RhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MjAyMC0w Mi0yNDxicj5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtJbmRpdmlkdWFsJm5ic3A7U3VibWlzc2lvbjxicj5QYWdlczombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs4PGJyPlVSTDombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDto dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGVuZy1wY2UtZW50cm9w eS1sYWJlbC1wb3NpdGlvbi0wMi50eHQ8YnI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXBlbmctcGNlLWVudHJvcHktbGFiZWwtcG9zaXRpb24vPGJyPkh0bWxpemVk OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW5nLXBjZS1lbnRyb3B5LWxhYmVsLXBvc2l0aW9uLTAyPGJy Pkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcGVuZy1wY2UtZW50cm9weS1s YWJlbC1wb3NpdGlvbjxicj5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1wZW5nLXBjZS1lbnRyb3B5LWxhYmVsLXBvc2l0aW9uLTAyPGJyPjxicj5B YnN0cmFjdDo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7cHJv cG9zZXMmbmJzcDthJm5ic3A7c2V0Jm5ic3A7b2YmbmJzcDtleHRlbnNpb25zJm5ic3A7Zm9yJm5i c3A7UENFUCZuYnNwO3RvJm5ic3A7Y29uZmlndXJlJm5ic3A7dGhlPGJyPiZuYnNwOyZuYnNwOyZu YnNwO2VudHJvcHkmbmJzcDtsYWJlbCZuYnNwO3Bvc2l0aW9uJm5ic3A7Zm9yJm5ic3A7U1ItTVBM UyZuYnNwO25ldHdvcmtzLjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PGJyPjxicj48YnI+UGxlYXNlJm5ic3A7bm90ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO21h eSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291cGxlJm5ic3A7b2YmbmJzcDttaW51dGVzJm5ic3A7 ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDtvZiZuYnNwO3N1Ym1pc3Npb248YnI+dW50aWwm bmJzcDt0aGUmbmJzcDtodG1saXplZCZuYnNwO3ZlcnNpb24mbmJzcDthbmQmbmJzcDtkaWZmJm5i c3A7YXJlJm5ic3A7YXZhaWxhYmxlJm5ic3A7YXQmbmJzcDt0b29scy5pZXRmLm9yZy48YnI+PGJy PlRoZSZuYnNwO0lFVEYmbmJzcDtTZWNyZXRhcmlhdDxicj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Tue Feb 25 16:59:07 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F3E3A0529; Tue, 25 Feb 2020 16:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 8G1_6YlBKV35; Tue, 25 Feb 2020 16:58:53 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA803A00E2; Tue, 25 Feb 2020 16:58:53 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 36847F4073C; Tue, 25 Feb 2020 16:58:41 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, pce@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200226005841.36847F4073C@rfc-editor.org> Date: Tue, 25 Feb 2020 16:58:41 -0800 (PST) Archived-At: Subject: [Pce] =?utf-8?q?RFC_8733_on_Path_Computation_Element_Communicati?= =?utf-8?q?on_Protocol_=28PCEP=29_Extensions_for_MPLS-TE_Label_Switched_Pa?= =?utf-8?q?th_=28LSP=29_Auto-Bandwidth_Adjustment_with_Stateful_PCE?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 00:59:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8733 Title: Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE Author: D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang Status: Standards Track Stream: IETF Date: February 2020 Mailbox: dhruv.ietf@gmail.com, rgandhi@cisco.com, udayasreereddy@gmail.com, ravi.singh.ietf@gmail.com, luyuanf@gmail.com Pages: 32 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt URL: https://www.rfc-editor.org/info/rfc8733 DOI: 10.17487/RFC8733 The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP. The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs. This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Feb 28 14:35:40 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFAE3A1F74; Fri, 28 Feb 2020 14:34:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: db3546@att.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292929882.19931.14967778516783926019@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:34:58 -0800 Archived-At: Subject: [Pce] pce - Requested session has been scheduled for IETF 107 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:07 -0000 Dear Dhruv Dhody, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. pce Session 1 (2:00 requested) Tuesday, 24 March 2020, Afternoon Session I 1330-1530 Room Name: Plaza B/C size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/pce.ics Request Information: --------------------------------------------------------- Working Group Name: Path Computation Element Area Name: Routing Area Session Requester: Dhruv Dhody Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: spring teas ccamp Technology Overlap: bier panrg mpls Key Participant Conflict: rift rtgwg detnet idr lsr sfc pals opsawg bess netconf netmod 6man People who must be present: Deborah Brungard Julien Meuric Dhruv Dhody Hariharan Ananthakrishnan Resources Requested: Special Requests: Do not schedule against RTG area BOF (if any) ---------------------------------------------------------