From nobody Fri May 1 03:58:07 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C111B3036 for ; Fri, 1 May 2015 03:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gwKkwMj7h20F for ; Fri, 1 May 2015 03:58:03 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1E81ACD95 for ; Fri, 1 May 2015 03:58:02 -0700 (PDT) Received: from [2.68.108.37] (2.68.108.37.mobile.tre.se [2.68.108.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8390F1801591; Fri, 1 May 2015 12:58:00 +0200 (CEST) Message-ID: <55435C39.5050208@pi.nu> Date: Fri, 01 May 2015 12:58:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Aissaoui, Mustapha (Mustapha)" , "Andrew G. Malis" References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 10:58:06 -0000 Mustapha and Andy, If we are talking about manual configure (manually installed labels), this is not what is not what is going on in the hard-pipe network. It is of course possible to run any MPLS network with all or a subset of the labels manually installed. We did that in 1999 whenm I worked with a Swedish operator. Awaiting tests and decision on the mix of signalling protocols we for several months did run our network by installing all labels manually, we never thought about that as "static", but I could live with that terminology if we want to use it. What is going on in the hard-pipe network is a bit different. The NMS (centralized controller) is configured with a label space per node to be used for the hard-pipe stratum. The NMS then allocate labels to be installed on the nodes as a LSP is requested and remove them and returns them to the pool when the LSP is taken down. I tend to think about this as dynamic configured labels. Dynamic as they are installed and removed depending on the life time of the LSPs. Configured as it is done by the NMS. Mustapha, Would "configured labels" cover the concerns you have. /Loa On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote: > Thanks Andy for the reference. Indeed, I was referring to assignment of > initial label and of any subsequent label change of an LSP or a PW by > configuration. This is sometimes referred to as “manual” configuration > and the LSP or PW is referred to as static. > > That definition fits I believe what is being described in > draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm. > > Regards, > > Mustapha. > > *From:*Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Thursday, April 30, 2015 8:52 AM > *To:* Loa Andersson > *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Nevil Brownlee > *Subject:* Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 > > Loa, > > I think the reference that you're looking for is section 3.11 of RFC 5921. > > Cheers, > > Andy > > On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson > wrote: > > Mustapha, > > That is still not a definition possible to refrence. > > I've always been a bit confused by the distinction between "static" and > "dynamic", especially when it comes to labels, a bit less so if we talk > about LSPs. > > To me the term "static" and "dynamic" seems to indicate how long lived > or how easy they are to change. > > If an NMS or any centralized controller instal and remove LSPs/labels > with the same frequency as e.g. LDP are they still "static"? > > I agree that there is a possible classification of "configured > LSPs/labels" vs. "signaled LSPs/labels". > > In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses > configured labels. > > Would that terminology be acceptable for you? > > /Loa > > > > On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote: > > Hi Loa, > By static label, I meant a label which is assigned to a LSP or a PW by > configuration and not by a control plane protocol. I believe this is > what is being described in this draft but let me know if I am wrong. > > Regards, > Mustapha. > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu ] > Sent: Wednesday, April 29, 2015 3:21 AM > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: Nevil Brownlee > Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 > > Mustapha, > > in line please. > > On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: > > Dear all, > I was asked to review this draft which is intended to be handled in the > > Independent Stream. Below are my comments to the authors. > > > Members of this list can also provide comments to the authors. Please > copy the > > Independent Submission Editorial Board at the following address: > > rfc-ise@rfc-editor.org > > Regards, > Mustapha. > ---------------------------- > https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 > > 1. Overall comment: > This document describes how a guaranteed bandwidth service can be deployed > > in a MPLS network by partitioning the network resources into two managed > layers, > referred to as strata. The guaranteed service layer is referred to as > "Hard Pipe" > stratum. > > > The management of the resources and the placement of the MPLS tunnels and > > services into the "Hard Pipe" stratum are performed with a management > system. > Thus the transport and service labels are static but this important > information has > not been stated upfront in the document. > > Do you have a a definition of "static labels" that we can refer to? > > /Loa > Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference > to T- > LDP signaled labels in Section 3 adds to the confusion. > > I propose that the Introduction and Scope sections be explicit about the > > framework used to achieve the "Hard Pipe" stratum, that is by means of a > management system and static transport and service labels. > > > In fact, I would think the document value would be in describing more > details of > > the framework including configuration aspects, resource and service > management > including resilience. These aspects have not been sufficiently addressed > and the > focus was more on how to use MPLS labels to differentiate the two strata. > > > 2. Section 1.1 - Scope: > As part of the second bullet, I cannot find in the document how a router > protects > > the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" stratum > overbooks a > link. Having a separate label for the guaranteed service is not > sufficient. The > authors should describe if LSP pre-emption and/or QoS markings are used to > differentiate the treatment across the strata. > > > 3. Section 3: > If the document objective is to describe the framework used, then this > section > > should begin by explaining the initial configuration performed by the > NMS to lay > the ground for the building of the two stratums. This includes the > partitioning of the > links, the assignment of transport and service label ranges in the > routers, the > overbooking strategy, etc. > > > Then, you can discuss how a guaranteed service is configured in the network > > using static transport labels and static service labels. This should > cover the > placement of the working and backup paths since Section 6 mentions MPLS-TP > protection is used. > > > Next, a description of how the transport LSP and service are monitored for > > continuity and defects. > > > Finally, the behavior when resources are overbooked and what services > are pre- > > empted or degraded should be described. > > ------------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri May 1 06:37:23 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFB81B31A9 for ; Fri, 1 May 2015 06:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 C4KS6MKW3R5U for ; Fri, 1 May 2015 06:37:19 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139BA1B29BA for ; Fri, 1 May 2015 06:37:19 -0700 (PDT) Received: by wizk4 with SMTP id k4so52866314wiz.1 for ; Fri, 01 May 2015 06:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8Prj/8JoprklOWbRRxvobZ+SOYj6N9zO7CA2SDvd9oM=; b=ctRGBpIwjwmG90fIXfqVjLSjadlQHtReCUt5Pg0xPzrs0iUNNSSF7SO/R2evnwXKw+ 4WaeP4WUtUMrgUGm5qnHXrbKcD9ZlNgReetWKIsvxLIOgbtrP4dwxwdD+2lyXtA5wYmW ljehyN0XtJo8KikAcb3ZCvmbQO4JD+hsLpQ6xOIcRTWJ4dzcQqiLd+9F55LHJpEtc/Lw jOSEjybd/51l5hReVC/6Jhv/cd0UXsAmGz7G92UYeywVLbf8wGPdAbtHbH1PdkiPwpdw 1rS7x+pfpVxvWlvTv7UmeOx6ZdWDO5isGicsELAOfZyob3Nv112osKYWlEqYX6kyEZMg /MWQ== X-Received: by 10.181.11.227 with SMTP id el3mr14664609wid.87.1430487437711; Fri, 01 May 2015 06:37:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.182.215 with HTTP; Fri, 1 May 2015 06:36:57 -0700 (PDT) In-Reply-To: <55435C39.5050208@pi.nu> References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu> From: "Andrew G. Malis" Date: Fri, 1 May 2015 09:36:57 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=f46d043be25e949f490515054fdf Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 13:37:23 -0000 --f46d043be25e949f490515054fdf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Loa, Those are exactly "static" labels as we've defined them for MPLS-TP, as they aren't being installed by a dynamic control plane on the routers (LDP or RSVP-TE). See the text in section 3.11 of RFC 5921: A PW or LSP may be statically configured without the support of a dynamic control plane. This may be either by direct configuration of the PEs/LSRs or via a network management system. Cheers, Andy On Fri, May 1, 2015 at 6:58 AM, Loa Andersson wrote: > Mustapha and Andy, > > If we are talking about manual configure (manually installed labels), > this is not what is not what is going on in the hard-pipe network. > > It is of course possible to run any MPLS network with all or a subset > of the labels manually installed. We did that in 1999 whenm I worked > with a Swedish operator. Awaiting tests and decision on the mix of > signalling protocols we for several months did run our network by > installing all labels manually, we never thought about that as "static", > but I could live with that terminology if we want to use it. > > What is going on in the hard-pipe network is a bit different. The NMS > (centralized controller) is configured with a label space per node to > be used for the hard-pipe stratum. The NMS then allocate labels to be > installed on the nodes as a LSP is requested and remove them and returns > them to the pool when the LSP is taken down. > > I tend to think about this as dynamic configured labels. Dynamic as > they are installed and removed depending on the life time of the LSPs. > Configured as it is done by the NMS. > > Mustapha, > > Would "configured labels" cover the concerns you have. > > /Loa > > On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote: > >> Thanks Andy for the reference. Indeed, I was referring to assignment of >> initial label and of any subsequent label change of an LSP or a PW by >> configuration. This is sometimes referred to as =E2=80=9Cmanual=E2=80=9D= configuration >> and the LSP or PW is referred to as static. >> >> That definition fits I believe what is being described in >> draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm. >> >> Regards, >> >> Mustapha. >> >> *From:*Andrew G. Malis [mailto:agmalis@gmail.com] >> *Sent:* Thursday, April 30, 2015 8:52 AM >> *To:* Loa Andersson >> *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Nevil Brownlee >> *Subject:* Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 >> >> Loa, >> >> I think the reference that you're looking for is section 3.11 of RFC 592= 1. >> >> Cheers, >> >> Andy >> >> On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson > > wrote: >> >> Mustapha, >> >> That is still not a definition possible to refrence. >> >> I've always been a bit confused by the distinction between "static" and >> "dynamic", especially when it comes to labels, a bit less so if we talk >> about LSPs. >> >> To me the term "static" and "dynamic" seems to indicate how long lived >> or how easy they are to change. >> >> If an NMS or any centralized controller instal and remove LSPs/labels >> with the same frequency as e.g. LDP are they still "static"? >> >> I agree that there is a possible classification of "configured >> LSPs/labels" vs. "signaled LSPs/labels". >> >> In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses >> configured labels. >> >> Would that terminology be acceptable for you? >> >> /Loa >> >> >> >> On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote: >> >> Hi Loa, >> By static label, I meant a label which is assigned to a LSP or a PW by >> configuration and not by a control plane protocol. I believe this is >> what is being described in this draft but let me know if I am wrong. >> >> Regards, >> Mustapha. >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu ] >> Sent: Wednesday, April 29, 2015 3:21 AM >> To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> Cc: Nevil Brownlee >> Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 >> >> Mustapha, >> >> in line please. >> >> On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: >> >> Dear all, >> I was asked to review this draft which is intended to be handled in the >> >> Independent Stream. Below are my comments to the authors. >> >> >> Members of this list can also provide comments to the authors. Please >> copy the >> >> Independent Submission Editorial Board at the following address: >> >> rfc-ise@rfc-editor.org >> >> >> Regards, >> Mustapha. >> ---------------------------- >> https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 >> >> 1. Overall comment: >> This document describes how a guaranteed bandwidth service can be deploy= ed >> >> in a MPLS network by partitioning the network resources into two managed >> layers, >> referred to as strata. The guaranteed service layer is referred to as >> "Hard Pipe" >> stratum. >> >> >> The management of the resources and the placement of the MPLS tunnels an= d >> >> services into the "Hard Pipe" stratum are performed with a management >> system. >> Thus the transport and service labels are static but this important >> information has >> not been stated upfront in the document. >> >> Do you have a a definition of "static labels" that we can refer to? >> >> /Loa >> Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference >> to T- >> LDP signaled labels in Section 3 adds to the confusion. >> >> I propose that the Introduction and Scope sections be explicit about >> the >> >> framework used to achieve the "Hard Pipe" stratum, that is by means of a >> management system and static transport and service labels. >> >> >> In fact, I would think the document value would be in describing more >> details of >> >> the framework including configuration aspects, resource and service >> management >> including resilience. These aspects have not been sufficiently addressed >> and the >> focus was more on how to use MPLS labels to differentiate the two strata= . >> >> >> 2. Section 1.1 - Scope: >> As part of the second bullet, I cannot find in the document how a router >> protects >> >> the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" stratum >> overbooks a >> link. Having a separate label for the guaranteed service is not >> sufficient. The >> authors should describe if LSP pre-emption and/or QoS markings are used = to >> differentiate the treatment across the strata. >> >> >> 3. Section 3: >> If the document objective is to describe the framework used, then this >> section >> >> should begin by explaining the initial configuration performed by the >> NMS to lay >> the ground for the building of the two stratums. This includes the >> partitioning of the >> links, the assignment of transport and service label ranges in the >> routers, the >> overbooking strategy, etc. >> >> >> Then, you can discuss how a guaranteed service is configured in the >> network >> >> using static transport labels and static service labels. This should >> cover the >> placement of the working and backup paths since Section 6 mentions MPLS-= TP >> protection is used. >> >> >> Next, a description of how the transport LSP and service are monitored f= or >> >> continuity and defects. >> >> >> Finally, the behavior when resources are overbooked and what services >> are pre- >> >> empted or degraded should be described. >> >> ------------------------------------ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --f46d043be25e949f490515054fdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

Those are exactly "static&quo= t; labels as we've defined them for MPLS-TP, as they aren't being i= nstalled by a dynamic control plane on the routers (LDP or RSVP-TE). See th= e text in section 3.11 of RFC 5921:

   A PW or LSP may be statically configured without the support of =
a
   dynamic control plane.  This may be either by direct configuration of
   the PEs/LSRs or via a network management system.

Cheers,
Andy


On Fri, May 1, 2015 at 6:58 AM, Loa= Andersson <loa@pi.nu> wrote:
Must= apha and Andy,

If we are talking about manual configure (manually installed labels),
this is not what is not what is going on in the hard-pipe network.

It is of course possible to run any MPLS network with all or a subset
of the labels manually installed. We did that in 1999 whenm I worked
with a Swedish operator. Awaiting tests and decision on the mix of
signalling protocols we for several months did run our network by
installing all labels manually, we never thought about that as "static= ",
but I could live with that terminology if we want to use it.

What is going on in the hard-pipe network is a bit different. The NMS
(centralized controller) is configured with a label space per node to
be used for the hard-pipe stratum. The NMS then allocate labels to be
installed on the nodes as a LSP is requested and remove them and returns them to the pool when the LSP is taken down.

I tend to think about this as dynamic configured labels. Dynamic as
they are installed and removed depending on the life time of the LSPs.
Configured as it is done by the NMS.

Mustapha,

Would "configured labels" cover the concerns you have.

/Loa

On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote:
Thanks Andy for the reference. Indeed, I was referring to assignment of
initial label and of any subsequent label change of an LSP or a PW by
configuration. This is sometimes referred to as =E2=80=9Cmanual=E2=80=9D co= nfiguration
and the LSP or PW is referred to as static.

That definition fits I believe what is being described in
draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm.

Regards,

Mustapha.

 *From:*Andrew G. Malis [mailto:agmalis@gmail.com]
*Sent:* Thursday, April 30, 2015 8:52 AM
*To:* Loa Andersson
*Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Nevil Brownlee
*Subject:* Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01

Loa,

I think the reference that you're looking for is section 3.11 of RFC 59= 21.

Cheers,

Andy

On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson <loa@pi.nu
<mailto:loa@pi.nu>= > wrote:

Mustapha,

That is still not a definition possible to refrence.

I've always been a bit confused by the distinction between "static= " and
"dynamic", especially when it comes to labels, a bit less so if w= e talk
about LSPs.

To me the term=C2=A0 "static" and "dynamic" seems to in= dicate how long lived
or how easy they are to change.

If an NMS or any centralized controller instal and remove LSPs/labels
with the same frequency as e.g. LDP are they still "static"?

I agree that there is a possible classification of "configured
LSPs/labels" vs. "signaled LSPs/labels".

In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses
configured labels.

Would that terminology be acceptable for you?

/Loa



On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote:

Hi Loa,
By static label, I meant a label which is assigned to a LSP or a PW by
configuration and not by a control plane protocol. I believe this is
what is being described in this draft but let me know if I am wrong.

Regards,
Mustapha.

-----Original Message-----
From: Loa Andersson [mailto:= loa@pi.nu <mailto:loa= @pi.nu>]
Sent: Wednesday, April 29, 2015 3:21 AM
 To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org <mailto:mpls@ietf.org>
Cc: Nevil Brownlee
Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01

Mustapha,

in line please.

On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote:

Dear all,
I was asked to review this draft which is intended to be handled in the

Independent Stream. Below are my comments to the authors.


Members of this list can also provide comments to the authors. Please
copy the

Independent Submission Editorial Board at the following address:

rfc-ise@= rfc-editor.org <mailto:rfc-ise@rfc-editor.org>


Regards,
Mustapha.
----------------------------
https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01

1. Overall comment:
This document describes how a guaranteed bandwidth service can be deployed<= br>
in a MPLS network by partitioning the network resources into two managed layers,
referred to as strata. The=C2=A0 guaranteed service layer is referred to as=
"Hard Pipe"
stratum.


The management of the resources and the placement of the MPLS tunnels and
services into the=C2=A0 "Hard Pipe" stratum are performed with a = management
system.
Thus the transport and service labels are static but this important
information has
not been stated upfront in the document.

Do you have a a definition of "static labels" that we can refer t= o?

/Loa
Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference to T-
LDP signaled labels in Section 3 adds to the confusion.

=C2=A0 =C2=A0 I propose that the Introduction and Scope sections be explici= t about the

framework used to achieve the "Hard Pipe" stratum, that is by mea= ns of a
management system and static transport and service labels.


In fact, I would think the document value would be in describing more
details of

the framework including configuration aspects, resource and service
management
including resilience. These aspects have not been sufficiently addressed and the
focus was more on how to use MPLS labels to differentiate the two strata.

2. Section 1.1 - Scope:
As part of the second bullet, I cannot find in the document how a router protects

the traffic of the "Hard Pipe" stratum if the "Normal IP/MPL= S" stratum
overbooks a
link. Having a separate label for the guaranteed service is not
sufficient. The
authors should describe if LSP pre-emption and/or QoS markings are used to<= br> differentiate the treatment across the strata.


3. Section 3:
If the document objective is to describe the framework used, then this
section

should begin by explaining the initial configuration performed by the
NMS to lay
the ground for the building of the two stratums. This includes the
partitioning of the
links, the assignment of transport and service label ranges in the
routers, the
overbooking strategy, etc.


Then, you can discuss how a guaranteed service is configured in the network=

using static transport labels and static service labels. This should
cover the
placement of the working and backup paths since Section 6 mentions MPLS-TP<= br> protection is used.


Next, a description of how the transport LSP and service are monitored for<= br>
continuity and defects.


Finally, the behavior when resources are overbooked and what services
are pre-

empted or degraded should be described.

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

_______________________________________________
mpls mailing list
mpls@ietf.or= g <mailto:mpls@ie= tf.org>
ht= tps://www.ietf.org/mailman/listinfo/mpls


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
 <mailto:loa@m= ail01.huawei.com>
Senior MPLS Expert loa@pi.nu= <mailto:loa@pi.nu>
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64
<tel:%2B46%20739%2081%2021%2064>


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
 <mailto:loa@m= ail01.huawei.com>
Senior MPLS Expert loa@pi.nu= <mailto:loa@pi.nu>
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64
<tel:%2B46%20739%2081%2021%2064>

_______________________________________________
mpls mailing list
mpls@ietf.org <ma= ilto:mpls@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/mpls


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=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 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--f46d043be25e949f490515054fdf-- From nobody Fri May 1 06:41:08 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3821B31BE for ; Fri, 1 May 2015 06:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tKrinZFTYh6E for ; Fri, 1 May 2015 06:41:05 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 96D951B31BD for ; Fri, 1 May 2015 06:41:04 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id B44D736F83C42; Fri, 1 May 2015 13:40:58 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t41Dex1X014771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 May 2015 09:40:59 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 1 May 2015 09:40:59 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: Loa Andersson , "Andrew G. Malis" Thread-Topic: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 Thread-Index: AdCBzIr6SsqnVpHOQqOMLXhwS/KfnQAogseAAAwv7YAAKVIdvwABTeSgADVYhIAAAwNEUA== Date: Fri, 1 May 2015 13:40:59 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D948351FD@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu> In-Reply-To: <55435C39.5050208@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 13:41:07 -0000 SGkgTG9hLA0KSSBhbSBmaW5lIHdpdGggImNvbmZpZ3VyZWQgbGFiZWxzIiBvciBtYXliZSAibGFi ZWxzIGFzc2lnbmVkIGFuZCByZWNsYWltZWQgYnkgY29uZmlndXJhdGlvbiIuDQoNCkhhdmluZyBz YWlkIHRoYXQsIG9uZSBvZiBteSBjb21tZW50cyBvbiB0aGUgZHJhZnQgd2FzIHRvIGV4cGxhaW4g aG93IHRoZSBsYWJlbHMgd2VyZSBhY3R1YWxseSBtYW5hZ2VkIGFuZCBhc3NpZ25lZC9yZWNsYWlt ZWQgdG8vZnJvbSByb3V0ZXJzIG92ZXIgdGltZS4gRnJvbSB5b3UgZGVzY3JpcHRpb24gYmVsb3cs IGl0IHNlZW1zIHRoZSBOTVMgZmlyc3QgcmVzZXJ2ZXMgYSBjb21tb24gcmFuZ2Ugb2YgbGFiZWxz ICphdmFpbGFibGUgb24gYWxsIHJvdXRlcnMqIGZvciB0aGlzIGFwcGxpY2F0aW9uLiBPbmNlIHJl c2VydmVkLCBubyBvdGhlciBjb250cm9sIHBsYW5lIHByb3RvY29sIG9uIGFueSByb3V0ZXIgY2Fu IHVzZSBhIGxhYmVsIGZyb20gdGhpcyByYW5nZSBldmVuIGlmIHRoZSBsYWJlbCBpcyBhdmFpbGFi bGUuIFRoYXQgd2F5LCB0aGUgTk1TIG1hbmFnZW1lbnQgb2YgdGhlIGxhYmVscyB3aWxsIG5vdCBj bGFzaCB3aXRoIHRoZSBjb250cm9sIHBsYW5lIHByb3RvY29scyBvbiBhbnkgb2YgdGhlIHJvdXRl cnMuDQoNClJlZ2FyZHMsDQpNdXN0YXBoYS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KPiBTZW50OiBGcmlk YXksIE1heSAwMSwgMjAxNSA2OjU4IEFNDQo+IFRvOiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3Rh cGhhKTsgQW5kcmV3IEcuIE1hbGlzDQo+IENjOiBtcGxzQGlldGYub3JnOyBOZXZpbCBCcm93bmxl ZQ0KPiBTdWJqZWN0OiBSZTogW21wbHNdIFJldmlldyBvZiBkcmFmdC1oYW8tbXBscy1pcC1oYXJk LXBpcGUtMDENCj4gDQo+IE11c3RhcGhhIGFuZCBBbmR5LA0KPiANCj4gSWYgd2UgYXJlIHRhbGtp bmcgYWJvdXQgbWFudWFsIGNvbmZpZ3VyZSAobWFudWFsbHkgaW5zdGFsbGVkIGxhYmVscyksIHRo aXMgaXMgbm90IHdoYXQNCj4gaXMgbm90IHdoYXQgaXMgZ29pbmcgb24gaW4gdGhlIGhhcmQtcGlw ZSBuZXR3b3JrLg0KPiANCj4gSXQgaXMgb2YgY291cnNlIHBvc3NpYmxlIHRvIHJ1biBhbnkgTVBM UyBuZXR3b3JrIHdpdGggYWxsIG9yIGEgc3Vic2V0IG9mIHRoZSBsYWJlbHMNCj4gbWFudWFsbHkg aW5zdGFsbGVkLiBXZSBkaWQgdGhhdCBpbiAxOTk5IHdoZW5tIEkgd29ya2VkIHdpdGggYSBTd2Vk aXNoIG9wZXJhdG9yLg0KPiBBd2FpdGluZyB0ZXN0cyBhbmQgZGVjaXNpb24gb24gdGhlIG1peCBv ZiBzaWduYWxsaW5nIHByb3RvY29scyB3ZSBmb3Igc2V2ZXJhbA0KPiBtb250aHMgZGlkIHJ1biBv dXIgbmV0d29yayBieSBpbnN0YWxsaW5nIGFsbCBsYWJlbHMgbWFudWFsbHksIHdlIG5ldmVyIHRo b3VnaHQNCj4gYWJvdXQgdGhhdCBhcyAic3RhdGljIiwgYnV0IEkgY291bGQgbGl2ZSB3aXRoIHRo YXQgdGVybWlub2xvZ3kgaWYgd2Ugd2FudCB0byB1c2UgaXQuDQo+IA0KPiBXaGF0IGlzIGdvaW5n IG9uIGluIHRoZSBoYXJkLXBpcGUgbmV0d29yayBpcyBhIGJpdCBkaWZmZXJlbnQuIFRoZSBOTVMg KGNlbnRyYWxpemVkDQo+IGNvbnRyb2xsZXIpIGlzIGNvbmZpZ3VyZWQgd2l0aCBhIGxhYmVsIHNw YWNlIHBlciBub2RlIHRvIGJlIHVzZWQgZm9yIHRoZSBoYXJkLXBpcGUNCj4gc3RyYXR1bS4gVGhl IE5NUyB0aGVuIGFsbG9jYXRlIGxhYmVscyB0byBiZSBpbnN0YWxsZWQgb24gdGhlIG5vZGVzIGFz IGEgTFNQIGlzDQo+IHJlcXVlc3RlZCBhbmQgcmVtb3ZlIHRoZW0gYW5kIHJldHVybnMgdGhlbSB0 byB0aGUgcG9vbCB3aGVuIHRoZSBMU1AgaXMgdGFrZW4NCj4gZG93bi4NCj4gDQo+IEkgdGVuZCB0 byB0aGluayBhYm91dCB0aGlzIGFzIGR5bmFtaWMgY29uZmlndXJlZCBsYWJlbHMuIER5bmFtaWMg YXMgdGhleSBhcmUNCj4gaW5zdGFsbGVkIGFuZCByZW1vdmVkIGRlcGVuZGluZyBvbiB0aGUgbGlm ZSB0aW1lIG9mIHRoZSBMU1BzLg0KPiBDb25maWd1cmVkIGFzIGl0IGlzIGRvbmUgYnkgdGhlIE5N Uy4NCj4gDQo+IE11c3RhcGhhLA0KPiANCj4gV291bGQgImNvbmZpZ3VyZWQgbGFiZWxzIiBjb3Zl ciB0aGUgY29uY2VybnMgeW91IGhhdmUuDQo+IA0KPiAvTG9hDQo+IA0KPiBPbiAyMDE1LTA0LTMw IDE1OjQyLCBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKSB3cm90ZToNCj4gPiBUaGFua3Mg QW5keSBmb3IgdGhlIHJlZmVyZW5jZS4gSW5kZWVkLCBJIHdhcyByZWZlcnJpbmcgdG8gYXNzaWdu bWVudA0KPiA+IG9mIGluaXRpYWwgbGFiZWwgYW5kIG9mIGFueSBzdWJzZXF1ZW50IGxhYmVsIGNo YW5nZSBvZiBhbiBMU1Agb3IgYSBQVw0KPiA+IGJ5IGNvbmZpZ3VyYXRpb24uIFRoaXMgaXMgc29t ZXRpbWVzIHJlZmVycmVkIHRvIGFzIOKAnG1hbnVhbOKAnQ0KPiA+IGNvbmZpZ3VyYXRpb24gYW5k IHRoZSBMU1Agb3IgUFcgaXMgcmVmZXJyZWQgdG8gYXMgc3RhdGljLg0KPiA+DQo+ID4gVGhhdCBk ZWZpbml0aW9uIGZpdHMgSSBiZWxpZXZlIHdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluDQo+ID4g ZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxIGJ1dCBMb2EgY2FuIGNvbmZpcm0uDQo+ID4N Cj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gTXVzdGFwaGEuDQo+ID4NCj4gPiAqRnJvbToqQW5kcmV3 IEcuIE1hbGlzIFttYWlsdG86YWdtYWxpc0BnbWFpbC5jb21dDQo+ID4gKlNlbnQ6KiBUaHVyc2Rh eSwgQXByaWwgMzAsIDIwMTUgODo1MiBBTQ0KPiA+ICpUbzoqIExvYSBBbmRlcnNzb24NCj4gPiAq Q2M6KiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgbXBsc0BpZXRmLm9yZzsgTmV2aWwg QnJvd25sZWUNCj4gPiAqU3ViamVjdDoqIFJlOiBbbXBsc10gUmV2aWV3IG9mIGRyYWZ0LWhhby1t cGxzLWlwLWhhcmQtcGlwZS0wMQ0KPiA+DQo+ID4gTG9hLA0KPiA+DQo+ID4gSSB0aGluayB0aGUg cmVmZXJlbmNlIHRoYXQgeW91J3JlIGxvb2tpbmcgZm9yIGlzIHNlY3Rpb24gMy4xMSBvZiBSRkMg NTkyMS4NCj4gPg0KPiA+IENoZWVycywNCj4gPg0KPiA+IEFuZHkNCj4gPg0KPiA+IE9uIFRodSwg QXByIDMwLCAyMDE1IGF0IDM6NDEgQU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udQ0KPiA+IDxt YWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQo+ID4NCj4gPiBNdXN0YXBoYSwNCj4gPg0KPiA+IFRo YXQgaXMgc3RpbGwgbm90IGEgZGVmaW5pdGlvbiBwb3NzaWJsZSB0byByZWZyZW5jZS4NCj4gPg0K PiA+IEkndmUgYWx3YXlzIGJlZW4gYSBiaXQgY29uZnVzZWQgYnkgdGhlIGRpc3RpbmN0aW9uIGJl dHdlZW4gInN0YXRpYyINCj4gPiBhbmQgImR5bmFtaWMiLCBlc3BlY2lhbGx5IHdoZW4gaXQgY29t ZXMgdG8gbGFiZWxzLCBhIGJpdCBsZXNzIHNvIGlmIHdlDQo+ID4gdGFsayBhYm91dCBMU1BzLg0K PiA+DQo+ID4gVG8gbWUgdGhlIHRlcm0gICJzdGF0aWMiIGFuZCAiZHluYW1pYyIgc2VlbXMgdG8g aW5kaWNhdGUgaG93IGxvbmcNCj4gPiBsaXZlZCBvciBob3cgZWFzeSB0aGV5IGFyZSB0byBjaGFu Z2UuDQo+ID4NCj4gPiBJZiBhbiBOTVMgb3IgYW55IGNlbnRyYWxpemVkIGNvbnRyb2xsZXIgaW5z dGFsIGFuZCByZW1vdmUgTFNQcy9sYWJlbHMNCj4gPiB3aXRoIHRoZSBzYW1lIGZyZXF1ZW5jeSBh cyBlLmcuIExEUCBhcmUgdGhleSBzdGlsbCAic3RhdGljIj8NCj4gPg0KPiA+IEkgYWdyZWUgdGhh dCB0aGVyZSBpcyBhIHBvc3NpYmxlIGNsYXNzaWZpY2F0aW9uIG9mICJjb25maWd1cmVkDQo+ID4g TFNQcy9sYWJlbHMiIHZzLiAic2lnbmFsZWQgTFNQcy9sYWJlbHMiLg0KPiA+DQo+ID4gSW4gdGhh dCB0ZXJtaW5vbG9neSBJJ2Qgc2F5IHRoYXQgZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlIHVz ZXMNCj4gPiBjb25maWd1cmVkIGxhYmVscy4NCj4gPg0KPiA+IFdvdWxkIHRoYXQgdGVybWlub2xv Z3kgYmUgYWNjZXB0YWJsZSBmb3IgeW91Pw0KPiA+DQo+ID4gL0xvYQ0KPiA+DQo+ID4NCj4gPg0K PiA+IE9uIDIwMTUtMDQtMjkgMTk6MjYsIEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpIHdy b3RlOg0KPiA+DQo+ID4gSGkgTG9hLA0KPiA+IEJ5IHN0YXRpYyBsYWJlbCwgSSBtZWFudCBhIGxh YmVsIHdoaWNoIGlzIGFzc2lnbmVkIHRvIGEgTFNQIG9yIGEgUFcgYnkNCj4gPiBjb25maWd1cmF0 aW9uIGFuZCBub3QgYnkgYSBjb250cm9sIHBsYW5lIHByb3RvY29sLiBJIGJlbGlldmUgdGhpcyBp cw0KPiA+IHdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgYnV0IGxldCBtZSBr bm93IGlmIEkgYW0gd3JvbmcuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IE11c3RhcGhhLg0KPiA+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBMb2EgQW5kZXJzc29u IFttYWlsdG86bG9hQHBpLm51IDxtYWlsdG86bG9hQHBpLm51Pl0NCj4gPiBTZW50OiBXZWRuZXNk YXksIEFwcmlsIDI5LCAyMDE1IDM6MjEgQU0NCj4gPiBUbzogQWlzc2FvdWksIE11c3RhcGhhIChN dXN0YXBoYSk7IG1wbHNAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4g Q2M6IE5ldmlsIEJyb3dubGVlDQo+ID4gU3ViamVjdDogUmU6IFttcGxzXSBSZXZpZXcgb2YgZHJh ZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxDQo+ID4NCj4gPiBNdXN0YXBoYSwNCj4gPg0KPiA+ IGluIGxpbmUgcGxlYXNlLg0KPiA+DQo+ID4gT24gMjAxNS0wNC0yOCAxODowMSwgQWlzc2FvdWks IE11c3RhcGhhIChNdXN0YXBoYSkgd3JvdGU6DQo+ID4NCj4gPiBEZWFyIGFsbCwNCj4gPiBJIHdh cyBhc2tlZCB0byByZXZpZXcgdGhpcyBkcmFmdCB3aGljaCBpcyBpbnRlbmRlZCB0byBiZSBoYW5k bGVkIGluDQo+ID4gdGhlDQo+ID4NCj4gPiBJbmRlcGVuZGVudCBTdHJlYW0uIEJlbG93IGFyZSBt eSBjb21tZW50cyB0byB0aGUgYXV0aG9ycy4NCj4gPg0KPiA+DQo+ID4gTWVtYmVycyBvZiB0aGlz IGxpc3QgY2FuIGFsc28gcHJvdmlkZSBjb21tZW50cyB0byB0aGUgYXV0aG9ycy4gUGxlYXNlDQo+ ID4gY29weSB0aGUNCj4gPg0KPiA+IEluZGVwZW5kZW50IFN1Ym1pc3Npb24gRWRpdG9yaWFsIEJv YXJkIGF0IHRoZSBmb2xsb3dpbmcgYWRkcmVzczoNCj4gPg0KPiA+IHJmYy1pc2VAcmZjLWVkaXRv ci5vcmcgPG1haWx0bzpyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPg0KPiA+DQo+ID4gUmVnYXJkcywN Cj4gPiBNdXN0YXBoYS4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhby1tcGxzLWlwLWhhcmQtcGlwZS0wMQ0K PiA+DQo+ID4gMS4gT3ZlcmFsbCBjb21tZW50Og0KPiA+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IGhvdyBhIGd1YXJhbnRlZWQgYmFuZHdpZHRoIHNlcnZpY2UgY2FuIGJlDQo+ID4gZGVwbG95ZWQN Cj4gPg0KPiA+IGluIGEgTVBMUyBuZXR3b3JrIGJ5IHBhcnRpdGlvbmluZyB0aGUgbmV0d29yayBy ZXNvdXJjZXMgaW50byB0d28NCj4gPiBtYW5hZ2VkIGxheWVycywgcmVmZXJyZWQgdG8gYXMgc3Ry YXRhLiBUaGUgIGd1YXJhbnRlZWQgc2VydmljZSBsYXllcg0KPiA+IGlzIHJlZmVycmVkIHRvIGFz ICJIYXJkIFBpcGUiDQo+ID4gc3RyYXR1bS4NCj4gPg0KPiA+DQo+ID4gVGhlIG1hbmFnZW1lbnQg b2YgdGhlIHJlc291cmNlcyBhbmQgdGhlIHBsYWNlbWVudCBvZiB0aGUgTVBMUyB0dW5uZWxzDQo+ ID4gYW5kDQo+ID4NCj4gPiBzZXJ2aWNlcyBpbnRvIHRoZSAgIkhhcmQgUGlwZSIgc3RyYXR1bSBh cmUgcGVyZm9ybWVkIHdpdGggYSBtYW5hZ2VtZW50DQo+ID4gc3lzdGVtLg0KPiA+IFRodXMgdGhl IHRyYW5zcG9ydCBhbmQgc2VydmljZSBsYWJlbHMgYXJlIHN0YXRpYyBidXQgdGhpcyBpbXBvcnRh bnQNCj4gPiBpbmZvcm1hdGlvbiBoYXMgbm90IGJlZW4gc3RhdGVkIHVwZnJvbnQgaW4gdGhlIGRv Y3VtZW50Lg0KPiA+DQo+ID4gRG8geW91IGhhdmUgYSBhIGRlZmluaXRpb24gb2YgInN0YXRpYyBs YWJlbHMiIHRoYXQgd2UgY2FuIHJlZmVyIHRvPw0KPiA+DQo+ID4gL0xvYQ0KPiA+IE9ubHkgaW4g c2VjdGlvbiA2IHRoYXQgTVBMUy1UUCB3YXMgbWVudGlvbmVkLiBGdXJ0aGVybW9yZSwgdGhlDQo+ ID4gcmVmZXJlbmNlIHRvIFQtIExEUCBzaWduYWxlZCBsYWJlbHMgaW4gU2VjdGlvbiAzIGFkZHMg dG8gdGhlDQo+ID4gY29uZnVzaW9uLg0KPiA+DQo+ID4gICAgIEkgcHJvcG9zZSB0aGF0IHRoZSBJ bnRyb2R1Y3Rpb24gYW5kIFNjb3BlIHNlY3Rpb25zIGJlIGV4cGxpY2l0DQo+ID4gYWJvdXQgdGhl DQo+ID4NCj4gPiBmcmFtZXdvcmsgdXNlZCB0byBhY2hpZXZlIHRoZSAiSGFyZCBQaXBlIiBzdHJh dHVtLCB0aGF0IGlzIGJ5IG1lYW5zIG9mDQo+ID4gYSBtYW5hZ2VtZW50IHN5c3RlbSBhbmQgc3Rh dGljIHRyYW5zcG9ydCBhbmQgc2VydmljZSBsYWJlbHMuDQo+ID4NCj4gPg0KPiA+IEluIGZhY3Qs IEkgd291bGQgdGhpbmsgdGhlIGRvY3VtZW50IHZhbHVlIHdvdWxkIGJlIGluIGRlc2NyaWJpbmcg bW9yZQ0KPiA+IGRldGFpbHMgb2YNCj4gPg0KPiA+IHRoZSBmcmFtZXdvcmsgaW5jbHVkaW5nIGNv bmZpZ3VyYXRpb24gYXNwZWN0cywgcmVzb3VyY2UgYW5kIHNlcnZpY2UNCj4gPiBtYW5hZ2VtZW50 IGluY2x1ZGluZyByZXNpbGllbmNlLiBUaGVzZSBhc3BlY3RzIGhhdmUgbm90IGJlZW4NCj4gPiBz dWZmaWNpZW50bHkgYWRkcmVzc2VkIGFuZCB0aGUgZm9jdXMgd2FzIG1vcmUgb24gaG93IHRvIHVz ZSBNUExTDQo+ID4gbGFiZWxzIHRvIGRpZmZlcmVudGlhdGUgdGhlIHR3byBzdHJhdGEuDQo+ID4N Cj4gPg0KPiA+IDIuIFNlY3Rpb24gMS4xIC0gU2NvcGU6DQo+ID4gQXMgcGFydCBvZiB0aGUgc2Vj b25kIGJ1bGxldCwgSSBjYW5ub3QgZmluZCBpbiB0aGUgZG9jdW1lbnQgaG93IGENCj4gPiByb3V0 ZXIgcHJvdGVjdHMNCj4gPg0KPiA+IHRoZSB0cmFmZmljIG9mIHRoZSAiSGFyZCBQaXBlIiBzdHJh dHVtIGlmIHRoZSAiTm9ybWFsIElQL01QTFMiIHN0cmF0dW0NCj4gPiBvdmVyYm9va3MgYSBsaW5r LiBIYXZpbmcgYSBzZXBhcmF0ZSBsYWJlbCBmb3IgdGhlIGd1YXJhbnRlZWQgc2VydmljZQ0KPiA+ IGlzIG5vdCBzdWZmaWNpZW50LiBUaGUgYXV0aG9ycyBzaG91bGQgZGVzY3JpYmUgaWYgTFNQIHBy ZS1lbXB0aW9uDQo+ID4gYW5kL29yIFFvUyBtYXJraW5ncyBhcmUgdXNlZCB0byBkaWZmZXJlbnRp YXRlIHRoZSB0cmVhdG1lbnQgYWNyb3NzIHRoZQ0KPiA+IHN0cmF0YS4NCj4gPg0KPiA+DQo+ID4g My4gU2VjdGlvbiAzOg0KPiA+IElmIHRoZSBkb2N1bWVudCBvYmplY3RpdmUgaXMgdG8gZGVzY3Jp YmUgdGhlIGZyYW1ld29yayB1c2VkLCB0aGVuIHRoaXMNCj4gPiBzZWN0aW9uDQo+ID4NCj4gPiBz aG91bGQgYmVnaW4gYnkgZXhwbGFpbmluZyB0aGUgaW5pdGlhbCBjb25maWd1cmF0aW9uIHBlcmZv cm1lZCBieSB0aGUNCj4gPiBOTVMgdG8gbGF5IHRoZSBncm91bmQgZm9yIHRoZSBidWlsZGluZyBv ZiB0aGUgdHdvIHN0cmF0dW1zLiBUaGlzDQo+ID4gaW5jbHVkZXMgdGhlIHBhcnRpdGlvbmluZyBv ZiB0aGUgbGlua3MsIHRoZSBhc3NpZ25tZW50IG9mIHRyYW5zcG9ydA0KPiA+IGFuZCBzZXJ2aWNl IGxhYmVsIHJhbmdlcyBpbiB0aGUgcm91dGVycywgdGhlIG92ZXJib29raW5nIHN0cmF0ZWd5LA0K PiA+IGV0Yy4NCj4gPg0KPiA+DQo+ID4gVGhlbiwgeW91IGNhbiBkaXNjdXNzIGhvdyBhIGd1YXJh bnRlZWQgc2VydmljZSBpcyBjb25maWd1cmVkIGluIHRoZQ0KPiA+IG5ldHdvcmsNCj4gPg0KPiA+ IHVzaW5nIHN0YXRpYyB0cmFuc3BvcnQgbGFiZWxzIGFuZCBzdGF0aWMgc2VydmljZSBsYWJlbHMu IFRoaXMgc2hvdWxkDQo+ID4gY292ZXIgdGhlIHBsYWNlbWVudCBvZiB0aGUgd29ya2luZyBhbmQg YmFja3VwIHBhdGhzIHNpbmNlIFNlY3Rpb24gNg0KPiA+IG1lbnRpb25zIE1QTFMtVFAgcHJvdGVj dGlvbiBpcyB1c2VkLg0KPiA+DQo+ID4NCj4gPiBOZXh0LCBhIGRlc2NyaXB0aW9uIG9mIGhvdyB0 aGUgdHJhbnNwb3J0IExTUCBhbmQgc2VydmljZSBhcmUgbW9uaXRvcmVkDQo+ID4gZm9yDQo+ID4N Cj4gPiBjb250aW51aXR5IGFuZCBkZWZlY3RzLg0KPiA+DQo+ID4NCj4gPiBGaW5hbGx5LCB0aGUg YmVoYXZpb3Igd2hlbiByZXNvdXJjZXMgYXJlIG92ZXJib29rZWQgYW5kIHdoYXQgc2VydmljZXMN Cj4gPiBhcmUgcHJlLQ0KPiA+DQo+ID4gZW1wdGVkIG9yIGRlZ3JhZGVkIHNob3VsZCBiZSBkZXNj cmliZWQuDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRm Lm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4g Pg0KPiA+DQo+ID4gLS0NCj4gPg0KPiA+DQo+ID4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAg ICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gPiA8bWFpbHRvOmxvYUBt YWlsMDEuaHVhd2VpLmNvbT4NCj4gPiBTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51IDxtYWls dG86bG9hQHBpLm51Pg0KPiA+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBw aG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiA+IDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIw NjQ+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4NCj4gPg0KPiA+IExvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ID4gPG1haWx0 bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQo+ID4gU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5u dSA8bWFpbHRvOmxvYUBwaS5udT4NCj4gPiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50 KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCj4gPiA8dGVsOiUyQjQ2JTIwNzM5JTIwODEl MjAyMSUyMDY0Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcgPG1h aWx0bzptcGxzQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+DQo+IA0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+IFNlbmlvciBN UExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+IEh1YXdlaSBU ZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K From nobody Fri May 1 21:02:22 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E486D1A0395; Fri, 1 May 2015 21:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 rrX6Yv7vyjvE; Fri, 1 May 2015 21:02:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C385D1A037E; Fri, 1 May 2015 21:02:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150502040218.15841.54396.idtracker@ietfa.amsl.com> Date: Fri, 01 May 2015 21:02:18 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 04:02:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification Authors : Nobo Akiya George Swallow Carlos Pignataro Loa Andersson Mach(Guoyi) Chen Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-03.txt Pages : 13 Date : 2015-05-01 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the "Reply via Specified Path (5)" Reply Mode value to easily indicate the reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC7110. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode-simple/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-reply-mode-simple-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 1 21:03:09 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE411A0390 for ; Fri, 1 May 2015 21:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=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 hemuTBhNZdWt for ; Fri, 1 May 2015 21:03:01 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5C71A037E for ; Fri, 1 May 2015 21:03:00 -0700 (PDT) Received: by labbd9 with SMTP id bd9so74592318lab.2 for ; Fri, 01 May 2015 21:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NNdJQHxlwwcbMDGZlLuSu0MJa4M/HG/xqjju3UIYcdQ=; b=AF710zeK8akHdct9ArIdflxBbh1qfFd8uqvb9cmU3bcRIM/78esXolRyXSG6PMsSVX LkbofnrLIjeLRnGff/9/JsF+IxIrcAzHFZ4OF1JG4Q6fOCS5dHk1SIz4HQpmG5XJ5x/s Vkhi2njxEAsnKOP8wkBBgF+M6sVjigsza3oQAynG3OQanGoD/Ft5+6CWxNs9hYQ+M39V 2tFcDygKJH08wBsb8Q+PNnXwY9xHXUgG4QfYDeeFTas4aToqpDaAEG+0br2aYKhNKriU mu5Y5a+ZdFl/gLRRbK5SwBx/43TPpPWHQeL6QNz8/cGz4AjLDQu/w6KY4EBzfQCPMP6G G6ZQ== MIME-Version: 1.0 X-Received: by 10.152.44.167 with SMTP id f7mr2430611lam.48.1430539378937; Fri, 01 May 2015 21:02:58 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Fri, 1 May 2015 21:02:58 -0700 (PDT) In-Reply-To: <048c01d081dc$82451ca0$4001a8c0@gateway.2wire.net> References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> <553F8193.8040506@pi.nu> <011c01d081bb$843f9010$8cbeb030$@olddog.co.uk> <048c01d081dc$82451ca0$4001a8c0@gateway.2wire.net> Date: Fri, 1 May 2015 21:02:58 -0700 Message-ID: From: Nobo Akiya To: "t.petch" Content-Type: multipart/alternative; boundary=089e0158c40e84d4f905151167b4 Archived-At: Cc: mpls , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 04:03:07 -0000 --089e0158c40e84d4f905151167b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, Tom, Loa, Thanks again! New revision (-03) has been posted. -Nobo On Tue, Apr 28, 2015 at 10:55 AM, t.petch wrote: > Me too > > Tom Petch > > > ----- Original Message ----- > From: "Adrian Farrel" > To: "'Loa Andersson'" ; "'Nobo Akiya'" > > Cc: "'t.petch'" ; "'Ross Callon'" > ; "'mpls'" ; > ; > > Sent: Tuesday, April 28, 2015 2:59 PM > > > I'm OK with what Nobo said. > > A > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: 28 April 2015 13:48 > > To: Nobo Akiya; adrian@olddog.co.uk > > Cc: t.petch; Ross Callon; mpls; mpls-chairs@tools.ietf.org; > draft-ietf-mpls-lsp- > > ping-reply-mode-simple@tools.ietf.org > > Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: > working > > group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > Nobo, > > > > I think this is fine. > > > > Bullet 4 says what to do if the Reply Mode Order TLV is mal-formed. > > > > Bullet 6-9 describe the mal-formednesses. > > > > Is it "invalid" rather than "not valid"? > > > > Tom and Adrian are you OK with this? > > > > /Loa > > > > On 2015-04-27 03:36, Nobo Akiya wrote: > > > Hi Adrian, > > > > > > Many thanks for very helpful comments. I have carefully read your > > > comments and made modifications to section 3.2 in my private copy. > > > > > > [OLD] > > > > > > 1. The Reply Mode Order TLV MAY be included in MPLS echo > request. > > > > > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo > reply. > > > > > > 3. The Reply Mode field of an MPLS echo request MUST be set to > a > > > valid value even when supplying the Reply Mode Order TLV. > The > > > initiator LSR SHOULD set the Reply Mode field of MPLS echo > > > request to a value that corresponds to a return path which > most > > > likely to be available, in case the responder LSR does not > > > understand the Reply Mode Order TLV. > > > > > > 4. If a responder LSR understands the Reply Mode Order TLV but > the > > > TLV is not valid (due to conditions described in the items > 6, 8 > > > and 9 immediately below), then the responder LSR MUST only > use > > > the value described in the Reply Mode field of received MPLS > echo > > > request. > > > > > > 5. If a responder LSR understands the Reply Mode Order TLV and > the > > > TLV is valid, then the responder LSR MUST consider the Reply > Mode > > > values described in the TLV and MUST NOT use the value > described > > > in the Reply Mode field of received MPLS echo request. In > other > > > words, a valid Reply Mode Order TLV overrides the value > specified > > > in the Reply Mode field of received MPLS echo request. > > > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode > value, > > > and SHOULD contain at least two Reply Mode values. > > > > > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > > > multiple times) in the Reply Mode Order TLV. > > > > > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be > included > > > more than once in the Reply Mode Order TLV. However, in > such > > > case a Reply Path TLV MUST be included for all instances of > the > > > Reply Mode value 5 included in the Reply Mode Order TLV. In > > > other words, 3 instances of the Reply Mode value 5 in the > Reply > > > Mode Order TLV will require 3 instances of the Reply Path > TLVs. > > > > > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in > the > > > Reply Mode Order TLV. > > > > > > If a responder LSR receives a Reply Mode Order TLV which does > not > > > comply to the rules described above, then the responder LSR MUST > > > ignore the Reply Mode Order TLV. > > > > > > > > > [NEW] > > > > > > 1. The Reply Mode Order TLV MUST NOT be included in MPLS echo > reply. > > > If the initiator LSR receives an MPLS echo reply with the > Reply > > > Mode Order TLV, the initiator LSR MUST ignore the whole > Reply > > > Mode Order TLV and MUST only use the value from the Reply > Mode > > > field of the received MPLS echo reply. It may be beneficial > for > > > implementations to provide counters and/or loggings, with > > > appropriate log dampening, to record this error case. > > > > > > 2. The Reply Mode Order TLV MAY be included in MPLS echo > request. > > > > > > 3. The Reply Mode field of an MPLS echo request MUST be set to > a > > > valid value even when supplying the Reply Mode Order TLV. > The > > > initiator LSR SHOULD set the Reply Mode field of MPLS echo > > > request to a value that corresponds to a return path which > most > > > likely to be available, in case the responder LSR does not > > > understand the Reply Mode Order TLV. > > > > > > 4. If a responder LSR understands the Reply Mode Order TLV but > the > > > TLV is not valid (due to conditions described in the items > 6, 7, > > > 8 and 9 immediately below), then the responder LSR MUST > ignore > > > the whole Reply Mode Order TLV and MUST only use the value > from > > > the Reply Mode field of the received MPLS echo request. It > may > > > be beneficial for implementations to provide counters and/or > > > loggings, with appropriate log dampening, to record this > error > > > case. > > > > > > 5. If a responder LSR understands the Reply Mode Order TLV and > the > > > TLV is valid, then the responder LSR MUST consider the Reply > Mode > > > values described in the TLV and MUST NOT use the value > described > > > in the Reply Mode field of received MPLS echo request. In > other > > > words, a valid Reply Mode Order TLV overrides the value > specified > > > in the Reply Mode field of received MPLS echo request. > > > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode > value. > > > > > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > > > multiple times) in the Reply Mode Order TLV. > > > > > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be > included > > > more than once in the Reply Mode Order TLV. However, in > such > > > case a Reply Path TLV MUST be included for all instances of > the > > > Reply Mode value 5 included in the Reply Mode Order TLV. In > > > other words, 3 instances of the Reply Mode value 5 in the > Reply > > > Mode Order TLV will require 3 instances of the Reply Path > TLVs. > > > > > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in > the > > > Reply Mode Order TLV. > > > > > > > > > Thanks! > > > > > > -Nobo > > > > > > > > > On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel > > > wrote: > > > > > > Hi Nobo,____ > > > > > > __ __ > > > > > > Let's come back to my original review comments.____ > > > > > > __ __ > > > > > > > Section 3.2 gives clear instructions and guidance on forming > the Reply____ > > > > > > > Mode Order TLV but not on what to do if a received TLV > deviates from > > the____ > > > > > > > MUST and MUST NOT instructions. Options might include ignoring > > errors,____ > > > > > > > ignoring the TLV, ignoring the message. But presumably not > sending > > an____ > > > > > > > error response (because how would you know how to send > it?)____ > > > > > > __ __ > > > > > > You responded:____ > > > > > > __ __ > > > > > > | [NOBO] That=E2=80=99s a good point. What the document really st= ate is > that > > > The____ > > > > > > | Reply Mode value 5 (Reply via Specified Path) MAY be repeated > but > > > all ____ > > > > > > | other Reply Mode values MUST NOT be repeated. Will update > the____ > > > > > > | document to make it clear.____ > > > > > > __ __ > > > > > > That's a fine thing to say, but doesn't answer my question about > how > > > an implementation is supposed to behave when a received Reply > Mode > > > Order TLV is "malformed".____ > > > > > > __ __ > > > > > > You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02. > Section > > > 3.2 swapped the order of points 4 and 5, and enhanced the text > to > > > read...____ > > > > > > __ __ > > > > > > 4.If a responder LSR understands the Reply Mode Order TLV but > the____ > > > > > > TLV is not valid (due to conditions described in the items 6, > 8____ > > > > > > and 9 immediately below), then the responder LSR MUST only > use____ > > > > > > the value described in the Reply Mode field of received MPLS > echo____ > > > > > > request.____ > > > > > > __ __ > > > > > > That seems to cover most bases. Good.____ > > > > > > It might also be helpful to say "...the responder LSR MUST > silently > > > ignore the whole Reply Mode Order TLV and MUST only use the > value > > > from the Reply Mode field of the received MPLS echo > request."____ > > > > > > Saying this helps clarify the behavior.____ > > > > > > __ __ > > > > > > The only things I don't find covered are:____ > > > > > > __ __ > > > > > > a. how to handle a violation of the seventh point____ > > > > > > __ __ > > > > > > 7.A Reply Mode value, except for Reply Mode value 5 (Reply > via____ > > > > > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear____ > > > > > > multiple times) in the Reply Mode Order TLV.____ > > > > > > __ __ > > > > > > I think you can address this by adding "7" to the list of > conditions > > > in point 4.____ > > > > > > __ __ > > > > > > b. how to handle a violation of the second point____ > > > > > > __ __ > > > > > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo > > reply.____ > > > > > > __ __ > > > > > > I think this will need additional text.____ > > > > > > __ __ > > > > > > I note that after the numbered bullets you also now have the > > > following text...____ > > > > > > __ __ > > > > > > If a responder LSR receives a Reply Mode Order TLV which does > not____ > > > > > > comply to the rules described above, then the responder LSR > MUST____ > > > > > > ignore the Reply Mode Order TLV.____ > > > > > > __ __ > > > > > > This is better than point 4 and covers everything.____ > > > > > > You might consider whether "ignore" means "silently ignore" or > > > whether you want to give advice about logging. It seems probable > > > that (because of the nature of ping) if you do suggest logging, > you > > > also want to describe some form of thresholding or damping.____ > > > > > > __ __ > > > > > > __ __ > > > > > > To address Loa's concern...____ > > > > > > The TLV is from the optional range. It can be ignored if it is > not > > > understood, and does not require to be included.____ > > > > > > Loa asserted that the document says that the TLV MUST be > included, > > > but I don't find this in -02.____ > > > > > > Therefore, I think this is all fine.____ > > > > > > __ __ > > > > > > Adrian____ > > > > > > __ __ > > > > > > *From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com > > > ] > > > *Sent:* 25 April 2015 05:50 > > > *To:* adrian@olddog.co.uk > > > *Cc:* Loa Andersson; t.petch; Ross Callon; mpls; > > > mpls-chairs@tools.ietf.org ; > > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > > > > > > > *Subject:* Re: [mpls] George can yu look at this - Re: end of > WGLC, > > > RE: working group last call for > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01____ > > > > > > __ __ > > > > > > Hi Adrian, Tom, Loa,____ > > > > > > __ __ > > > > > > This extension is currently structured such that it allows for > > > backwards compatibility (i.e., transit LSR not supporting this > > > mechanism will not return "malformed request" ... because the > TLV is > > > optional).____ > > > > > > __ __ > > > > > > The result is that this mechanism becomes a best effort > mechanism, > > > and we will not get the full benefit until all LSRs along the > LSP > > > (and other LSRs which could falsely receive the echo request) > > > implements this extension.____ > > > > > > __ __ > > > > > > One way to allow the initiator LSR to determine whether or not > the > > > responder LSR understood this TLV, and still keeping the > backwards > > > compatibility, is that we keep the Reply Mode Order TLV as an > > > optional TLV, but require (i.e., MUST) the responder LSR > > > understanding this TLV to include the Reply Mode Order TLV in > the > > > echo reply, potentially with result of parsing/handling that > TLV.____ > > > > > > __ __ > > > > > > However, that's probably not the path we want to go, as all (or > > > most) optional TLVs will have to do something similar (i.e., > include > > > the same TLV in the echo reply). This will quickly result in > echo > > > reply packet bloat ... we should prevent that as echo reply > usually > > > tends to include more information (ILS, DSMAP/DDMAP per nexthop, > > > multipath Sub-TLVs per nexthop, etc).____ > > > > > > __ __ > > > > > > To me, the right way to solve this is to create a capability TLV > > > that mandates the reponder LSR to return which features it > supports > > > in bitmaps or something very compact. But this can be done in a > > > separate effort/draft.____ > > > > > > __ __ > > > > > > In short, my preference for this document is to go as is (after > > > incorporating comments from Tom).____ > > > > > > __ __ > > > > > > Thanks!____ > > > > > > __ __ > > > > > > -Nobo____ > > > > > > __ __ > > > > > > On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel > > > > wrote:____ > > > > > > Thanks Loa, > > > > > > You captured it. The edge cases need to be nailed down. > > > > > > Personally I have no particular preference for where it is > nailed, > > > but I don't > > > want it flapping in the breeze. > > > > > > A > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org > > > ] On Behalf Of Loa Andersson > > > > Sent: 23 April 2015 13:59 > > > > To: t.petch; Nobo Akiya > > > > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org > > > ; > > > draft-ietf-mpls-lsp-ping-reply- > > > > mode-simple@tools.ietf.org > > > > > Subject: [mpls] George can yu look at this - Re: end of WGLC, > RE: > > > working > > > group > > > > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > > > Tom, > > > > > > > > The question you and Adrian asks is what to do if the Reply > Mode > > > > Order TLV is missing. > > > > > > > > There is something fishy here, I'd like George to look at > this. > > > > > > > > The LSP Ping design says that TLVs from this range may be > silentsly > > > > dropped, my take is that we don't need to specify anything > more > > > > than that. > > > > > > > > Now, we say that it MUST be present, and after thinking > around a bit > > > > I wonder if the TLV should be assigned from the mandatory > range > > > instead? > > > > > > > > Or if the MUST be present means that the message will be > malformed if > > > > it is not there, and the message should be discarded. > > > > > > > > OK - now I'm confused. > > > > > > > > /Loa > > > > > > > > On 2015-04-23 13:02, t.petch wrote: > > > > > ---- Original Message ----- > > > > > From: "Loa Andersson" > > > > > > Sent: Wednesday, April 22, 2015 2:15 PM > > > > > > > > > >> Tom, > > > > >> > > > > >> On 2015-04-20 00:07, Nobo Akiya wrote: > > > > >>> > > > > >>> > > > > >>> Yes but ... I think that it is a change of meaning. > Is is > > > > > enough just > > > > >>> to ignore the TLV or should the whole PDU be > discarded? > > > I find > > > > > it > > > > >>> difficult to know but don't feel strongly about that > > > choice so > > > > > will go > > > > >>> with what you suggest. > > > > >>> > > > > >>> > > > > >> > > > > >> So I don't misunderstand what you are saying. It seems to > me > > > like the > > > > >> comments made by Adrian and you actually requires a > "change of > > > > > meaning", > > > > >> that is kind of essence of a "comment", right? > > > > >> > > > > >> As for what to do with if the TLV is not recognized, it is > > > > >> intentionally requested from a space where it can be > silently > > > dropped > > > > >> (i.e. "ignored"). > > > > >> > > > > >> The new TLV Type value should be assigned from the > range > > > > >> (32768-49161) specified in [RFC4379] section 3 that > > > allows the TLV > > > > >> type to be silently dropped if not recognized. > > > > >> > > > > >> Type Meaning Reference > > > > >> ---- ------- --------- > > > > >> TBD1 Reply Mode Order TLV this > document > > > > >> > > > > >> What is it that I miss? > > > > > > > > > > Nothing serious. My initial thought was to echo Adrian, > that, > > > at least > > > > > in this context, there should be an indication what to do > if a > > > MUST or > > > > > SHOULD was violated without just then having a clear sense > of > > > what it > > > > > should be instead. > > > > > > > > > > The I-D did require (MUST) one entry in the TLV and wanted > (SHOULD) > > > > > more. Adding what to do if that did not happen I was > seeing as > > > > > clarification. I then read Nobo as proposing going a bit > > > further saying > > > > > requires (MUST) one or more. Which might lead to boxes > taking a > > > > > simplistic approach and always putting in the new TLV with > a single > > > > > entry and ignoring the traditional TLV. Not a problem just > a > > > change > > > > > from what others might think that they have consented to. > > > > > > > > > > On the question of what to do when the rules are violated, > > > again I did > > > > > not initially think of what the action should be. On > > > reflection, I am > > > > > still unsure. I understand that the Reply Mode Order TLV > is > > > optional > > > > > and so can be ignored when not understood; that's fine. > But if > > > it is > > > > > understood and can be seen to be defective, should the box > with > > > that > > > > > knowledge discard just that TLV and accept the remainder of > the > > > message? > > > > > Or should it argue that if this TLV is defective, then > likely > > > the rest > > > > > is as well and should be ignored? I am unsure. > > > > > > > > > > If there is scope for a breach of security, or taking a hit > in > > > > > performance, then ignore is the right policy. If the > > > requirement is to > > > > > get as much data as possible from a failing network, then > use > > > it is the > > > > > right policy. As long as the I-D is clear, I am not too > fussed > > > which > > > > > way it goes. I am content with the changes that Nobo has > proposed. > > > > > > > > > > Tom Petch > > > > > > > > > >> /Loa > > > > >> > > > > >> -- > > > > >> > > > > >> > > > > >> Loa Andersson email: > > > loa@mail01.huawei.com > > > > >> Senior MPLS Expert loa@pi.nu > > > > >> Huawei Technologies (consultant) phone: +46 739 81 21 > 64 > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Loa Andersson > email:loa@mail01.huawei.com > > > > > > Senior MPLS Expertloa@pi.nu > > > > Huawei Technologies (consultant) phone:+46 739 81 21 64 > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > >mpls@ietf.org > > > >https://www.ietf.org/mailman/listinfo/mpls____ > > > > > > __ __ > > > > > > > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > --089e0158c40e84d4f905151167b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian, Tom, Loa,

Thanks again!

New revision (-03) has been posted.

-Nobo

On Tue, Apr 28, 2015 at 10:55 AM, t.petch <ietfc@btconnect.com> wrote:
Me too

Tom Petch


----- Original Message -----
From: "Adrian Farrel" <= adrian@olddog.co.uk>
To: "'Loa Andersson'" <lo= a@pi.nu>; "'Nobo Akiya'"
<nobo.akiya.dev@gmail.com>
Cc: "'t.petch'" <ietfc@btconnect.com>; "'Ross Callon'"
<rcallon@juniper.net>; &qu= ot;'mpls'" <mpls@ietf.org<= /a>>;
<mpls-chairs@tools.ietf.or= g>;
<draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org>
Sent: Tuesday, April 28, 2015 2:59 PM


I'm OK with what Nobo said.

A

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu= ]
> Sent: 28 April 2015 13:48
> To: Nobo Akiya; adrian@olddog.c= o.uk
> Cc: t.petch; Ross Callon; mpls; mpls-chairs@tools.ietf.org;
draft-ietf-mpls-lsp-
> ping-reply-mo= de-simple@tools.ietf.org
> Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE:<= br> working
> group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01
>
> Nobo,
>
> I think this is fine.
>
> Bullet 4 says what to do if the Reply Mode Order TLV is mal-formed. >
> Bullet 6-9 describe the mal-formednesses.
>
> Is it "invalid" rather than "not valid"?
>
> Tom and Adrian are you OK with this?
>
> /Loa
>
> On 2015-04-27 03:36, Nobo Akiya wrote:
> > Hi Adrian,
> >
> > Many thanks for very helpful comments. I have carefully read your=
> > comments and made modifications to section 3.2 in my private copy= .
> >
> > [OLD]
> >
> >=C2=A0 =C2=A0 =C2=A01.=C2=A0 The Reply Mode Order TLV MAY be inclu= ded in MPLS echo
request.
> >
> >=C2=A0 =C2=A0 =C2=A02.=C2=A0 The Reply Mode Order TLV MUST NOT be = included in MPLS echo
reply.
> >
> >=C2=A0 =C2=A0 =C2=A03.=C2=A0 The Reply Mode field of an MPLS echo = request MUST be set to
a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0valid value even when supplying = the Reply Mode Order TLV.
The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initiator LSR SHOULD set the Rep= ly Mode field of MPLS echo
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0request to a value that correspo= nds to a return path which
most
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likely to be available, in case = the responder LSR does not
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0understand the Reply Mode Order = TLV.
> >
> >=C2=A0 =C2=A0 =C2=A04.=C2=A0 If a responder LSR understands the Re= ply Mode Order TLV but
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLV is not valid (due to conditi= ons described in the items
6, 8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and 9 immediately below), then t= he responder LSR MUST only
use
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the value described in the Reply= Mode field of received MPLS
echo
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0request.
> >
> >=C2=A0 =C2=A0 =C2=A05.=C2=A0 If a responder LSR understands the Re= ply Mode Order TLV and
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLV is valid, then the responder= LSR MUST consider the Reply
Mode
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0values described in the TLV and = MUST NOT use the value
described
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the Reply Mode field of recei= ved MPLS echo request.=C2=A0 In
other
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0words, a valid Reply Mode Order = TLV overrides the value
specified
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the Reply Mode field of recei= ved MPLS echo request.
> >
> >=C2=A0 =C2=A0 =C2=A06.=C2=A0 Reply Mode Order TLV MUST contain at = least one Reply Mode
value,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and SHOULD contain at least two = Reply Mode values.
> >
> >=C2=A0 =C2=A0 =C2=A07.=C2=A0 A Reply Mode value, except for Reply = Mode value 5 (Reply via
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Specified Path), MUST NOT be rep= eated (i.e., MUST NOT appear
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple times) in the Reply Mod= e Order TLV.
> >
> >=C2=A0 =C2=A0 =C2=A08.=C2=A0 The Reply Mode value 5 (Reply via Spe= cified Path) MAY be
included
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more than once in the Reply Mode= Order TLV.=C2=A0 However, in
such
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case a Reply Path TLV MUST be in= cluded for all instances of
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reply Mode value 5 included in t= he Reply Mode Order TLV.=C2=A0 In
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other words, 3 instances of the = Reply Mode value 5 in the
Reply
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mode Order TLV will require 3 in= stances of the Reply Path
TLVs.
> >
> >=C2=A0 =C2=A0 =C2=A09.=C2=A0 The Reply Mode value 1 (Do not reply)= MUST NOT be used in
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reply Mode Order TLV.
> >
> >=C2=A0 =C2=A0 =C2=A0If a responder LSR receives a Reply Mode Order= TLV which does
not
> >=C2=A0 =C2=A0 =C2=A0comply to the rules described above, then the = responder LSR MUST
> >=C2=A0 =C2=A0 =C2=A0ignore the Reply Mode Order TLV.
> >
> >
> > [NEW]
> >
> >=C2=A0 =C2=A0 =C2=A01.=C2=A0 The Reply Mode Order TLV MUST NOT be = included in MPLS echo
reply.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the initiator LSR receives an= MPLS echo reply with the
Reply
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mode Order TLV, the initiator LS= R MUST ignore the whole
Reply
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mode Order TLV and MUST only use= the value from the Reply
Mode
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0field of the received MPLS echo = reply.=C2=A0 It may be beneficial
for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementations to provide count= ers and/or loggings, with
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0appropriate log dampening, to re= cord this error case.
> >
> >=C2=A0 =C2=A0 =C2=A02.=C2=A0 The Reply Mode Order TLV MAY be inclu= ded in MPLS echo
request.
> >
> >=C2=A0 =C2=A0 =C2=A03.=C2=A0 The Reply Mode field of an MPLS echo = request MUST be set to
a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0valid value even when supplying = the Reply Mode Order TLV.
The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initiator LSR SHOULD set the Rep= ly Mode field of MPLS echo
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0request to a value that correspo= nds to a return path which
most
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likely to be available, in case = the responder LSR does not
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0understand the Reply Mode Order = TLV.
> >
> >=C2=A0 =C2=A0 =C2=A04.=C2=A0 If a responder LSR understands the Re= ply Mode Order TLV but
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLV is not valid (due to conditi= ons described in the items
6, 7,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08 and 9 immediately below), then= the responder LSR MUST
ignore
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the whole Reply Mode Order TLV a= nd MUST only use the value
from
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the Reply Mode field of the rece= ived MPLS echo request.=C2=A0 It
may
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be beneficial for implementation= s to provide counters and/or
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggings, with appropriate log d= ampening, to record this
error
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case.
> >
> >=C2=A0 =C2=A0 =C2=A05.=C2=A0 If a responder LSR understands the Re= ply Mode Order TLV and
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLV is valid, then the responder= LSR MUST consider the Reply
Mode
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0values described in the TLV and = MUST NOT use the value
described
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the Reply Mode field of recei= ved MPLS echo request.=C2=A0 In
other
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0words, a valid Reply Mode Order = TLV overrides the value
specified
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the Reply Mode field of recei= ved MPLS echo request.
> >
> >=C2=A0 =C2=A0 =C2=A06.=C2=A0 Reply Mode Order TLV MUST contain at = least one Reply Mode
value.
> >
> >=C2=A0 =C2=A0 =C2=A07.=C2=A0 A Reply Mode value, except for Reply = Mode value 5 (Reply via
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Specified Path), MUST NOT be rep= eated (i.e., MUST NOT appear
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple times) in the Reply Mod= e Order TLV.
> >
> >=C2=A0 =C2=A0 =C2=A08.=C2=A0 The Reply Mode value 5 (Reply via Spe= cified Path) MAY be
included
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more than once in the Reply Mode= Order TLV.=C2=A0 However, in
such
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case a Reply Path TLV MUST be in= cluded for all instances of
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reply Mode value 5 included in t= he Reply Mode Order TLV.=C2=A0 In
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other words, 3 instances of the = Reply Mode value 5 in the
Reply
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mode Order TLV will require 3 in= stances of the Reply Path
TLVs.
> >
> >=C2=A0 =C2=A0 =C2=A09.=C2=A0 The Reply Mode value 1 (Do not reply)= MUST NOT be used in
the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reply Mode Order TLV.
> >
> >
> > Thanks!
> >
> > -Nobo
> >
> >
> > On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel <adrian@olddog.co.uk
> > <mailto:adrian@olddog.c= o.uk>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0Hi Nobo,____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0Let's come back to my original review comm= ents.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0> Section 3.2 gives clear instructions and = guidance on forming
the Reply____
> >
> >=C2=A0 =C2=A0 =C2=A0> Mode Order TLV but not on what to do if a= received TLV
deviates from
> the____
> >
> >=C2=A0 =C2=A0 =C2=A0> MUST and MUST NOT instructions. Options m= ight include ignoring
> errors,____
> >
> >=C2=A0 =C2=A0 =C2=A0> ignoring the TLV, ignoring the message. B= ut presumably not
sending
> an____
> >
> >=C2=A0 =C2=A0 =C2=A0> error response (because how would you kno= w how to send
it?)____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0You responded:____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0| [NOBO] That=E2=80=99s a good point. What the= document really state is
that
> >=C2=A0 =C2=A0 =C2=A0The____
> >
> >=C2=A0 =C2=A0 =C2=A0| Reply Mode value 5 (Reply via Specified Path= ) MAY be repeated
but
> >=C2=A0 =C2=A0 =C2=A0all ____
> >
> >=C2=A0 =C2=A0 =C2=A0| other Reply Mode values MUST NOT be repeated= . Will update
the____
> >
> >=C2=A0 =C2=A0 =C2=A0| document to make it clear.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0That's a fine thing to say, but doesn'= t answer my question about
how
> >=C2=A0 =C2=A0 =C2=A0an implementation is supposed to behave when a= received Reply
Mode
> >=C2=A0 =C2=A0 =C2=A0Order TLV is "malformed".____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0You posted draft-ietf-mpls-lsp-ping-reply-mode= -simple-02.
Section
> >=C2=A0 =C2=A0 =C2=A03.2 swapped the order of points 4 and 5, and e= nhanced the text
to
> >=C2=A0 =C2=A0 =C2=A0read...____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A04.If a responder LSR understands the Reply Mod= e Order TLV but
the____
> >
> >=C2=A0 =C2=A0 =C2=A0TLV is not valid (due to conditions described = in the items 6,
8____
> >
> >=C2=A0 =C2=A0 =C2=A0and 9 immediately below), then the responder L= SR MUST only
use____
> >
> >=C2=A0 =C2=A0 =C2=A0the value described in the Reply Mode field of= received MPLS
echo____
> >
> >=C2=A0 =C2=A0 =C2=A0request.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0That seems to cover most bases. Good.____
> >
> >=C2=A0 =C2=A0 =C2=A0It might also be helpful to say "...the r= esponder LSR MUST
silently
> >=C2=A0 =C2=A0 =C2=A0ignore the whole Reply Mode Order TLV and MUST= only use the
value
> >=C2=A0 =C2=A0 =C2=A0from the Reply Mode field of the received MPLS= echo
request."____
> >
> >=C2=A0 =C2=A0 =C2=A0Saying this helps clarify the behavior.____ > >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0The only things I don't find covered are:_= ___
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0a. how to handle a violation of the seventh po= int____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A07.A Reply Mode value, except for Reply Mode va= lue 5 (Reply
via____
> >
> >=C2=A0 =C2=A0 =C2=A0Specified Path), MUST NOT be repeated (i.e., M= UST NOT appear____
> >
> >=C2=A0 =C2=A0 =C2=A0multiple times) in the Reply Mode Order TLV.__= __
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0I think you can address this by adding "7= " to the list of
conditions
> >=C2=A0 =C2=A0 =C2=A0in point 4.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0b. how to handle a violation of the second poi= nt____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A02. The Reply Mode Order TLV MUST NOT be includ= ed in MPLS echo
> reply.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0I think this will need additional text.____ > >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0I note that after the numbered bullets you als= o now have the
> >=C2=A0 =C2=A0 =C2=A0following text...____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0If a responder LSR receives a Reply Mode Order= TLV which does
not____
> >
> >=C2=A0 =C2=A0 =C2=A0comply to the rules described above, then the = responder LSR
MUST____
> >
> >=C2=A0 =C2=A0 =C2=A0ignore the Reply Mode Order TLV.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0This is better than point 4 and covers everyth= ing.____
> >
> >=C2=A0 =C2=A0 =C2=A0You might consider whether "ignore" = means "silently ignore" or
> >=C2=A0 =C2=A0 =C2=A0whether you want to give advice about logging.= It seems probable
> >=C2=A0 =C2=A0 =C2=A0that (because of the nature of ping) if you do= suggest logging,
you
> >=C2=A0 =C2=A0 =C2=A0also want to describe some form of thresholdin= g or damping.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0To address Loa's concern...____
> >
> >=C2=A0 =C2=A0 =C2=A0The TLV is from the optional range. It can be = ignored if it is
not
> >=C2=A0 =C2=A0 =C2=A0understood, and does not require to be include= d.____
> >
> >=C2=A0 =C2=A0 =C2=A0Loa asserted that the document says that the T= LV MUST be
included,
> >=C2=A0 =C2=A0 =C2=A0but I don't find this in -02.____
> >
> >=C2=A0 =C2=A0 =C2=A0Therefore, I think this is all fine.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0Adrian____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0*From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com
> >=C2=A0 =C2=A0 =C2=A0<mailto:nobo.akiya.dev@gmail.com>]
> >=C2=A0 =C2=A0 =C2=A0*Sent:* 25 April 2015 05:50
> >=C2=A0 =C2=A0 =C2=A0*To:* a= drian@olddog.co.uk <mailto:ad= rian@olddog.co.uk>
> >=C2=A0 =C2=A0 =C2=A0*Cc:* Loa Andersson; t.petch; Ross Callon; mpl= s;
> >=C2=A0 =C2=A0 =C2=A0= mpls-chairs@tools.ietf.org <mailto:mpls-chairs@tools.ietf.org>;
> >=C2=A0 =C2=A0 =C2=A0draft-ietf-mpls-lsp-ping-reply-mode-simple@t= ools.ietf.org
> >
<mailto:draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org&= gt;
> >=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [mpls] George can yu look at th= is - Re: end of
WGLC,
> >=C2=A0 =C2=A0 =C2=A0RE: working group last call for
> >=C2=A0 =C2=A0 =C2=A0draft-ietf-mpls-lsp-ping-reply-mode-simple-01_= ___
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0Hi Adrian, Tom, Loa,____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0This extension is currently structured such th= at it allows for
> >=C2=A0 =C2=A0 =C2=A0backwards compatibility (i.e., transit LSR not= supporting this
> >=C2=A0 =C2=A0 =C2=A0mechanism will not return "malformed requ= est" ... because the
TLV is
> >=C2=A0 =C2=A0 =C2=A0optional).____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0The result is that this mechanism becomes a be= st effort
mechanism,
> >=C2=A0 =C2=A0 =C2=A0and we will not get the full benefit until all= LSRs along the
LSP
> >=C2=A0 =C2=A0 =C2=A0(and other LSRs which could falsely receive th= e echo request)
> >=C2=A0 =C2=A0 =C2=A0implements this extension.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0One way to allow the initiator LSR to determin= e whether or not
the
> >=C2=A0 =C2=A0 =C2=A0responder LSR understood this TLV, and still k= eeping the
backwards
> >=C2=A0 =C2=A0 =C2=A0compatibility, is that we keep the Reply Mode = Order TLV as an
> >=C2=A0 =C2=A0 =C2=A0optional TLV, but require (i.e., MUST) the res= ponder LSR
> >=C2=A0 =C2=A0 =C2=A0understanding this TLV to include the Reply Mo= de Order TLV in
the
> >=C2=A0 =C2=A0 =C2=A0echo reply, potentially with result of parsing= /handling that
TLV.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0However, that's probably not the path we w= ant to go, as all (or
> >=C2=A0 =C2=A0 =C2=A0most) optional TLVs will have to do something = similar (i.e.,
include
> >=C2=A0 =C2=A0 =C2=A0the same TLV in the echo reply). This will qui= ckly result in
echo
> >=C2=A0 =C2=A0 =C2=A0reply packet bloat ... we should prevent that = as echo reply
usually
> >=C2=A0 =C2=A0 =C2=A0tends to include more information (ILS, DSMAP/= DDMAP per nexthop,
> >=C2=A0 =C2=A0 =C2=A0multipath Sub-TLVs per nexthop, etc).____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0To me, the right way to solve this is to creat= e a capability TLV
> >=C2=A0 =C2=A0 =C2=A0that mandates the reponder LSR to return which= features it
supports
> >=C2=A0 =C2=A0 =C2=A0in bitmaps or something very compact. But this= can be done in a
> >=C2=A0 =C2=A0 =C2=A0separate effort/draft.____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0In short, my preference for this document is t= o go as is (after
> >=C2=A0 =C2=A0 =C2=A0incorporating comments from Tom).____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0Thanks!____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0-Nobo____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >=C2=A0 =C2=A0 =C2=A0On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel=
<adrian@olddog.co.uk
> >=C2=A0 =C2=A0 =C2=A0<mailto:adrian@olddog.co.uk>> wrote:____
> >
> >=C2=A0 =C2=A0 =C2=A0Thanks Loa,
> >
> >=C2=A0 =C2=A0 =C2=A0You captured it. The edge cases need to be nai= led down.
> >
> >=C2=A0 =C2=A0 =C2=A0Personally I have no particular preference for= where it is
nailed,
> >=C2=A0 =C2=A0 =C2=A0but I don't
> >=C2=A0 =C2=A0 =C2=A0want it flapping in the breeze.
> >
> >=C2=A0 =C2=A0 =C2=A0A
> >
> >=C2=A0 =C2=A0 =C2=A0 > -----Original Message-----
> >=C2=A0 =C2=A0 =C2=A0 > From: mpls [mailto:mpls-bounces@ietf.org
> >=C2=A0 =C2=A0 =C2=A0<mailto:mpls-bounces@ietf.org>] On Behalf Of Loa Andersson
> >=C2=A0 =C2=A0 =C2=A0 > Sent: 23 April 2015 13:59
> >=C2=A0 =C2=A0 =C2=A0 > To: t.petch; Nobo Akiya
> >=C2=A0 =C2=A0 =C2=A0 > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org
> >=C2=A0 =C2=A0 =C2=A0<mailto:mpls-chairs@tools.ietf.org>;
> >=C2=A0 =C2=A0 =C2=A0draft-ietf-mpls-lsp-ping-reply-
> >=C2=A0 =C2=A0 =C2=A0 > mode-simple@tools.ietf.org
<mailto:mode-simple@tools.= ietf.org>
> >=C2=A0 =C2=A0 =C2=A0 > Subject: [mpls] George can yu look at th= is - Re: end of WGLC,
RE:
> >=C2=A0 =C2=A0 =C2=A0working
> >=C2=A0 =C2=A0 =C2=A0group
> >=C2=A0 =C2=A0 =C2=A0 > last call for draft-ietf-mpls-lsp-ping-r= eply-mode-simple-01
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Tom,
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > The question you and Adrian asks is what= to do if the Reply
Mode
> >=C2=A0 =C2=A0 =C2=A0 > Order TLV is missing.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > There is something fishy here, I'd l= ike George to look at
this.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > The LSP Ping design says that TLVs from = this range may be
silentsly
> >=C2=A0 =C2=A0 =C2=A0 > dropped, my take is that we don't ne= ed to specify anything
more
> >=C2=A0 =C2=A0 =C2=A0 > than that.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Now, we say that it MUST be present, and= after thinking
around a bit
> >=C2=A0 =C2=A0 =C2=A0 > I wonder if the TLV should be assigned f= rom the mandatory
range
> >=C2=A0 =C2=A0 =C2=A0instead?
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Or if the MUST be present means that the= message will be
malformed if
> >=C2=A0 =C2=A0 =C2=A0 > it is not there, and the message should = be discarded.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > OK - now I'm confused.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > /Loa
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > On 2015-04-23 13:02, t.petch wrote:
> >=C2=A0 =C2=A0 =C2=A0 > > ---- Original Message -----
> >=C2=A0 =C2=A0 =C2=A0 > > From: "Loa Andersson" <= ;loa@pi.nu <mailto:loa@pi.nu>>
> >=C2=A0 =C2=A0 =C2=A0 > > Sent: Wednesday, April 22, 2015 2:1= 5 PM
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >> Tom,
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >> On 2015-04-20 00:07, Nobo Akiya= wrote:
> >=C2=A0 =C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0 <tp&= gt;
> >=C2=A0 =C2=A0 =C2=A0 > >>>
> >=C2=A0 =C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0 Yes but= ... I think that it is a change of meaning.
Is is
> >=C2=A0 =C2=A0 =C2=A0 > > enough just
> >=C2=A0 =C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0 to igno= re the TLV or should the whole PDU be
discarded?
> >=C2=A0 =C2=A0 =C2=A0I find
> >=C2=A0 =C2=A0 =C2=A0 > > it
> >=C2=A0 =C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0 difficu= lt to know but don't feel strongly about that
> >=C2=A0 =C2=A0 =C2=A0choice so
> >=C2=A0 =C2=A0 =C2=A0 > > will go
> >=C2=A0 =C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0 with wh= at you suggest.
> >=C2=A0 =C2=A0 =C2=A0 > >>>
> >=C2=A0 =C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0 </tp= >
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >> So I don't misunderstand wh= at you are saying. It seems to
me
> >=C2=A0 =C2=A0 =C2=A0like the
> >=C2=A0 =C2=A0 =C2=A0 > >> comments made by Adrian and you= actually requires a
"change of
> >=C2=A0 =C2=A0 =C2=A0 > > meaning",
> >=C2=A0 =C2=A0 =C2=A0 > >> that is kind of essence of a &q= uot;comment", right?
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >> As for what to do with if the T= LV is not recognized, it is
> >=C2=A0 =C2=A0 =C2=A0 > >> intentionally requested from a = space where it can be
silently
> >=C2=A0 =C2=A0 =C2=A0dropped
> >=C2=A0 =C2=A0 =C2=A0 > >> (i.e. "ignored").
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >>=C2=A0 =C2=A0 =C2=A0 The new TLV= Type value should be assigned from the
range
> >=C2=A0 =C2=A0 =C2=A0 > >>=C2=A0 =C2=A0 =C2=A0 (32768-4916= 1) specified in [RFC4379] section 3 that
> >=C2=A0 =C2=A0 =C2=A0allows the TLV
> >=C2=A0 =C2=A0 =C2=A0 > >>=C2=A0 =C2=A0 =C2=A0 type to be = silently dropped if not recognized.
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Type= =C2=A0 =C2=A0Meaning=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reference
> >=C2=A0 =C2=A0 =C2=A0 > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ----= =C2=A0 =C2=A0-------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------
> >=C2=A0 =C2=A0 =C2=A0 > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 TBD1= =C2=A0 =C2=A0Reply Mode Order TLV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0this
document
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >> What is it that I miss?
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Nothing serious.=C2=A0 My initial t= hought was to echo Adrian,
that,
> >=C2=A0 =C2=A0 =C2=A0at least
> >=C2=A0 =C2=A0 =C2=A0 > > in this context, there should be an= indication what to do
if a
> >=C2=A0 =C2=A0 =C2=A0MUST or
> >=C2=A0 =C2=A0 =C2=A0 > > SHOULD was violated without just th= en having a clear sense
of
> >=C2=A0 =C2=A0 =C2=A0what it
> >=C2=A0 =C2=A0 =C2=A0 > > should be instead.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > The I-D did require (MUST) one entr= y in the TLV and wanted
(SHOULD)
> >=C2=A0 =C2=A0 =C2=A0 > > more.=C2=A0 Adding what to do if th= at did not happen I was
seeing as
> >=C2=A0 =C2=A0 =C2=A0 > > clarification.=C2=A0 I then read No= bo as proposing going a bit
> >=C2=A0 =C2=A0 =C2=A0further saying
> >=C2=A0 =C2=A0 =C2=A0 > > requires (MUST) one or more.=C2=A0 = Which might lead to boxes
taking a
> >=C2=A0 =C2=A0 =C2=A0 > > simplistic approach and always putt= ing in the new TLV with
a single
> >=C2=A0 =C2=A0 =C2=A0 > > entry and ignoring the traditional = TLV.=C2=A0 Not a problem just
a
> >=C2=A0 =C2=A0 =C2=A0change
> >=C2=A0 =C2=A0 =C2=A0 > > from what others might think that t= hey have consented to.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > On the question of what to do when = the rules are violated,
> >=C2=A0 =C2=A0 =C2=A0again I did
> >=C2=A0 =C2=A0 =C2=A0 > > not initially think of what the act= ion should be.=C2=A0 On
> >=C2=A0 =C2=A0 =C2=A0reflection, I am
> >=C2=A0 =C2=A0 =C2=A0 > > still unsure.=C2=A0 I understand th= at the Reply Mode Order TLV
is
> >=C2=A0 =C2=A0 =C2=A0optional
> >=C2=A0 =C2=A0 =C2=A0 > > and so can be ignored when not unde= rstood; that's fine.
But if
> >=C2=A0 =C2=A0 =C2=A0it is
> >=C2=A0 =C2=A0 =C2=A0 > > understood and can be seen to be de= fective, should the box
with
> >=C2=A0 =C2=A0 =C2=A0that
> >=C2=A0 =C2=A0 =C2=A0 > > knowledge discard just that TLV and= accept the remainder of
the
> >=C2=A0 =C2=A0 =C2=A0message?
> >=C2=A0 =C2=A0 =C2=A0 > > Or should it argue that if this TLV= is defective, then
likely
> >=C2=A0 =C2=A0 =C2=A0the rest
> >=C2=A0 =C2=A0 =C2=A0 > > is as well and should be ignored?= =C2=A0 I am unsure.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > If there is scope for a breach of s= ecurity, or taking a hit
in
> >=C2=A0 =C2=A0 =C2=A0 > > performance, then ignore is the rig= ht policy. If the
> >=C2=A0 =C2=A0 =C2=A0requirement is to
> >=C2=A0 =C2=A0 =C2=A0 > > get as much data as possible from a= failing network, then
use
> >=C2=A0 =C2=A0 =C2=A0it is the
> >=C2=A0 =C2=A0 =C2=A0 > > right policy.=C2=A0 As long as the = I-D is clear, I am not too
fussed
> >=C2=A0 =C2=A0 =C2=A0which
> >=C2=A0 =C2=A0 =C2=A0 > > way it goes.=C2=A0 I am content wit= h the changes that Nobo has
proposed.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Tom Petch
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >> /Loa
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >> --
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >>
> >=C2=A0 =C2=A0 =C2=A0 > >> Loa Andersson=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: > >=C2=A0 =C2=A0 =C2=A0loa@m= ail01.huawei.com <mailto:lo= a@mail01.huawei.com>
> >=C2=A0 =C2=A0 =C2=A0 > >> Senior MPLS Expert loa@pi.nu <mailto:loa@= pi.nu>
> >=C2=A0 =C2=A0 =C2=A0 > >> Huawei Technologies (consultant= )=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21
64
> >=C2=A0 =C2=A0 =C2=A0<tel:%2B46%20739%2081%2021%2064>
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> --
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> Loa Andersson
email:loa@mail01.huawei.co= m
> <mailto:loa@mail01.huawei.= com>
> >=C2=A0 =C2=A0 =C2=A0> Senior MPLS Expertloa@pi.nu <mailto:loa@pi.nu= >
> >=C2=A0 =C2=A0 =C2=A0> Huawei Technologies (consultant)=C2=A0 = =C2=A0 =C2=A0phone:+46 739 81 21 64
> <tel:%2B46%20739%2081%2021%2064>
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> _________________________________________= ______
> >=C2=A0 =C2=A0 =C2=A0> mpls mailing list
> >=C2=A0 =C2=A0 =C2=A0>mpls@ietf= .org <mailto:mpls@ietf.org><= br> > >=C2=A0 =C2=A0 =C2=A0>https://www.ietf.org/mailman/listinfo/mp= ls____
> >
> >=C2=A0 =C2=A0 =C2=A0__ __
> >
> >
>
> --
>
>
> Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
> Senior MPLS Expert=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 loa@pi.= nu
> Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=


--089e0158c40e84d4f905151167b4-- From nobody Sat May 2 01:49:13 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145671A1B44 for ; Sat, 2 May 2015 01:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uz4i4zokdC2Q for ; Sat, 2 May 2015 01:49:09 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC371A1B40 for ; Sat, 2 May 2015 01:49:09 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 52B3A1801127; Sat, 2 May 2015 10:49:07 +0200 (CEST) Message-ID: <55448F85.5050803@pi.nu> Date: Sat, 02 May 2015 10:49:09 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Andrew G. Malis" References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 08:49:12 -0000 Andy, So you say that even though the labels in draft-hao-mpls-ip-hard-pipe are dynamically allocated we should call them "static", because that is how we defined them for MPLS-TP. Could you accept the terminology that Mustapha and I seems to be converging on: Configured labels - labels that are assigned and reclaimed by configuration. I think I prefer that we cahnge "assigned" for "installed", but for now that is not important. /Loa On 2015-05-01 15:36, Andrew G. Malis wrote: > Loa, > > Those are exactly "static" labels as we've defined them for MPLS-TP, as > they aren't being installed by a dynamic control plane on the routers > (LDP or RSVP-TE). See the text in section 3.11 of RFC 5921: > > A PW or LSP may be statically configured without the support of a > dynamic control plane. This may be either by direct configuration of > the PEs/LSRs or via a network management system. > > > Cheers, > Andy > > > On Fri, May 1, 2015 at 6:58 AM, Loa Andersson > wrote: > > Mustapha and Andy, > > If we are talking about manual configure (manually installed labels), > this is not what is not what is going on in the hard-pipe network. > > It is of course possible to run any MPLS network with all or a subset > of the labels manually installed. We did that in 1999 whenm I worked > with a Swedish operator. Awaiting tests and decision on the mix of > signalling protocols we for several months did run our network by > installing all labels manually, we never thought about that as "static", > but I could live with that terminology if we want to use it. > > What is going on in the hard-pipe network is a bit different. The NMS > (centralized controller) is configured with a label space per node to > be used for the hard-pipe stratum. The NMS then allocate labels to be > installed on the nodes as a LSP is requested and remove them and returns > them to the pool when the LSP is taken down. > > I tend to think about this as dynamic configured labels. Dynamic as > they are installed and removed depending on the life time of the LSPs. > Configured as it is done by the NMS. > > Mustapha, > > Would "configured labels" cover the concerns you have. > > /Loa > > On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote: > > Thanks Andy for the reference. Indeed, I was referring to > assignment of > initial label and of any subsequent label change of an LSP or a > PW by > configuration. This is sometimes referred to as “manual” > configuration > and the LSP or PW is referred to as static. > > That definition fits I believe what is being described in > draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm. > > Regards, > > Mustapha. > > *From:*Andrew G. Malis [mailto:agmalis@gmail.com > ] > *Sent:* Thursday, April 30, 2015 8:52 AM > *To:* Loa Andersson > *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org > ; Nevil Brownlee > *Subject:* Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 > > Loa, > > I think the reference that you're looking for is section 3.11 of > RFC 5921. > > Cheers, > > Andy > > On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson > >> wrote: > > Mustapha, > > That is still not a definition possible to refrence. > > I've always been a bit confused by the distinction between > "static" and > "dynamic", especially when it comes to labels, a bit less so if > we talk > about LSPs. > > To me the term "static" and "dynamic" seems to indicate how > long lived > or how easy they are to change. > > If an NMS or any centralized controller instal and remove > LSPs/labels > with the same frequency as e.g. LDP are they still "static"? > > I agree that there is a possible classification of "configured > LSPs/labels" vs. "signaled LSPs/labels". > > In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses > configured labels. > > Would that terminology be acceptable for you? > > /Loa > > > > On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote: > > Hi Loa, > By static label, I meant a label which is assigned to a LSP or a > PW by > configuration and not by a control plane protocol. I believe this is > what is being described in this draft but let me know if I am wrong. > > Regards, > Mustapha. > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu > >] > Sent: Wednesday, April 29, 2015 3:21 AM > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Cc: Nevil Brownlee > Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 > > Mustapha, > > in line please. > > On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: > > Dear all, > I was asked to review this draft which is intended to be handled > in the > > Independent Stream. Below are my comments to the authors. > > > Members of this list can also provide comments to the authors. > Please > copy the > > Independent Submission Editorial Board at the following address: > > rfc-ise@rfc-editor.org > > > > > Regards, > Mustapha. > ---------------------------- > https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 > > 1. Overall comment: > This document describes how a guaranteed bandwidth service can > be deployed > > in a MPLS network by partitioning the network resources into two > managed > layers, > referred to as strata. The guaranteed service layer is referred > to as > "Hard Pipe" > stratum. > > > The management of the resources and the placement of the MPLS > tunnels and > > services into the "Hard Pipe" stratum are performed with a > management > system. > Thus the transport and service labels are static but this important > information has > not been stated upfront in the document. > > Do you have a a definition of "static labels" that we can refer to? > > /Loa > Only in section 6 that MPLS-TP was mentioned. Furthermore, the > reference > to T- > LDP signaled labels in Section 3 adds to the confusion. > > I propose that the Introduction and Scope sections be > explicit about the > > framework used to achieve the "Hard Pipe" stratum, that is by > means of a > management system and static transport and service labels. > > > In fact, I would think the document value would be in describing > more > details of > > the framework including configuration aspects, resource and service > management > including resilience. These aspects have not been sufficiently > addressed > and the > focus was more on how to use MPLS labels to differentiate the > two strata. > > > 2. Section 1.1 - Scope: > As part of the second bullet, I cannot find in the document how > a router > protects > > the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" > stratum > overbooks a > link. Having a separate label for the guaranteed service is not > sufficient. The > authors should describe if LSP pre-emption and/or QoS markings > are used to > differentiate the treatment across the strata. > > > 3. Section 3: > If the document objective is to describe the framework used, > then this > section > > should begin by explaining the initial configuration performed > by the > NMS to lay > the ground for the building of the two stratums. This includes the > partitioning of the > links, the assignment of transport and service label ranges in the > routers, the > overbooking strategy, etc. > > > Then, you can discuss how a guaranteed service is configured in > the network > > using static transport labels and static service labels. This should > cover the > placement of the working and backup paths since Section 6 > mentions MPLS-TP > protection is used. > > > Next, a description of how the transport LSP and service are > monitored for > > continuity and defects. > > > Finally, the behavior when resources are overbooked and what > services > are pre- > > empted or degraded should be described. > > ------------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu > > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu > > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat May 2 02:33:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A060B1A1B77; Sat, 2 May 2015 02:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ssccoX64fH14; Sat, 2 May 2015 02:33:53 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAAF1A1B76; Sat, 2 May 2015 02:33:53 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DF8C71801127; Sat, 2 May 2015 11:33:51 +0200 (CEST) Message-ID: <55449A01.8000505@pi.nu> Date: Sat, 02 May 2015 11:33:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] MPLS-RT review of draft-cui-mpls-tp-mfp-use-case-and-requirements closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 09:33:54 -0000 Authors, WG, We now have three (Greg, Jia and Eric) MPLS-RT reviews of the draft-cui-mpls-tp-mfp-use-case-and-requirementsand the MPLS-RT is closed; which does not mean that comments are not welcome, anyone can review and send comments to the list and the authors. Could the authors please review comments and update as necessary before we go to the working group adoption poll! /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat May 2 06:55:15 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926021A8845 for ; Sat, 2 May 2015 06:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 vlAfey_Mvq4i for ; Sat, 2 May 2015 06:55:09 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8971A8844 for ; Sat, 2 May 2015 06:55:09 -0700 (PDT) Received: by wgin8 with SMTP id n8so112378027wgi.0 for ; Sat, 02 May 2015 06:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pkz/aQ5RDmO5y8Fh/v1aEOfVKxtFkZikIQCAjH+m3kk=; b=I6xLrNRuIUapAGbWFeGlettkxhq7Tf5Fo3KgUZe5QEvOXMIZqxRovOvx7yI9V4aWVu ToP6PzFqNq/RiP/Biq8mdkCb9iYfGsS2tP6a4f2Is9TmF/OgDIlqx07pDSbkGI4uXsRI CWLiXW0qjpliHmWR9x8GIfLwqNg5Y9biuZVrZgLxhIM2tMvby8KGTjUr40w4gcekIJHJ pOaBBTi0iPn/zlc3S+WDy09r+32CNHkYZFgTu8raX15nN7zVpuXzBURn1WkZjdaC6G54 NnvSwQzGO1HNjB/GgNToQQtbIlVT4m6TiiUWIBzxJoy8dUF+T6F6dlDxAT6JPXXgRFxP Mu5A== X-Received: by 10.180.93.193 with SMTP id cw1mr5260731wib.12.1430574907909; Sat, 02 May 2015 06:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.182.215 with HTTP; Sat, 2 May 2015 06:54:47 -0700 (PDT) In-Reply-To: <55448F85.5050803@pi.nu> References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu> <55448F85.5050803@pi.nu> From: "Andrew G. Malis" Date: Sat, 2 May 2015 09:54:47 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=f46d043bdede35eca2051519ad72 Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 13:55:14 -0000 --f46d043bdede35eca2051519ad72 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Loa, Sure, that works for me too. A good word to use instead of "installed" is "provisioned". Cheers, Andy On Sat, May 2, 2015 at 4:49 AM, Loa Andersson wrote: > Andy, > > So you say that even though the labels in draft-hao-mpls-ip-hard-pipe > are dynamically allocated we should call them "static", because that is > how we defined them for MPLS-TP. > > Could you accept the terminology that Mustapha and I seems to be > converging on: > > Configured labels - labels that are assigned and reclaimed by > configuration. > > I think I prefer that we cahnge "assigned" for "installed", but for now > that is not important. > > /Loa > > On 2015-05-01 15:36, Andrew G. Malis wrote: > >> Loa, >> >> Those are exactly "static" labels as we've defined them for MPLS-TP, as >> they aren't being installed by a dynamic control plane on the routers >> (LDP or RSVP-TE). See the text in section 3.11 of RFC 5921: >> >> A PW or LSP may be statically configured without the support of a >> dynamic control plane. This may be either by direct configuration o= f >> the PEs/LSRs or via a network management system. >> >> >> Cheers, >> Andy >> >> >> On Fri, May 1, 2015 at 6:58 AM, Loa Andersson > > wrote: >> >> Mustapha and Andy, >> >> If we are talking about manual configure (manually installed labels)= , >> this is not what is not what is going on in the hard-pipe network. >> >> It is of course possible to run any MPLS network with all or a subse= t >> of the labels manually installed. We did that in 1999 whenm I worked >> with a Swedish operator. Awaiting tests and decision on the mix of >> signalling protocols we for several months did run our network by >> installing all labels manually, we never thought about that as >> "static", >> but I could live with that terminology if we want to use it. >> >> What is going on in the hard-pipe network is a bit different. The NM= S >> (centralized controller) is configured with a label space per node t= o >> be used for the hard-pipe stratum. The NMS then allocate labels to b= e >> installed on the nodes as a LSP is requested and remove them and >> returns >> them to the pool when the LSP is taken down. >> >> I tend to think about this as dynamic configured labels. Dynamic as >> they are installed and removed depending on the life time of the LSP= s. >> Configured as it is done by the NMS. >> >> Mustapha, >> >> Would "configured labels" cover the concerns you have. >> >> /Loa >> >> On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote: >> >> Thanks Andy for the reference. Indeed, I was referring to >> assignment of >> initial label and of any subsequent label change of an LSP or a >> PW by >> configuration. This is sometimes referred to as =E2=80=9Cmanual= =E2=80=9D >> configuration >> and the LSP or PW is referred to as static. >> >> That definition fits I believe what is being described in >> draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm. >> >> Regards, >> >> Mustapha. >> >> *From:*Andrew G. Malis [mailto:agmalis@gmail.com >> ] >> *Sent:* Thursday, April 30, 2015 8:52 AM >> *To:* Loa Andersson >> *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> ; Nevil Brownlee >> *Subject:* Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 >> >> Loa, >> >> I think the reference that you're looking for is section 3.11 of >> RFC 5921. >> >> Cheers, >> >> Andy >> >> On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson > >> >> wrote: >> >> Mustapha, >> >> That is still not a definition possible to refrence. >> >> I've always been a bit confused by the distinction between >> "static" and >> "dynamic", especially when it comes to labels, a bit less so if >> we talk >> about LSPs. >> >> To me the term "static" and "dynamic" seems to indicate how >> long lived >> or how easy they are to change. >> >> If an NMS or any centralized controller instal and remove >> LSPs/labels >> with the same frequency as e.g. LDP are they still "static"? >> >> I agree that there is a possible classification of "configured >> LSPs/labels" vs. "signaled LSPs/labels". >> >> In that terminology I'd say that draft-hao-mpls-ip-hard-pipe use= s >> configured labels. >> >> Would that terminology be acceptable for you? >> >> /Loa >> >> >> >> On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote: >> >> Hi Loa, >> By static label, I meant a label which is assigned to a LSP or a >> PW by >> configuration and not by a control plane protocol. I believe thi= s >> is >> what is being described in this draft but let me know if I am >> wrong. >> >> Regards, >> Mustapha. >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu >> >] >> Sent: Wednesday, April 29, 2015 3:21 AM >> To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> > mpls@ietf.org>> >> Cc: Nevil Brownlee >> Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 >> >> Mustapha, >> >> in line please. >> >> On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: >> >> Dear all, >> I was asked to review this draft which is intended to be handled >> in the >> >> Independent Stream. Below are my comments to the authors. >> >> >> Members of this list can also provide comments to the authors. >> Please >> copy the >> >> Independent Submission Editorial Board at the following address: >> >> rfc-ise@rfc-editor.org >> > >> >> >> >> Regards, >> Mustapha. >> ---------------------------- >> https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 >> >> 1. Overall comment: >> This document describes how a guaranteed bandwidth service can >> be deployed >> >> in a MPLS network by partitioning the network resources into two >> managed >> layers, >> referred to as strata. The guaranteed service layer is referred >> to as >> "Hard Pipe" >> stratum. >> >> >> The management of the resources and the placement of the MPLS >> tunnels and >> >> services into the "Hard Pipe" stratum are performed with a >> management >> system. >> Thus the transport and service labels are static but this >> important >> information has >> not been stated upfront in the document. >> >> Do you have a a definition of "static labels" that we can refer >> to? >> >> /Loa >> Only in section 6 that MPLS-TP was mentioned. Furthermore, the >> reference >> to T- >> LDP signaled labels in Section 3 adds to the confusion. >> >> I propose that the Introduction and Scope sections be >> explicit about the >> >> framework used to achieve the "Hard Pipe" stratum, that is by >> means of a >> management system and static transport and service labels. >> >> >> In fact, I would think the document value would be in describing >> more >> details of >> >> the framework including configuration aspects, resource and >> service >> management >> including resilience. These aspects have not been sufficiently >> addressed >> and the >> focus was more on how to use MPLS labels to differentiate the >> two strata. >> >> >> 2. Section 1.1 - Scope: >> As part of the second bullet, I cannot find in the document how >> a router >> protects >> >> the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" >> stratum >> overbooks a >> link. Having a separate label for the guaranteed service is not >> sufficient. The >> authors should describe if LSP pre-emption and/or QoS markings >> are used to >> differentiate the treatment across the strata. >> >> >> 3. Section 3: >> If the document objective is to describe the framework used, >> then this >> section >> >> should begin by explaining the initial configuration performed >> by the >> NMS to lay >> the ground for the building of the two stratums. This includes t= he >> partitioning of the >> links, the assignment of transport and service label ranges in t= he >> routers, the >> overbooking strategy, etc. >> >> >> Then, you can discuss how a guaranteed service is configured in >> the network >> >> using static transport labels and static service labels. This >> should >> cover the >> placement of the working and backup paths since Section 6 >> mentions MPLS-TP >> protection is used. >> >> >> Next, a description of how the transport LSP and service are >> monitored for >> >> continuity and defects. >> >> >> Finally, the behavior when resources are overbooked and what >> services >> are pre- >> >> empted or degraded should be described. >> >> ------------------------------------ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> -- >> >> >> Loa Andersson email: >> loa@mail01.huawei.com >> > >> Senior MPLS Expert loa@pi.nu >> > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> >> >> -- >> >> >> Loa Andersson email: >> loa@mail01.huawei.com >> > >> Senior MPLS Expert loa@pi.nu >> > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --f46d043bdede35eca2051519ad72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

Sure, that works for me too. A goo= d word to use instead of "installed" is "provisioned".<= /div>

Cheers,
Andy

On Sat, May 2, 2015 at 4:49 AM, L= oa Andersson <loa@pi.nu> wrote:
An= dy,

So you say that even though the labels in draft-hao-mpls-ip-hard-pipe
are dynamically allocated we should call them "static", because t= hat is
how we defined them for MPLS-TP.

Could you accept the terminology that Mustapha and I seems to be
converging on:

Configured labels - labels that are assigned and reclaimed by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0configuration.

I think I prefer that we cahnge "assigned" for "installed&qu= ot;, but for now
that is not important.

/Loa

On 2015-05-01 15:36, Andrew G. Malis wrote:
Loa,

Those are exactly "static" labels as we've defined them for M= PLS-TP, as
they aren't being installed by a dynamic control plane on the routers (LDP or RSVP-TE). See the text in section 3.11 of RFC 5921:

=C2=A0 =C2=A0 A PW or LSP may be statically configured without the support = of a
=C2=A0 =C2=A0 dynamic control plane.=C2=A0 This may be either by direct con= figuration of
=C2=A0 =C2=A0 the PEs/LSRs or via a network management system.


Cheers,
Andy


On Fri, May 1, 2015 at 6:58 AM, Loa Andersson <loa@pi.nu
<mailto:loa@pi.nu>= > wrote:

=C2=A0 =C2=A0 Mustapha and Andy,

=C2=A0 =C2=A0 If we are talking about manual configure (manually installed = labels),
=C2=A0 =C2=A0 this is not what is not what is going on in the hard-pipe net= work.

=C2=A0 =C2=A0 It is of course possible to run any MPLS network with all or = a subset
=C2=A0 =C2=A0 of the labels manually installed. We did that in 1999 whenm I= worked
=C2=A0 =C2=A0 with a Swedish operator. Awaiting tests and decision on the m= ix of
=C2=A0 =C2=A0 signalling protocols we for several months did run our networ= k by
=C2=A0 =C2=A0 installing all labels manually, we never thought about that a= s "static",
=C2=A0 =C2=A0 but I could live with that terminology if we want to use it.<= br>
=C2=A0 =C2=A0 What is going on in the hard-pipe network is a bit different.= The NMS
=C2=A0 =C2=A0 (centralized controller) is configured with a label space per= node to
=C2=A0 =C2=A0 be used for the hard-pipe stratum. The NMS then allocate labe= ls to be
=C2=A0 =C2=A0 installed on the nodes as a LSP is requested and remove them = and returns
=C2=A0 =C2=A0 them to the pool when the LSP is taken down.

=C2=A0 =C2=A0 I tend to think about this as dynamic configured labels. Dyna= mic as
=C2=A0 =C2=A0 they are installed and removed depending on the life time of = the LSPs.
=C2=A0 =C2=A0 Configured as it is done by the NMS.

=C2=A0 =C2=A0 Mustapha,

=C2=A0 =C2=A0 Would "configured labels" cover the concerns you ha= ve.

=C2=A0 =C2=A0 /Loa

=C2=A0 =C2=A0 On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks Andy for the reference. Indeed, I was re= ferring to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 assignment of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 initial label and of any subsequent label chang= e of an LSP or a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 PW by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration. This is sometimes referred to as= =E2=80=9Cmanual=E2=80=9D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and the LSP or PW is referred to as static.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 That definition fits I believe what is being de= scribed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-hao-mpls-ip-hard-pipe-01 but Loa can conf= irm.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mustapha.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *From:*Andrew G. Malis [mailto:agmalis@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:agmalis@gmail.com>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent:* Thursday, April 30, 2015 8:52 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:* Loa Andersson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org>; Nevil Brownlee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subject:* Re: [mpls] Review of draft-hao-mpls-= ip-hard-pipe-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Loa,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I think the reference that you're looking f= or is section 3.11 of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 5921.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson = <loa@pi.nu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mustapha,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 That is still not a definition possible to refr= ence.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've always been a bit confused by the dist= inction between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "static" and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "dynamic", especially when it comes t= o labels, a bit less so if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 we talk
=C2=A0 =C2=A0 =C2=A0 =C2=A0 about LSPs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 To me the term=C2=A0 "static" and &qu= ot;dynamic" seems to indicate how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 long lived
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or how easy they are to change.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an NMS or any centralized controller instal = and remove
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LSPs/labels
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with the same frequency as e.g. LDP are they st= ill "static"?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree that there is a possible classification= of "configured
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LSPs/labels" vs. "signaled LSPs/label= s".

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In that terminology I'd say that draft-hao-= mpls-ip-hard-pipe uses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configured labels.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Would that terminology be acceptable for you?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /Loa



=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2015-04-29 19:26, Aissaoui, Mustapha (Mustap= ha) wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Loa,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 By static label, I meant a label which is assig= ned to a LSP or a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 PW by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration and not by a control plane protoc= ol. I believe this is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 what is being described in this draft but let m= e know if I am wrong.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mustapha.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Loa Andersson [mailto:loa@pi.nu <mailto:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Wednesday, April 29, 2015 3:21 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org> <mailto:mpls@ietf.org <mailto:mpls@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: Nevil Brownlee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [mpls] Review of draft-hao-mpls-ip= -hard-pipe-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mustapha,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 in line please.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2015-04-28 18:01, Aissaoui, Mustapha (Mustap= ha) wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Dear all,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I was asked to review this draft which is inten= ded to be handled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Stream. Below are my comments to th= e authors.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Members of this list can also provide comments = to the authors.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please
=C2=A0 =C2=A0 =C2=A0 =C2=A0 copy the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission Editorial Board at the f= ollowing address:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 rfc-ise@rfc-editor.org <mailto:rfc-ise@rfc-editor.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:rfc-ise@rfc-editor.org <mailto:rfc-ise@rfc-editor.org&g= t;>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mustapha.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ----------------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft= -hao-mpls-ip-hard-pipe-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Overall comment:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This document describes how a guaranteed bandwi= dth service can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be deployed

=C2=A0 =C2=A0 =C2=A0 =C2=A0 in a MPLS network by partitioning the network r= esources into two
=C2=A0 =C2=A0 =C2=A0 =C2=A0 managed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 layers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 referred to as strata. The=C2=A0 guaranteed ser= vice layer is referred
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Hard Pipe"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stratum.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 The management of the resources and the placeme= nt of the MPLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tunnels and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 services into the=C2=A0 "Hard Pipe" s= tratum are performed with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 system.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thus the transport and service labels are stati= c but this important
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not been stated upfront in the document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Do you have a a definition of "static labe= ls" that we can refer to?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /Loa
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Only in section 6 that MPLS-TP was mentioned. F= urthermore, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to T-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LDP signaled labels in Section 3 adds to the co= nfusion.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I propose that the Introduc= tion and Scope sections be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 explicit about the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 framework used to achieve the "Hard Pipe&q= uot; stratum, that is by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 means of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 management system and static transport and serv= ice labels.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 In fact, I would think the document value would= be in describing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 details of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the framework including configuration aspects, = resource and service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 including resilience. These aspects have not be= en sufficiently
=C2=A0 =C2=A0 =C2=A0 =C2=A0 addressed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 focus was more on how to use MPLS labels to dif= ferentiate the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 two strata.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Section 1.1 - Scope:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 As part of the second bullet, I cannot find in = the document how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a router
=C2=A0 =C2=A0 =C2=A0 =C2=A0 protects

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the traffic of the "Hard Pipe" stratu= m if the "Normal IP/MPLS"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stratum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 overbooks a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 link. Having a separate label for the guarantee= d service is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sufficient. The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authors should describe if LSP pre-emption and/= or QoS markings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 differentiate the treatment across the strata.<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. Section 3:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the document objective is to describe the fr= amework used,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 then this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 section

=C2=A0 =C2=A0 =C2=A0 =C2=A0 should begin by explaining the initial configur= ation performed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 NMS to lay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the ground for the building of the two stratums= . This includes the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 partitioning of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 links, the assignment of transport and service = label ranges in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 routers, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 overbooking strategy, etc.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Then, you can discuss how a guaranteed service = is configured in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the network

=C2=A0 =C2=A0 =C2=A0 =C2=A0 using static transport labels and static servic= e labels. This should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cover the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 placement of the working and backup paths since= Section 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mentions MPLS-TP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 protection is used.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Next, a description of how the transport LSP an= d service are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 monitored for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 continuity and defects.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Finally, the behavior when resources are overbo= oked and what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 services
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are pre-

=C2=A0 =C2=A0 =C2=A0 =C2=A0 empted or degraded should be described.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ------------------------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mpls

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Huawei Technologies (consultant)=C2=A0 =C2=A0 = =C2=A0phone: +46 739 81 21 64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 --


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Huawei Technologies (consultant)=C2=A0 =C2=A0 = =C2=A0phone: +46 739 81 21 64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mpls

=C2=A0 =C2=A0 --


=C2=A0 =C2=A0 Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
=C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com>
=C2=A0 =C2=A0 Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
=C2=A0 =C2=A0 Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
=C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>



--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=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 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--f46d043bdede35eca2051519ad72-- From nobody Sat May 2 08:22:56 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014611A890C for ; Sat, 2 May 2015 08:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Eg_gq9hQr3yZ for ; Sat, 2 May 2015 08:22:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 F3A671A877E for ; Sat, 2 May 2015 08:22:49 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E17BD290FF1C6; Sat, 2 May 2015 15:22:42 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t42FMhgf019294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 May 2015 11:22:43 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Sat, 2 May 2015 11:22:43 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "'agmalis@gmail.com'" , "'loa@pi.nu'" Thread-Topic: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 Thread-Index: AdCBzIr6SsqnVpHOQqOMLXhwS/KfnQAogseAAAwv7YAAKVIdvwABTeSgADVYhIAABYz5gAAoPXmAAAqsk4AABU+85A== Date: Sat, 2 May 2015 15:22:42 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D94835E1F@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340D94835E1FUS70UWXCHMBA01z_" MIME-Version: 1.0 Archived-At: Cc: "'mpls@ietf.org'" , "'rfc-ise@rfc-editor.org'" Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 15:22:55 -0000 --_000_4A79394211F1AF4EB57D998426C9340D94835E1FUS70UWXCHMBA01z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSBhbmQgTG9hLA0KSSBhbSBnb29kIGVpdGhlciB3YXkuDQoNCk11c3RhcGhhLg0KU2VudCBm cm9tIG15IEJsYWNrYmVycnkhDQoNCkZyb206IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFs aXNAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXksIE1heSAwMiwgMjAxNSAwOTo1NCBBTQ0KVG86 IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4NCkNjOiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3Rh cGhhKTsgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz47IE5ldmlsIEJyb3dubGVlIDxyZmMt aXNlQHJmYy1lZGl0b3Iub3JnPg0KU3ViamVjdDogUmU6IFttcGxzXSBSZXZpZXcgb2YgZHJhZnQt aGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxDQoNCkxvYSwNCg0KU3VyZSwgdGhhdCB3b3JrcyBmb3Ig bWUgdG9vLiBBIGdvb2Qgd29yZCB0byB1c2UgaW5zdGVhZCBvZiAiaW5zdGFsbGVkIiBpcyAicHJv dmlzaW9uZWQiLg0KDQpDaGVlcnMsDQpBbmR5DQoNCk9uIFNhdCwgTWF5IDIsIDIwMTUgYXQgNDo0 OSBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToN CkFuZHksDQoNClNvIHlvdSBzYXkgdGhhdCBldmVuIHRob3VnaCB0aGUgbGFiZWxzIGluIGRyYWZ0 LWhhby1tcGxzLWlwLWhhcmQtcGlwZQ0KYXJlIGR5bmFtaWNhbGx5IGFsbG9jYXRlZCB3ZSBzaG91 bGQgY2FsbCB0aGVtICJzdGF0aWMiLCBiZWNhdXNlIHRoYXQgaXMNCmhvdyB3ZSBkZWZpbmVkIHRo ZW0gZm9yIE1QTFMtVFAuDQoNCkNvdWxkIHlvdSBhY2NlcHQgdGhlIHRlcm1pbm9sb2d5IHRoYXQg TXVzdGFwaGEgYW5kIEkgc2VlbXMgdG8gYmUNCmNvbnZlcmdpbmcgb246DQoNCkNvbmZpZ3VyZWQg bGFiZWxzIC0gbGFiZWxzIHRoYXQgYXJlIGFzc2lnbmVkIGFuZCByZWNsYWltZWQgYnkNCiAgICAg ICAgICAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24uDQoNCkkgdGhpbmsgSSBwcmVmZXIgdGhhdCB3 ZSBjYWhuZ2UgImFzc2lnbmVkIiBmb3IgImluc3RhbGxlZCIsIGJ1dCBmb3Igbm93DQp0aGF0IGlz IG5vdCBpbXBvcnRhbnQuDQoNCi9Mb2ENCg0KT24gMjAxNS0wNS0wMSAxNTozNiwgQW5kcmV3IEcu IE1hbGlzIHdyb3RlOg0KTG9hLA0KDQpUaG9zZSBhcmUgZXhhY3RseSAic3RhdGljIiBsYWJlbHMg YXMgd2UndmUgZGVmaW5lZCB0aGVtIGZvciBNUExTLVRQLCBhcw0KdGhleSBhcmVuJ3QgYmVpbmcg aW5zdGFsbGVkIGJ5IGEgZHluYW1pYyBjb250cm9sIHBsYW5lIG9uIHRoZSByb3V0ZXJzDQooTERQ IG9yIFJTVlAtVEUpLiBTZWUgdGhlIHRleHQgaW4gc2VjdGlvbiAzLjExIG9mIFJGQyA1OTIxOg0K DQogICAgQSBQVyBvciBMU1AgbWF5IGJlIHN0YXRpY2FsbHkgY29uZmlndXJlZCB3aXRob3V0IHRo ZSBzdXBwb3J0IG9mIGENCiAgICBkeW5hbWljIGNvbnRyb2wgcGxhbmUuICBUaGlzIG1heSBiZSBl aXRoZXIgYnkgZGlyZWN0IGNvbmZpZ3VyYXRpb24gb2YNCiAgICB0aGUgUEVzL0xTUnMgb3Igdmlh IGEgbmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbS4NCg0KDQpDaGVlcnMsDQpBbmR5DQoNCg0KT24g RnJpLCBNYXkgMSwgMjAxNSBhdCA2OjU4IEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFp bHRvOmxvYUBwaS5udT4NCjxtYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+Pj4gd3Jv dGU6DQoNCiAgICBNdXN0YXBoYSBhbmQgQW5keSwNCg0KICAgIElmIHdlIGFyZSB0YWxraW5nIGFi b3V0IG1hbnVhbCBjb25maWd1cmUgKG1hbnVhbGx5IGluc3RhbGxlZCBsYWJlbHMpLA0KICAgIHRo aXMgaXMgbm90IHdoYXQgaXMgbm90IHdoYXQgaXMgZ29pbmcgb24gaW4gdGhlIGhhcmQtcGlwZSBu ZXR3b3JrLg0KDQogICAgSXQgaXMgb2YgY291cnNlIHBvc3NpYmxlIHRvIHJ1biBhbnkgTVBMUyBu ZXR3b3JrIHdpdGggYWxsIG9yIGEgc3Vic2V0DQogICAgb2YgdGhlIGxhYmVscyBtYW51YWxseSBp bnN0YWxsZWQuIFdlIGRpZCB0aGF0IGluIDE5OTkgd2hlbm0gSSB3b3JrZWQNCiAgICB3aXRoIGEg U3dlZGlzaCBvcGVyYXRvci4gQXdhaXRpbmcgdGVzdHMgYW5kIGRlY2lzaW9uIG9uIHRoZSBtaXgg b2YNCiAgICBzaWduYWxsaW5nIHByb3RvY29scyB3ZSBmb3Igc2V2ZXJhbCBtb250aHMgZGlkIHJ1 biBvdXIgbmV0d29yayBieQ0KICAgIGluc3RhbGxpbmcgYWxsIGxhYmVscyBtYW51YWxseSwgd2Ug bmV2ZXIgdGhvdWdodCBhYm91dCB0aGF0IGFzICJzdGF0aWMiLA0KICAgIGJ1dCBJIGNvdWxkIGxp dmUgd2l0aCB0aGF0IHRlcm1pbm9sb2d5IGlmIHdlIHdhbnQgdG8gdXNlIGl0Lg0KDQogICAgV2hh dCBpcyBnb2luZyBvbiBpbiB0aGUgaGFyZC1waXBlIG5ldHdvcmsgaXMgYSBiaXQgZGlmZmVyZW50 LiBUaGUgTk1TDQogICAgKGNlbnRyYWxpemVkIGNvbnRyb2xsZXIpIGlzIGNvbmZpZ3VyZWQgd2l0 aCBhIGxhYmVsIHNwYWNlIHBlciBub2RlIHRvDQogICAgYmUgdXNlZCBmb3IgdGhlIGhhcmQtcGlw ZSBzdHJhdHVtLiBUaGUgTk1TIHRoZW4gYWxsb2NhdGUgbGFiZWxzIHRvIGJlDQogICAgaW5zdGFs bGVkIG9uIHRoZSBub2RlcyBhcyBhIExTUCBpcyByZXF1ZXN0ZWQgYW5kIHJlbW92ZSB0aGVtIGFu ZCByZXR1cm5zDQogICAgdGhlbSB0byB0aGUgcG9vbCB3aGVuIHRoZSBMU1AgaXMgdGFrZW4gZG93 bi4NCg0KICAgIEkgdGVuZCB0byB0aGluayBhYm91dCB0aGlzIGFzIGR5bmFtaWMgY29uZmlndXJl ZCBsYWJlbHMuIER5bmFtaWMgYXMNCiAgICB0aGV5IGFyZSBpbnN0YWxsZWQgYW5kIHJlbW92ZWQg ZGVwZW5kaW5nIG9uIHRoZSBsaWZlIHRpbWUgb2YgdGhlIExTUHMuDQogICAgQ29uZmlndXJlZCBh cyBpdCBpcyBkb25lIGJ5IHRoZSBOTVMuDQoNCiAgICBNdXN0YXBoYSwNCg0KICAgIFdvdWxkICJj b25maWd1cmVkIGxhYmVscyIgY292ZXIgdGhlIGNvbmNlcm5zIHlvdSBoYXZlLg0KDQogICAgL0xv YQ0KDQogICAgT24gMjAxNS0wNC0zMCAxNTo0MiwgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBo YSkgd3JvdGU6DQoNCiAgICAgICAgVGhhbmtzIEFuZHkgZm9yIHRoZSByZWZlcmVuY2UuIEluZGVl ZCwgSSB3YXMgcmVmZXJyaW5nIHRvDQogICAgICAgIGFzc2lnbm1lbnQgb2YNCiAgICAgICAgaW5p dGlhbCBsYWJlbCBhbmQgb2YgYW55IHN1YnNlcXVlbnQgbGFiZWwgY2hhbmdlIG9mIGFuIExTUCBv ciBhDQogICAgICAgIFBXIGJ5DQogICAgICAgIGNvbmZpZ3VyYXRpb24uIFRoaXMgaXMgc29tZXRp bWVzIHJlZmVycmVkIHRvIGFzIOKAnG1hbnVhbOKAnQ0KICAgICAgICBjb25maWd1cmF0aW9uDQog ICAgICAgIGFuZCB0aGUgTFNQIG9yIFBXIGlzIHJlZmVycmVkIHRvIGFzIHN0YXRpYy4NCg0KICAg ICAgICBUaGF0IGRlZmluaXRpb24gZml0cyBJIGJlbGlldmUgd2hhdCBpcyBiZWluZyBkZXNjcmli ZWQgaW4NCiAgICAgICAgZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxIGJ1dCBMb2EgY2Fu IGNvbmZpcm0uDQoNCiAgICAgICAgUmVnYXJkcywNCg0KICAgICAgICBNdXN0YXBoYS4NCg0KICAg ICAgICAqRnJvbToqQW5kcmV3IEcuIE1hbGlzIFttYWlsdG86YWdtYWxpc0BnbWFpbC5jb208bWFp bHRvOmFnbWFsaXNAZ21haWwuY29tPg0KICAgICAgICA8bWFpbHRvOmFnbWFsaXNAZ21haWwuY29t PG1haWx0bzphZ21hbGlzQGdtYWlsLmNvbT4+XQ0KICAgICAgICAqU2VudDoqIFRodXJzZGF5LCBB cHJpbCAzMCwgMjAxNSA4OjUyIEFNDQogICAgICAgICpUbzoqIExvYSBBbmRlcnNzb24NCiAgICAg ICAgKkNjOiogQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7IG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+DQogICAgICAgIDxtYWlsdG86bXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4+OyBOZXZpbCBCcm93bmxlZQ0KICAgICAgICAqU3ViamVjdDoqIFJlOiBb bXBsc10gUmV2aWV3IG9mIGRyYWZ0LWhhby1tcGxzLWlwLWhhcmQtcGlwZS0wMQ0KDQogICAgICAg IExvYSwNCg0KICAgICAgICBJIHRoaW5rIHRoZSByZWZlcmVuY2UgdGhhdCB5b3UncmUgbG9va2lu ZyBmb3IgaXMgc2VjdGlvbiAzLjExIG9mDQogICAgICAgIFJGQyA1OTIxLg0KDQogICAgICAgIENo ZWVycywNCg0KICAgICAgICBBbmR5DQoNCiAgICAgICAgT24gVGh1LCBBcHIgMzAsIDIwMTUgYXQg Mzo0MSBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+DQogICAg ICAgIDxtYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+Pg0KICAgICAgICA8bWFpbHRv OmxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51PiA8bWFpbHRvOmxvYUBwaS5udTxtYWlsdG86bG9h QHBpLm51Pj4+PiB3cm90ZToNCg0KICAgICAgICBNdXN0YXBoYSwNCg0KICAgICAgICBUaGF0IGlz IHN0aWxsIG5vdCBhIGRlZmluaXRpb24gcG9zc2libGUgdG8gcmVmcmVuY2UuDQoNCiAgICAgICAg SSd2ZSBhbHdheXMgYmVlbiBhIGJpdCBjb25mdXNlZCBieSB0aGUgZGlzdGluY3Rpb24gYmV0d2Vl bg0KICAgICAgICAic3RhdGljIiBhbmQNCiAgICAgICAgImR5bmFtaWMiLCBlc3BlY2lhbGx5IHdo ZW4gaXQgY29tZXMgdG8gbGFiZWxzLCBhIGJpdCBsZXNzIHNvIGlmDQogICAgICAgIHdlIHRhbGsN CiAgICAgICAgYWJvdXQgTFNQcy4NCg0KICAgICAgICBUbyBtZSB0aGUgdGVybSAgInN0YXRpYyIg YW5kICJkeW5hbWljIiBzZWVtcyB0byBpbmRpY2F0ZSBob3cNCiAgICAgICAgbG9uZyBsaXZlZA0K ICAgICAgICBvciBob3cgZWFzeSB0aGV5IGFyZSB0byBjaGFuZ2UuDQoNCiAgICAgICAgSWYgYW4g Tk1TIG9yIGFueSBjZW50cmFsaXplZCBjb250cm9sbGVyIGluc3RhbCBhbmQgcmVtb3ZlDQogICAg ICAgIExTUHMvbGFiZWxzDQogICAgICAgIHdpdGggdGhlIHNhbWUgZnJlcXVlbmN5IGFzIGUuZy4g TERQIGFyZSB0aGV5IHN0aWxsICJzdGF0aWMiPw0KDQogICAgICAgIEkgYWdyZWUgdGhhdCB0aGVy ZSBpcyBhIHBvc3NpYmxlIGNsYXNzaWZpY2F0aW9uIG9mICJjb25maWd1cmVkDQogICAgICAgIExT UHMvbGFiZWxzIiB2cy4gInNpZ25hbGVkIExTUHMvbGFiZWxzIi4NCg0KICAgICAgICBJbiB0aGF0 IHRlcm1pbm9sb2d5IEknZCBzYXkgdGhhdCBkcmFmdC1oYW8tbXBscy1pcC1oYXJkLXBpcGUgdXNl cw0KICAgICAgICBjb25maWd1cmVkIGxhYmVscy4NCg0KICAgICAgICBXb3VsZCB0aGF0IHRlcm1p bm9sb2d5IGJlIGFjY2VwdGFibGUgZm9yIHlvdT8NCg0KICAgICAgICAvTG9hDQoNCg0KDQogICAg ICAgIE9uIDIwMTUtMDQtMjkgMTk6MjYsIEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpIHdy b3RlOg0KDQogICAgICAgIEhpIExvYSwNCiAgICAgICAgQnkgc3RhdGljIGxhYmVsLCBJIG1lYW50 IGEgbGFiZWwgd2hpY2ggaXMgYXNzaWduZWQgdG8gYSBMU1Agb3IgYQ0KICAgICAgICBQVyBieQ0K ICAgICAgICBjb25maWd1cmF0aW9uIGFuZCBub3QgYnkgYSBjb250cm9sIHBsYW5lIHByb3RvY29s LiBJIGJlbGlldmUgdGhpcyBpcw0KICAgICAgICB3aGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBpbiB0 aGlzIGRyYWZ0IGJ1dCBsZXQgbWUga25vdyBpZiBJIGFtIHdyb25nLg0KDQogICAgICAgIFJlZ2Fy ZHMsDQogICAgICAgIE11c3RhcGhhLg0KDQogICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQogICAgICAgIEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnU8bWFpbHRv OmxvYUBwaS5udT4gPG1haWx0bzpsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+DQogICAgICAg IDxtYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+IDxtYWlsdG86bG9hQHBpLm51PG1h aWx0bzpsb2FAcGkubnU+Pj5dDQogICAgICAgIFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIw MTUgMzoyMSBBTQ0KICAgICAgICBUbzogQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQogICAgICAgIDxtYWlsdG86bXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+IDxtYWlsdG86bXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4gPG1haWx0bzptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPj4+DQogICAgICAgIENjOiBOZXZpbCBCcm93bmxlZQ0KICAgICAgICBTdWJqZWN0OiBSZTog W21wbHNdIFJldmlldyBvZiBkcmFmdC1oYW8tbXBscy1pcC1oYXJkLXBpcGUtMDENCg0KICAgICAg ICBNdXN0YXBoYSwNCg0KICAgICAgICBpbiBsaW5lIHBsZWFzZS4NCg0KICAgICAgICBPbiAyMDE1 LTA0LTI4IDE4OjAxLCBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKSB3cm90ZToNCg0KICAg ICAgICBEZWFyIGFsbCwNCiAgICAgICAgSSB3YXMgYXNrZWQgdG8gcmV2aWV3IHRoaXMgZHJhZnQg d2hpY2ggaXMgaW50ZW5kZWQgdG8gYmUgaGFuZGxlZA0KICAgICAgICBpbiB0aGUNCg0KICAgICAg ICBJbmRlcGVuZGVudCBTdHJlYW0uIEJlbG93IGFyZSBteSBjb21tZW50cyB0byB0aGUgYXV0aG9y cy4NCg0KDQogICAgICAgIE1lbWJlcnMgb2YgdGhpcyBsaXN0IGNhbiBhbHNvIHByb3ZpZGUgY29t bWVudHMgdG8gdGhlIGF1dGhvcnMuDQogICAgICAgIFBsZWFzZQ0KICAgICAgICBjb3B5IHRoZQ0K DQogICAgICAgIEluZGVwZW5kZW50IFN1Ym1pc3Npb24gRWRpdG9yaWFsIEJvYXJkIGF0IHRoZSBm b2xsb3dpbmcgYWRkcmVzczoNCg0KICAgICAgICByZmMtaXNlQHJmYy1lZGl0b3Iub3JnPG1haWx0 bzpyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPiA8bWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmc8 bWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmc+Pg0KICAgICAgICA8bWFpbHRvOnJmYy1pc2VA cmZjLWVkaXRvci5vcmc8bWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmc+IDxtYWlsdG86cmZj LWlzZUByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWlzZUByZmMtZWRpdG9yLm9yZz4+Pg0KDQoN Cg0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICBNdXN0YXBoYS4NCiAgICAgICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxDQoNCiAgICAgICAgMS4gT3ZlcmFsbCBjb21t ZW50Og0KICAgICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYSBndWFyYW50ZWVkIGJh bmR3aWR0aCBzZXJ2aWNlIGNhbg0KICAgICAgICBiZSBkZXBsb3llZA0KDQogICAgICAgIGluIGEg TVBMUyBuZXR3b3JrIGJ5IHBhcnRpdGlvbmluZyB0aGUgbmV0d29yayByZXNvdXJjZXMgaW50byB0 d28NCiAgICAgICAgbWFuYWdlZA0KICAgICAgICBsYXllcnMsDQogICAgICAgIHJlZmVycmVkIHRv IGFzIHN0cmF0YS4gVGhlICBndWFyYW50ZWVkIHNlcnZpY2UgbGF5ZXIgaXMgcmVmZXJyZWQNCiAg ICAgICAgdG8gYXMNCiAgICAgICAgIkhhcmQgUGlwZSINCiAgICAgICAgc3RyYXR1bS4NCg0KDQog ICAgICAgIFRoZSBtYW5hZ2VtZW50IG9mIHRoZSByZXNvdXJjZXMgYW5kIHRoZSBwbGFjZW1lbnQg b2YgdGhlIE1QTFMNCiAgICAgICAgdHVubmVscyBhbmQNCg0KICAgICAgICBzZXJ2aWNlcyBpbnRv IHRoZSAgIkhhcmQgUGlwZSIgc3RyYXR1bSBhcmUgcGVyZm9ybWVkIHdpdGggYQ0KICAgICAgICBt YW5hZ2VtZW50DQogICAgICAgIHN5c3RlbS4NCiAgICAgICAgVGh1cyB0aGUgdHJhbnNwb3J0IGFu ZCBzZXJ2aWNlIGxhYmVscyBhcmUgc3RhdGljIGJ1dCB0aGlzIGltcG9ydGFudA0KICAgICAgICBp bmZvcm1hdGlvbiBoYXMNCiAgICAgICAgbm90IGJlZW4gc3RhdGVkIHVwZnJvbnQgaW4gdGhlIGRv Y3VtZW50Lg0KDQogICAgICAgIERvIHlvdSBoYXZlIGEgYSBkZWZpbml0aW9uIG9mICJzdGF0aWMg bGFiZWxzIiB0aGF0IHdlIGNhbiByZWZlciB0bz8NCg0KICAgICAgICAvTG9hDQogICAgICAgIE9u bHkgaW4gc2VjdGlvbiA2IHRoYXQgTVBMUy1UUCB3YXMgbWVudGlvbmVkLiBGdXJ0aGVybW9yZSwg dGhlDQogICAgICAgIHJlZmVyZW5jZQ0KICAgICAgICB0byBULQ0KICAgICAgICBMRFAgc2lnbmFs ZWQgbGFiZWxzIGluIFNlY3Rpb24gMyBhZGRzIHRvIHRoZSBjb25mdXNpb24uDQoNCiAgICAgICAg ICAgICBJIHByb3Bvc2UgdGhhdCB0aGUgSW50cm9kdWN0aW9uIGFuZCBTY29wZSBzZWN0aW9ucyBi ZQ0KICAgICAgICBleHBsaWNpdCBhYm91dCB0aGUNCg0KICAgICAgICBmcmFtZXdvcmsgdXNlZCB0 byBhY2hpZXZlIHRoZSAiSGFyZCBQaXBlIiBzdHJhdHVtLCB0aGF0IGlzIGJ5DQogICAgICAgIG1l YW5zIG9mIGENCiAgICAgICAgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIHN0YXRpYyB0cmFuc3BvcnQg YW5kIHNlcnZpY2UgbGFiZWxzLg0KDQoNCiAgICAgICAgSW4gZmFjdCwgSSB3b3VsZCB0aGluayB0 aGUgZG9jdW1lbnQgdmFsdWUgd291bGQgYmUgaW4gZGVzY3JpYmluZw0KICAgICAgICBtb3JlDQog ICAgICAgIGRldGFpbHMgb2YNCg0KICAgICAgICB0aGUgZnJhbWV3b3JrIGluY2x1ZGluZyBjb25m aWd1cmF0aW9uIGFzcGVjdHMsIHJlc291cmNlIGFuZCBzZXJ2aWNlDQogICAgICAgIG1hbmFnZW1l bnQNCiAgICAgICAgaW5jbHVkaW5nIHJlc2lsaWVuY2UuIFRoZXNlIGFzcGVjdHMgaGF2ZSBub3Qg YmVlbiBzdWZmaWNpZW50bHkNCiAgICAgICAgYWRkcmVzc2VkDQogICAgICAgIGFuZCB0aGUNCiAg ICAgICAgZm9jdXMgd2FzIG1vcmUgb24gaG93IHRvIHVzZSBNUExTIGxhYmVscyB0byBkaWZmZXJl bnRpYXRlIHRoZQ0KICAgICAgICB0d28gc3RyYXRhLg0KDQoNCiAgICAgICAgMi4gU2VjdGlvbiAx LjEgLSBTY29wZToNCiAgICAgICAgQXMgcGFydCBvZiB0aGUgc2Vjb25kIGJ1bGxldCwgSSBjYW5u b3QgZmluZCBpbiB0aGUgZG9jdW1lbnQgaG93DQogICAgICAgIGEgcm91dGVyDQogICAgICAgIHBy b3RlY3RzDQoNCiAgICAgICAgdGhlIHRyYWZmaWMgb2YgdGhlICJIYXJkIFBpcGUiIHN0cmF0dW0g aWYgdGhlICJOb3JtYWwgSVAvTVBMUyINCiAgICAgICAgc3RyYXR1bQ0KICAgICAgICBvdmVyYm9v a3MgYQ0KICAgICAgICBsaW5rLiBIYXZpbmcgYSBzZXBhcmF0ZSBsYWJlbCBmb3IgdGhlIGd1YXJh bnRlZWQgc2VydmljZSBpcyBub3QNCiAgICAgICAgc3VmZmljaWVudC4gVGhlDQogICAgICAgIGF1 dGhvcnMgc2hvdWxkIGRlc2NyaWJlIGlmIExTUCBwcmUtZW1wdGlvbiBhbmQvb3IgUW9TIG1hcmtp bmdzDQogICAgICAgIGFyZSB1c2VkIHRvDQogICAgICAgIGRpZmZlcmVudGlhdGUgdGhlIHRyZWF0 bWVudCBhY3Jvc3MgdGhlIHN0cmF0YS4NCg0KDQogICAgICAgIDMuIFNlY3Rpb24gMzoNCiAgICAg ICAgSWYgdGhlIGRvY3VtZW50IG9iamVjdGl2ZSBpcyB0byBkZXNjcmliZSB0aGUgZnJhbWV3b3Jr IHVzZWQsDQogICAgICAgIHRoZW4gdGhpcw0KICAgICAgICBzZWN0aW9uDQoNCiAgICAgICAgc2hv dWxkIGJlZ2luIGJ5IGV4cGxhaW5pbmcgdGhlIGluaXRpYWwgY29uZmlndXJhdGlvbiBwZXJmb3Jt ZWQNCiAgICAgICAgYnkgdGhlDQogICAgICAgIE5NUyB0byBsYXkNCiAgICAgICAgdGhlIGdyb3Vu ZCBmb3IgdGhlIGJ1aWxkaW5nIG9mIHRoZSB0d28gc3RyYXR1bXMuIFRoaXMgaW5jbHVkZXMgdGhl DQogICAgICAgIHBhcnRpdGlvbmluZyBvZiB0aGUNCiAgICAgICAgbGlua3MsIHRoZSBhc3NpZ25t ZW50IG9mIHRyYW5zcG9ydCBhbmQgc2VydmljZSBsYWJlbCByYW5nZXMgaW4gdGhlDQogICAgICAg IHJvdXRlcnMsIHRoZQ0KICAgICAgICBvdmVyYm9va2luZyBzdHJhdGVneSwgZXRjLg0KDQoNCiAg ICAgICAgVGhlbiwgeW91IGNhbiBkaXNjdXNzIGhvdyBhIGd1YXJhbnRlZWQgc2VydmljZSBpcyBj b25maWd1cmVkIGluDQogICAgICAgIHRoZSBuZXR3b3JrDQoNCiAgICAgICAgdXNpbmcgc3RhdGlj IHRyYW5zcG9ydCBsYWJlbHMgYW5kIHN0YXRpYyBzZXJ2aWNlIGxhYmVscy4gVGhpcyBzaG91bGQN CiAgICAgICAgY292ZXIgdGhlDQogICAgICAgIHBsYWNlbWVudCBvZiB0aGUgd29ya2luZyBhbmQg YmFja3VwIHBhdGhzIHNpbmNlIFNlY3Rpb24gNg0KICAgICAgICBtZW50aW9ucyBNUExTLVRQDQog ICAgICAgIHByb3RlY3Rpb24gaXMgdXNlZC4NCg0KDQogICAgICAgIE5leHQsIGEgZGVzY3JpcHRp b24gb2YgaG93IHRoZSB0cmFuc3BvcnQgTFNQIGFuZCBzZXJ2aWNlIGFyZQ0KICAgICAgICBtb25p dG9yZWQgZm9yDQoNCiAgICAgICAgY29udGludWl0eSBhbmQgZGVmZWN0cy4NCg0KDQogICAgICAg IEZpbmFsbHksIHRoZSBiZWhhdmlvciB3aGVuIHJlc291cmNlcyBhcmUgb3ZlcmJvb2tlZCBhbmQg d2hhdA0KICAgICAgICBzZXJ2aWNlcw0KICAgICAgICBhcmUgcHJlLQ0KDQogICAgICAgIGVtcHRl ZCBvciBkZWdyYWRlZCBzaG91bGQgYmUgZGVzY3JpYmVkLg0KDQogICAgICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgIG1wbHMgbWFpbGluZyBsaXN0DQog ICAgICAgIG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IDxtYWlsdG86bXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+IDxtYWlsdG86bXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4NCiAgICAgICAgPG1haWx0bzptcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPj4+DQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KDQoNCiAgICAgICAgLS0NCg0KDQogICAgICAgIExvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDoNCiAgICAgICAgbG9hQG1haWwwMS5odWF3ZWkuY29t PG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+IDxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWku Y29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+Pg0KICAgICAgICA8bWFpbHRvOmxvYUBt YWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPiA8bWFpbHRvOmxv YUBtYWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPj4+DQogICAg ICAgIFNlbmlvciBNUExTIEV4cGVydCBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4gPG1haWx0 bzpsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+DQogICAgICAgIDxtYWlsdG86bG9hQHBpLm51 PG1haWx0bzpsb2FAcGkubnU+IDxtYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+Pj4N CiAgICAgICAgSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCiAgICAgICAgPHRl bDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCiAgICAgICAgPHRlbDolMkI0NiUyMDczOSUy MDgxJTIwMjElMjA2ND4NCg0KDQogICAgICAgIC0tDQoNCg0KICAgICAgICBMb2EgQW5kZXJzc29u ICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6DQogICAgICAgIGxvYUBtYWlsMDEuaHVhd2Vp LmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPiA8bWFpbHRvOmxvYUBtYWlsMDEuaHVh d2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPj4NCiAgICAgICAgPG1haWx0bzps b2FAbWFpbDAxLmh1YXdlaS5jb208bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbT4gPG1haWx0 bzpsb2FAbWFpbDAxLmh1YXdlaS5jb208bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbT4+Pg0K ICAgICAgICBTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+IDxt YWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+Pg0KICAgICAgICA8bWFpbHRvOmxvYUBw aS5udTxtYWlsdG86bG9hQHBpLm51PiA8bWFpbHRvOmxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51 Pj4+DQogICAgICAgIEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTog KzQ2IDczOSA4MSAyMSA2NDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQ+DQogICAgICAg IDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQ+DQogICAgICAgIDx0ZWw6JTJCNDYlMjA3 MzklMjA4MSUyMDIxJTIwNjQ+DQoNCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgbXBscyBtYWlsaW5nIGxpc3QNCiAgICAgICAg bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4gPG1haWx0bzptcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPj4gPG1haWx0bzptcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KICAgICAgICA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+Pj4NCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQoNCg0KICAgIC0tDQoNCg0KICAgIExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAg ICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdl aS5jb20+DQogICAgPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb208bWFpbHRvOmxvYUBtYWls MDEuaHVhd2VpLmNvbT4+DQogICAgU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5udTxtYWlsdG86 bG9hQHBpLm51PiA8bWFpbHRvOmxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4NCiAgICBIdWF3 ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQ8 dGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0Pg0KICAgIDx0ZWw6JTJCNDYlMjA3MzklMjA4 MSUyMDIxJTIwNjQ+DQoNCg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1 YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxv YUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFu dCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjEl MjA2ND4NCg0K --_000_4A79394211F1AF4EB57D998426C9340D94835E1FUS70UWXCHMBA01z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHkgYW5kIExvYSw8YnI+DQpJIGFtIGdv b2QgZWl0aGVyIHdheS4gPGJyPg0KPGJyPg0KTXVzdGFwaGEuIDxicj4NClNlbnQgZnJvbSBteSBC bGFja2JlcnJ5ITwvZm9udD48YnI+DQombmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGI+RnJvbTwvYj46IEFuZHJldyBHLiBN YWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDwvYj46IFNhdHVy ZGF5LCBNYXkgMDIsIDIwMTUgMDk6NTQgQU08YnI+DQo8Yj5UbzwvYj46IExvYSBBbmRlcnNzb24g Jmx0O2xvYUBwaS5udSZndDsgPGJyPg0KPGI+Q2M8L2I+OiBBaXNzYW91aSwgTXVzdGFwaGEgKE11 c3RhcGhhKTsgbXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs7IE5ldmlsIEJyb3du bGVlICZsdDtyZmMtaXNlQHJmYy1lZGl0b3Iub3JnJmd0Ow0KPGJyPg0KPGI+U3ViamVjdDwvYj46 IFJlOiBbbXBsc10gUmV2aWV3IG9mIGRyYWZ0LWhhby1tcGxzLWlwLWhhcmQtcGlwZS0wMSA8YnI+ DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5Mb2EsDQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5TdXJlLCB0aGF0IHdvcmtzIGZvciBtZSB0b28uIEEgZ29vZCB3b3Jk IHRvIHVzZSBpbnN0ZWFkIG9mICZxdW90O2luc3RhbGxlZCZxdW90OyBpcyAmcXVvdDtwcm92aXNp b25lZCZxdW90Oy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4N CjxkaXY+QW5keTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFNhdCwgTWF5IDIsIDIwMTUgYXQgNDo0OSBBTSwg TG9hIEFuZGVyc3NvbiA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBw aS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+ DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkFuZHksPGJy Pg0KPGJyPg0KU28geW91IHNheSB0aGF0IGV2ZW4gdGhvdWdoIHRoZSBsYWJlbHMgaW4gZHJhZnQt aGFvLW1wbHMtaXAtaGFyZC1waXBlPGJyPg0KYXJlIGR5bmFtaWNhbGx5IGFsbG9jYXRlZCB3ZSBz aG91bGQgY2FsbCB0aGVtICZxdW90O3N0YXRpYyZxdW90OywgYmVjYXVzZSB0aGF0IGlzPGJyPg0K aG93IHdlIGRlZmluZWQgdGhlbSBmb3IgTVBMUy1UUC48YnI+DQo8YnI+DQpDb3VsZCB5b3UgYWNj ZXB0IHRoZSB0ZXJtaW5vbG9neSB0aGF0IE11c3RhcGhhIGFuZCBJIHNlZW1zIHRvIGJlPGJyPg0K Y29udmVyZ2luZyBvbjo8YnI+DQo8YnI+DQpDb25maWd1cmVkIGxhYmVscyAtIGxhYmVscyB0aGF0 IGFyZSBhc3NpZ25lZCBhbmQgcmVjbGFpbWVkIGJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nv bmZpZ3VyYXRpb24uPGJyPg0KPGJyPg0KSSB0aGluayBJIHByZWZlciB0aGF0IHdlIGNhaG5nZSAm cXVvdDthc3NpZ25lZCZxdW90OyBmb3IgJnF1b3Q7aW5zdGFsbGVkJnF1b3Q7LCBidXQgZm9yIG5v dzxicj4NCnRoYXQgaXMgbm90IGltcG9ydGFudC48YnI+DQo8YnI+DQovTG9hPHNwYW4gY2xhc3M9 IiI+PGJyPg0KPGJyPg0KT24gMjAxNS0wNS0wMSAxNTozNiwgQW5kcmV3IEcuIE1hbGlzIHdyb3Rl Ojxicj4NCjwvc3Bhbj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPg0KPHNwYW4gY2xhc3M9IiI+TG9hLDxicj4NCjxicj4NClRob3NlIGFyZSBleGFjdGx5ICZx dW90O3N0YXRpYyZxdW90OyBsYWJlbHMgYXMgd2UndmUgZGVmaW5lZCB0aGVtIGZvciBNUExTLVRQ LCBhczxicj4NCnRoZXkgYXJlbid0IGJlaW5nIGluc3RhbGxlZCBieSBhIGR5bmFtaWMgY29udHJv bCBwbGFuZSBvbiB0aGUgcm91dGVyczxicj4NCihMRFAgb3IgUlNWUC1URSkuIFNlZSB0aGUgdGV4 dCBpbiBzZWN0aW9uIDMuMTEgb2YgUkZDIDU5MjE6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBB IFBXIG9yIExTUCBtYXkgYmUgc3RhdGljYWxseSBjb25maWd1cmVkIHdpdGhvdXQgdGhlIHN1cHBv cnQgb2YgYTxicj4NCiZuYnNwOyAmbmJzcDsgZHluYW1pYyBjb250cm9sIHBsYW5lLiZuYnNwOyBU aGlzIG1heSBiZSBlaXRoZXIgYnkgZGlyZWN0IGNvbmZpZ3VyYXRpb24gb2Y8YnI+DQombmJzcDsg Jm5ic3A7IHRoZSBQRXMvTFNScyBvciB2aWEgYSBuZXR3b3JrIG1hbmFnZW1lbnQgc3lzdGVtLjxi cj4NCjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpBbmR5PGJyPg0KPGJyPg0KPGJyPg0KT24gRnJp LCBNYXkgMSwgMjAxNSBhdCA2OjU4IEFNLCBMb2EgQW5kZXJzc29uICZsdDs8YSBocmVmPSJtYWls dG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPjxicj4NCjwvc3Bhbj4N CjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bG9hQHBp Lm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgTXVzdGFwaGEgYW5kIEFuZHksPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBJZiB3ZSBhcmUgdGFsa2luZyBhYm91dCBtYW51YWwgY29uZmlndXJlIChtYW51YWxseSBp bnN0YWxsZWQgbGFiZWxzKSw8YnI+DQombmJzcDsgJm5ic3A7IHRoaXMgaXMgbm90IHdoYXQgaXMg bm90IHdoYXQgaXMgZ29pbmcgb24gaW4gdGhlIGhhcmQtcGlwZSBuZXR3b3JrLjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgSXQgaXMgb2YgY291cnNlIHBvc3NpYmxlIHRvIHJ1biBhbnkgTVBMUyBu ZXR3b3JrIHdpdGggYWxsIG9yIGEgc3Vic2V0PGJyPg0KJm5ic3A7ICZuYnNwOyBvZiB0aGUgbGFi ZWxzIG1hbnVhbGx5IGluc3RhbGxlZC4gV2UgZGlkIHRoYXQgaW4gMTk5OSB3aGVubSBJIHdvcmtl ZDxicj4NCiZuYnNwOyAmbmJzcDsgd2l0aCBhIFN3ZWRpc2ggb3BlcmF0b3IuIEF3YWl0aW5nIHRl c3RzIGFuZCBkZWNpc2lvbiBvbiB0aGUgbWl4IG9mPGJyPg0KJm5ic3A7ICZuYnNwOyBzaWduYWxs aW5nIHByb3RvY29scyB3ZSBmb3Igc2V2ZXJhbCBtb250aHMgZGlkIHJ1biBvdXIgbmV0d29yayBi eTxicj4NCiZuYnNwOyAmbmJzcDsgaW5zdGFsbGluZyBhbGwgbGFiZWxzIG1hbnVhbGx5LCB3ZSBu ZXZlciB0aG91Z2h0IGFib3V0IHRoYXQgYXMgJnF1b3Q7c3RhdGljJnF1b3Q7LDxicj4NCiZuYnNw OyAmbmJzcDsgYnV0IEkgY291bGQgbGl2ZSB3aXRoIHRoYXQgdGVybWlub2xvZ3kgaWYgd2Ugd2Fu dCB0byB1c2UgaXQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBXaGF0IGlzIGdvaW5nIG9uIGlu IHRoZSBoYXJkLXBpcGUgbmV0d29yayBpcyBhIGJpdCBkaWZmZXJlbnQuIFRoZSBOTVM8YnI+DQom bmJzcDsgJm5ic3A7IChjZW50cmFsaXplZCBjb250cm9sbGVyKSBpcyBjb25maWd1cmVkIHdpdGgg YSBsYWJlbCBzcGFjZSBwZXIgbm9kZSB0bzxicj4NCiZuYnNwOyAmbmJzcDsgYmUgdXNlZCBmb3Ig dGhlIGhhcmQtcGlwZSBzdHJhdHVtLiBUaGUgTk1TIHRoZW4gYWxsb2NhdGUgbGFiZWxzIHRvIGJl PGJyPg0KJm5ic3A7ICZuYnNwOyBpbnN0YWxsZWQgb24gdGhlIG5vZGVzIGFzIGEgTFNQIGlzIHJl cXVlc3RlZCBhbmQgcmVtb3ZlIHRoZW0gYW5kIHJldHVybnM8YnI+DQombmJzcDsgJm5ic3A7IHRo ZW0gdG8gdGhlIHBvb2wgd2hlbiB0aGUgTFNQIGlzIHRha2VuIGRvd24uPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyBJIHRlbmQgdG8gdGhpbmsgYWJvdXQgdGhpcyBhcyBkeW5hbWljIGNvbmZpZ3Vy ZWQgbGFiZWxzLiBEeW5hbWljIGFzPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGV5IGFyZSBpbnN0YWxs ZWQgYW5kIHJlbW92ZWQgZGVwZW5kaW5nIG9uIHRoZSBsaWZlIHRpbWUgb2YgdGhlIExTUHMuPGJy Pg0KJm5ic3A7ICZuYnNwOyBDb25maWd1cmVkIGFzIGl0IGlzIGRvbmUgYnkgdGhlIE5NUy48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7IE11c3RhcGhhLDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg V291bGQgJnF1b3Q7Y29uZmlndXJlZCBsYWJlbHMmcXVvdDsgY292ZXIgdGhlIGNvbmNlcm5zIHlv dSBoYXZlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgL0xvYTxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgT24gMjAxNS0wNC0zMCAxNTo0MiwgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkg d3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoYW5rcyBBbmR5 IGZvciB0aGUgcmVmZXJlbmNlLiBJbmRlZWQsIEkgd2FzIHJlZmVycmluZyB0bzxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhc3NpZ25tZW50IG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGluaXRpYWwgbGFiZWwgYW5kIG9mIGFueSBzdWJzZXF1ZW50IGxhYmVsIGNo YW5nZSBvZiBhbiBMU1Agb3IgYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQVyBi eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25maWd1cmF0aW9uLiBUaGlzIGlz IHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyDigJxtYW51YWzigJ08YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgY29uZmlndXJhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBhbmQgdGhlIExTUCBvciBQVyBpcyByZWZlcnJlZCB0byBhcyBzdGF0aWMuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoYXQgZGVmaW5pdGlvbiBmaXRzIEkgYmVs aWV2ZSB3aGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBkcmFmdC1oYW8tbXBscy1pcC1oYXJkLXBpcGUtMDEgYnV0IExvYSBjYW4gY29uZmly bS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUmVnYXJkcyw8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTXVzdGFwaGEuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICpGcm9tOipBbmRyZXcgRy4gTWFsaXMgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hZ21hbGlz QGdtYWlsLmNvbTwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hZ21h bGlzQGdtYWlsLmNvbTwvYT4mZ3Q7XTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAq U2VudDoqIFRodXJzZGF5LCBBcHJpbCAzMCwgMjAxNSA4OjUyIEFNPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICpUbzoqIExvYSBBbmRlcnNzb248YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgKkNjOiogQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7IDxhIGhyZWY9 Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzQGlldGYub3JnPC9h Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNA aWV0Zi5vcmc8L2E+Jmd0OzsgTmV2aWwgQnJvd25sZWU8c3BhbiBjbGFzcz0iIj48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKlN1YmplY3Q6KiBSZTogW21wbHNdIFJldmlldyBvZiBk cmFmdC1oYW8tbXBscy1pcC1oYXJkLXBpcGUtMDE8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgTG9hLDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJ IHRoaW5rIHRoZSByZWZlcmVuY2UgdGhhdCB5b3UncmUgbG9va2luZyBmb3IgaXMgc2VjdGlvbiAz LjExIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJGQyA1OTIxLjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDaGVlcnMsPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFuZHk8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgT24gVGh1LCBBcHIgMzAsIDIwMTUgYXQgMzo0MSBBTSwgTG9hIEFuZGVyc3NvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwv YT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiZndDs8YnI+DQo8 L3NwYW4+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5s b2FAcGkubnU8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0 PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4mZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE11c3RhcGhhLDxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBUaGF0IGlzIHN0aWxsIG5vdCBhIGRlZmluaXRpb24gcG9zc2libGUg dG8gcmVmcmVuY2UuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEkndmUg YWx3YXlzIGJlZW4gYSBiaXQgY29uZnVzZWQgYnkgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW48YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3RhdGljJnF1b3Q7IGFuZDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtkeW5hbWljJnF1b3Q7LCBlc3BlY2lh bGx5IHdoZW4gaXQgY29tZXMgdG8gbGFiZWxzLCBhIGJpdCBsZXNzIHNvIGlmPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdlIHRhbGs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgYWJvdXQgTFNQcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg VG8gbWUgdGhlIHRlcm0mbmJzcDsgJnF1b3Q7c3RhdGljJnF1b3Q7IGFuZCAmcXVvdDtkeW5hbWlj JnF1b3Q7IHNlZW1zIHRvIGluZGljYXRlIGhvdzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBsb25nIGxpdmVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG9yIGhvdyBl YXN5IHRoZXkgYXJlIHRvIGNoYW5nZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgSWYgYW4gTk1TIG9yIGFueSBjZW50cmFsaXplZCBjb250cm9sbGVyIGluc3RhbCBhbmQg cmVtb3ZlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IExTUHMvbGFiZWxzPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpdGggdGhlIHNhbWUgZnJlcXVlbmN5IGFzIGUu Zy4gTERQIGFyZSB0aGV5IHN0aWxsICZxdW90O3N0YXRpYyZxdW90Oz88YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSBhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgcG9zc2libGUg Y2xhc3NpZmljYXRpb24gb2YgJnF1b3Q7Y29uZmlndXJlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBMU1BzL2xhYmVscyZxdW90OyB2cy4gJnF1b3Q7c2lnbmFsZWQgTFNQcy9sYWJl bHMmcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluIHRoYXQg dGVybWlub2xvZ3kgSSdkIHNheSB0aGF0IGRyYWZ0LWhhby1tcGxzLWlwLWhhcmQtcGlwZSB1c2Vz PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbmZpZ3VyZWQgbGFiZWxzLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXb3VsZCB0aGF0IHRlcm1pbm9sb2d5 IGJlIGFjY2VwdGFibGUgZm9yIHlvdT88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgL0xvYTxicj4NCjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBPbiAyMDE1LTA0LTI5IDE5OjI2LCBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKSB3 cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSGkgTG9hLDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCeSBzdGF0aWMgbGFiZWwsIEkgbWVhbnQgYSBs YWJlbCB3aGljaCBpcyBhc3NpZ25lZCB0byBhIExTUCBvciBhPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFBXIGJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbmZp Z3VyYXRpb24gYW5kIG5vdCBieSBhIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wuIEkgYmVsaWV2ZSB0 aGlzIGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdoYXQgaXMgYmVpbmcgZGVz Y3JpYmVkIGluIHRoaXMgZHJhZnQgYnV0IGxldCBtZSBrbm93IGlmIEkgYW0gd3JvbmcuPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJlZ2FyZHMsPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IE11c3RhcGhhLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0 OyZndDtdPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMjksIDIwMTUgMzoyMSBBTTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBU bzogQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7IDxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzQGlldGYub3JnPC9hPjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8c3BhbiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNA aWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+Jmd0 OyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2M6IE5ldmlsIEJyb3dubGVl PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YmplY3Q6IFJlOiBbbXBsc10gUmV2 aWV3IG9mIGRyYWZ0LWhhby1tcGxzLWlwLWhhcmQtcGlwZS0wMTxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBNdXN0YXBoYSw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgaW4gbGluZSBwbGVhc2UuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IE9uIDIwMTUtMDQtMjggMTg6MDEsIEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFw aGEpIHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEZWFyIGFs bCw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSB3YXMgYXNrZWQgdG8gcmV2aWV3 IHRoaXMgZHJhZnQgd2hpY2ggaXMgaW50ZW5kZWQgdG8gYmUgaGFuZGxlZDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBpbiB0aGU8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgSW5kZXBlbmRlbnQgU3RyZWFtLiBCZWxvdyBhcmUgbXkgY29tbWVudHMgdG8gdGhl IGF1dGhvcnMuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1l bWJlcnMgb2YgdGhpcyBsaXN0IGNhbiBhbHNvIHByb3ZpZGUgY29tbWVudHMgdG8gdGhlIGF1dGhv cnMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBsZWFzZTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBjb3B5IHRoZTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBJbmRlcGVuZGVudCBTdWJtaXNzaW9uIEVkaXRvcmlhbCBCb2FyZCBhdCB0aGUg Zm9sbG93aW5nIGFkZHJlc3M6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Im1haWx0bzpyZmMtaXNlQHJmYy1lZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cmZjLWlzZUByZmMtZWRpdG9yLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cmZj LWlzZUByZmMtZWRpdG9yLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJmYy1pc2VAcmZjLWVkaXRvci5v cmc8L2E+Jmd0Ozxicj4NCjwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86cmZjLWlzZUByZmMtZWRpdG9yLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJmYy1pc2VAcmZjLWVkaXRvci5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnJmYy1pc2VAcmZjLWVkaXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5yZmMtaXNlQHJmYy1lZGl0 b3Iub3JnPC9hPiZndDsmZ3Q7DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPjxicj4NCjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSZWdhcmRzLDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBNdXN0YXBoYS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFvLW1w bHMtaXAtaGFyZC1waXBlLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxPC9hPjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxLiBPdmVyYWxsIGNvbW1lbnQ6PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBhIGd1YXJh bnRlZWQgYmFuZHdpZHRoIHNlcnZpY2UgY2FuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGJlIGRlcGxveWVkPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlu IGEgTVBMUyBuZXR3b3JrIGJ5IHBhcnRpdGlvbmluZyB0aGUgbmV0d29yayByZXNvdXJjZXMgaW50 byB0d288YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWFuYWdlZDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsYXllcnMsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHJlZmVycmVkIHRvIGFzIHN0cmF0YS4gVGhlJm5ic3A7IGd1YXJhbnRlZWQgc2Vydmlj ZSBsYXllciBpcyByZWZlcnJlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byBh czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtIYXJkIFBpcGUmcXVvdDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3RyYXR1bS48YnI+DQo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIG1hbmFnZW1lbnQgb2YgdGhlIHJlc291 cmNlcyBhbmQgdGhlIHBsYWNlbWVudCBvZiB0aGUgTVBMUzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB0dW5uZWxzIGFuZDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBzZXJ2aWNlcyBpbnRvIHRoZSZuYnNwOyAmcXVvdDtIYXJkIFBpcGUmcXVvdDsgc3RyYXR1 bSBhcmUgcGVyZm9ybWVkIHdpdGggYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBt YW5hZ2VtZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHN5c3RlbS48YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGh1cyB0aGUgdHJhbnNwb3J0IGFuZCBzZXJ2aWNl IGxhYmVscyBhcmUgc3RhdGljIGJ1dCB0aGlzIGltcG9ydGFudDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBpbmZvcm1hdGlvbiBoYXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgbm90IGJlZW4gc3RhdGVkIHVwZnJvbnQgaW4gdGhlIGRvY3VtZW50Ljxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEbyB5b3UgaGF2ZSBhIGEgZGVmaW5pdGlvbiBv ZiAmcXVvdDtzdGF0aWMgbGFiZWxzJnF1b3Q7IHRoYXQgd2UgY2FuIHJlZmVyIHRvPzxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvTG9hPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IE9ubHkgaW4gc2VjdGlvbiA2IHRoYXQgTVBMUy1UUCB3YXMgbWVudGlvbmVk LiBGdXJ0aGVybW9yZSwgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlZmVy ZW5jZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byBULTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBMRFAgc2lnbmFsZWQgbGFiZWxzIGluIFNlY3Rpb24gMyBhZGRz IHRvIHRoZSBjb25mdXNpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7SSBwcm9wb3NlIHRoYXQgdGhlIEludHJvZHVjdGlvbiBhbmQg U2NvcGUgc2VjdGlvbnMgYmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZXhwbGlj aXQgYWJvdXQgdGhlPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZyYW1l d29yayB1c2VkIHRvIGFjaGlldmUgdGhlICZxdW90O0hhcmQgUGlwZSZxdW90OyBzdHJhdHVtLCB0 aGF0IGlzIGJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lYW5zIG9mIGE8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIHN0YXRp YyB0cmFuc3BvcnQgYW5kIHNlcnZpY2UgbGFiZWxzLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBJbiBmYWN0LCBJIHdvdWxkIHRoaW5rIHRoZSBkb2N1bWVudCB2 YWx1ZSB3b3VsZCBiZSBpbiBkZXNjcmliaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IG1vcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGV0YWlscyBvZjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgZnJhbWV3b3JrIGluY2x1ZGlu ZyBjb25maWd1cmF0aW9uIGFzcGVjdHMsIHJlc291cmNlIGFuZCBzZXJ2aWNlPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hbmFnZW1lbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgaW5jbHVkaW5nIHJlc2lsaWVuY2UuIFRoZXNlIGFzcGVjdHMgaGF2ZSBub3QgYmVl biBzdWZmaWNpZW50bHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWRkcmVzc2Vk PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFuZCB0aGU8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgZm9jdXMgd2FzIG1vcmUgb24gaG93IHRvIHVzZSBNUExTIGxhYmVs cyB0byBkaWZmZXJlbnRpYXRlIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0 d28gc3RyYXRhLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAy LiBTZWN0aW9uIDEuMSAtIFNjb3BlOjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBB cyBwYXJ0IG9mIHRoZSBzZWNvbmQgYnVsbGV0LCBJIGNhbm5vdCBmaW5kIGluIHRoZSBkb2N1bWVu dCBob3c8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYSByb3V0ZXI8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJvdGVjdHM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgdGhlIHRyYWZmaWMgb2YgdGhlICZxdW90O0hhcmQgUGlwZSZxdW90OyBz dHJhdHVtIGlmIHRoZSAmcXVvdDtOb3JtYWwgSVAvTVBMUyZxdW90Ozxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBzdHJhdHVtPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IG92ZXJib29rcyBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxpbmsuIEhhdmlu ZyBhIHNlcGFyYXRlIGxhYmVsIGZvciB0aGUgZ3VhcmFudGVlZCBzZXJ2aWNlIGlzIG5vdDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdWZmaWNpZW50LiBUaGU8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYXV0aG9ycyBzaG91bGQgZGVzY3JpYmUgaWYgTFNQIHByZS1l bXB0aW9uIGFuZC9vciBRb1MgbWFya2luZ3M8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgYXJlIHVzZWQgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlmZmVyZW50 aWF0ZSB0aGUgdHJlYXRtZW50IGFjcm9zcyB0aGUgc3RyYXRhLjxicj4NCjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAzLiBTZWN0aW9uIDM6PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IElmIHRoZSBkb2N1bWVudCBvYmplY3RpdmUgaXMgdG8gZGVzY3JpYmUg dGhlIGZyYW1ld29yayB1c2VkLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGVu IHRoaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VjdGlvbjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaG91bGQgYmVnaW4gYnkgZXhwbGFpbmluZyB0 aGUgaW5pdGlhbCBjb25maWd1cmF0aW9uIHBlcmZvcm1lZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBieSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTk1TIHRv IGxheTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgZ3JvdW5kIGZvciB0aGUg YnVpbGRpbmcgb2YgdGhlIHR3byBzdHJhdHVtcy4gVGhpcyBpbmNsdWRlcyB0aGU8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGFydGl0aW9uaW5nIG9mIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBsaW5rcywgdGhlIGFzc2lnbm1lbnQgb2YgdHJhbnNwb3J0IGFu ZCBzZXJ2aWNlIGxhYmVsIHJhbmdlcyBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgcm91dGVycywgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG92ZXJi b29raW5nIHN0cmF0ZWd5LCBldGMuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFRoZW4sIHlvdSBjYW4gZGlzY3VzcyBob3cgYSBndWFyYW50ZWVkIHNlcnZpY2Ug aXMgY29uZmlndXJlZCBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgbmV0 d29yazxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1c2luZyBzdGF0aWMg dHJhbnNwb3J0IGxhYmVscyBhbmQgc3RhdGljIHNlcnZpY2UgbGFiZWxzLiBUaGlzIHNob3VsZDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb3ZlciB0aGU8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgcGxhY2VtZW50IG9mIHRoZSB3b3JraW5nIGFuZCBiYWNrdXAgcGF0 aHMgc2luY2UgU2VjdGlvbiA2PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lbnRp b25zIE1QTFMtVFA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJvdGVjdGlvbiBp cyB1c2VkLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBOZXh0 LCBhIGRlc2NyaXB0aW9uIG9mIGhvdyB0aGUgdHJhbnNwb3J0IExTUCBhbmQgc2VydmljZSBhcmU8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbW9uaXRvcmVkIGZvcjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb250aW51aXR5IGFuZCBkZWZlY3RzLjxicj4N Cjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaW5hbGx5LCB0aGUgYmVo YXZpb3Igd2hlbiByZXNvdXJjZXMgYXJlIG92ZXJib29rZWQgYW5kIHdoYXQ8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VydmljZXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgYXJlIHByZS08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1w dGVkIG9yIGRlZ3JhZGVkIHNob3VsZCBiZSBkZXNjcmliZWQuPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBtcGxzIG1haWxpbmcgbGlzdDxicj4NCjwvZGl2Pg0KPC9kaXY+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5tcGxzQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYu b3JnPC9hPjxzcGFuIGNsYXNzPSIiPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8 L2E+PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tPGJyPg0K PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IExvYSBBbmRlcnNzb24mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9hQG1haWwwMS5odWF3ZWku Y29tPC9hPiZndDs8YnI+DQo8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9hQG1haWwwMS5odWF3ZWku Y29tPC9hPiZndDsmZ3Q7PHNwYW4gY2xhc3M9IiI+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFNlbmlvciBNUExTIEV4cGVydCA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJn ZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsb2FA cGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0Ozxicj4NCjwvc3Bhbj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bG9hQHBp Lm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyZndDs8c3Bh biBjbGFzcz0iIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBocmVmPSJ0 ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHZhbHVlPSImIzQzOzQ2NzM5ODEyMTY0IiB0 YXJnZXQ9Il9ibGFuayI+DQomIzQzOzQ2IDczOSA4MSAyMSA2NDwvYT48YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJmx0O3RlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2NCZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3RlbDolMkI0NiUyMDczOSUyMDgx JTIwMjElMjA2NCZndDs8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgLS08YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTG9hIEFu ZGVyc3NvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVtYWlsOjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5sb2FAbWFp bDAxLmh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5sb2FAbWFp bDAxLmh1YXdlaS5jb208L2E+Jmd0OyZndDs8c3BhbiBjbGFzcz0iIj48YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgU2VuaW9yIE1QTFMgRXhwZXJ0IDxhIGhyZWY9Im1haWx0bzpsb2FA cGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4mZ3Q7PGJyPg0K PC9zcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4m Z3Q7Jmd0OzxzcGFuIGNsYXNzPSIiPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBI dWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6 IDxhIGhyZWY9InRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2NCIgdmFsdWU9IiYjNDM7NDY3 Mzk4MTIxNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYgNzM5IDgxIDIxIDY0PC9hPjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7dGVsOiUyQjQ2JTIwNzM5JTIwODElMjAy MSUyMDY0Jmd0Ozxicj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0O3RlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2NCZndDs8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbXBs cyBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxh IGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpt cGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFz cz0iIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+ Jmd0OyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4NCjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgLS08YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IExvYSBB bmRlcnNzb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRv OmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5odWF3 ZWkuY29tPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9hQG1haWwwMS5odWF3ZWku Y29tPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7IFNlbmlvciBNUExTIEV4cGVydCA8YSBocmVm PSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8 L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFu dCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4 MSUyMDIxJTIwNjQiIHZhbHVlPSImIzQzOzQ2NzM5ODEyMTY0IiB0YXJnZXQ9Il9ibGFuayI+DQom IzQzOzQ2IDczOSA4MSAyMSA2NDwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZsdDt0ZWw6JTJCNDYl MjA3MzklMjA4MSUyMDIxJTIwNjQmZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjwvYmxvY2tx dW90ZT4NCjxzcGFuIGNsYXNzPSJpbSBIT0VuWmIiPjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4N CkxvYSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0i bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWww MS5odWF3ZWkuY29tPC9hPjxicj4NCjwvc3Bhbj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8ZGl2 IGNsYXNzPSJoNSI+U2VuaW9yIE1QTFMgRXhwZXJ0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj4NCmxvYUBw aS5udTwvYT48YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSZuYnNwOyAmbmJz cDsgJm5ic3A7cGhvbmU6IDxhIGhyZWY9InRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2NCIg dmFsdWU9IiYjNDM7NDY3Mzk4MTIxNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYgNzM5IDgx IDIxIDY0PC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi cj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A79394211F1AF4EB57D998426C9340D94835E1FUS70UWXCHMBA01z_-- From nobody Sat May 2 13:13:09 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC5B1A8FD3; Sat, 2 May 2015 13:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6-m-z0uUeb6V; Sat, 2 May 2015 13:13:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DAD1A8F4C; Sat, 2 May 2015 13:13:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150502201306.22361.67140.idtracker@ietfa.amsl.com> Date: Sat, 02 May 2015 13:13:06 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 20:13:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-mirsky-mpls-residence-time-06.txt Pages : 23 Date : 2015-05-02 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mirsky-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-mirsky-mpls-residence-time-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mirsky-mpls-residence-time-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 2 23:42:35 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8F1A013B for ; Sat, 2 May 2015 23:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nX07nCvuJ31C for ; Sat, 2 May 2015 23:42:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729171A0130 for ; Sat, 2 May 2015 23:42:29 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2113C18013E6; Sun, 3 May 2015 08:42:27 +0200 (CEST) Message-ID: <5545C354.8000204@pi.nu> Date: Sun, 03 May 2015 08:42:28 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Andrew G. Malis" References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu> <55448F85.5050803@pi.nu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 06:42:33 -0000 Andy, Tnx - I have a question about "provisioned". I think "provisioning" is the activity both to install and remove labels, right? Does "provisioned" mean both also, or just install? /Loa On 2015-05-02 15:54, Andrew G. Malis wrote: > Loa, > > Sure, that works for me too. A good word to use instead of "installed" > is "provisioned". > > Cheers, > Andy > > On Sat, May 2, 2015 at 4:49 AM, Loa Andersson > wrote: > > Andy, > > So you say that even though the labels in draft-hao-mpls-ip-hard-pipe > are dynamically allocated we should call them "static", because that is > how we defined them for MPLS-TP. > > Could you accept the terminology that Mustapha and I seems to be > converging on: > > Configured labels - labels that are assigned and reclaimed by > configuration. > > I think I prefer that we cahnge "assigned" for "installed", but for now > that is not important. > > /Loa > > On 2015-05-01 15:36, Andrew G. Malis wrote: > > Loa, > > Those are exactly "static" labels as we've defined them for > MPLS-TP, as > they aren't being installed by a dynamic control plane on the > routers > (LDP or RSVP-TE). See the text in section 3.11 of RFC 5921: > > A PW or LSP may be statically configured without the > support of a > dynamic control plane. This may be either by direct > configuration of > the PEs/LSRs or via a network management system. > > > Cheers, > Andy > > > On Fri, May 1, 2015 at 6:58 AM, Loa Andersson > >> wrote: > > Mustapha and Andy, > > If we are talking about manual configure (manually > installed labels), > this is not what is not what is going on in the hard-pipe > network. > > It is of course possible to run any MPLS network with all > or a subset > of the labels manually installed. We did that in 1999 whenm > I worked > with a Swedish operator. Awaiting tests and decision on the > mix of > signalling protocols we for several months did run our > network by > installing all labels manually, we never thought about that > as "static", > but I could live with that terminology if we want to use it. > > What is going on in the hard-pipe network is a bit > different. The NMS > (centralized controller) is configured with a label space > per node to > be used for the hard-pipe stratum. The NMS then allocate > labels to be > installed on the nodes as a LSP is requested and remove > them and returns > them to the pool when the LSP is taken down. > > I tend to think about this as dynamic configured labels. > Dynamic as > they are installed and removed depending on the life time > of the LSPs. > Configured as it is done by the NMS. > > Mustapha, > > Would "configured labels" cover the concerns you have. > > /Loa > > On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote: > > Thanks Andy for the reference. Indeed, I was referring to > assignment of > initial label and of any subsequent label change of an > LSP or a > PW by > configuration. This is sometimes referred to as “manual” > configuration > and the LSP or PW is referred to as static. > > That definition fits I believe what is being described in > draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm. > > Regards, > > Mustapha. > > *From:*Andrew G. Malis [mailto:agmalis@gmail.com > > >] > *Sent:* Thursday, April 30, 2015 8:52 AM > *To:* Loa Andersson > *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > >; Nevil > Brownlee > *Subject:* Re: [mpls] Review of > draft-hao-mpls-ip-hard-pipe-01 > > Loa, > > I think the reference that you're looking for is > section 3.11 of > RFC 5921. > > Cheers, > > Andy > > On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson > > > > >>> wrote: > > Mustapha, > > That is still not a definition possible to refrence. > > I've always been a bit confused by the distinction between > "static" and > "dynamic", especially when it comes to labels, a bit > less so if > we talk > about LSPs. > > To me the term "static" and "dynamic" seems to > indicate how > long lived > or how easy they are to change. > > If an NMS or any centralized controller instal and remove > LSPs/labels > with the same frequency as e.g. LDP are they still > "static"? > > I agree that there is a possible classification of > "configured > LSPs/labels" vs. "signaled LSPs/labels". > > In that terminology I'd say that > draft-hao-mpls-ip-hard-pipe uses > configured labels. > > Would that terminology be acceptable for you? > > /Loa > > > > On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote: > > Hi Loa, > By static label, I meant a label which is assigned to a > LSP or a > PW by > configuration and not by a control plane protocol. I > believe this is > what is being described in this draft but let me know > if I am wrong. > > Regards, > Mustapha. > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu > > > >>] > Sent: Wednesday, April 29, 2015 3:21 AM > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > > > >> > Cc: Nevil Brownlee > Subject: Re: [mpls] Review of > draft-hao-mpls-ip-hard-pipe-01 > > Mustapha, > > in line please. > > On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: > > Dear all, > I was asked to review this draft which is intended to > be handled > in the > > Independent Stream. Below are my comments to the authors. > > > Members of this list can also provide comments to the > authors. > Please > copy the > > Independent Submission Editorial Board at the following > address: > > rfc-ise@rfc-editor.org > > > >> > > > > Regards, > Mustapha. > ---------------------------- > https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 > > 1. Overall comment: > This document describes how a guaranteed bandwidth > service can > be deployed > > in a MPLS network by partitioning the network resources > into two > managed > layers, > referred to as strata. The guaranteed service layer is > referred > to as > "Hard Pipe" > stratum. > > > The management of the resources and the placement of > the MPLS > tunnels and > > services into the "Hard Pipe" stratum are performed with a > management > system. > Thus the transport and service labels are static but > this important > information has > not been stated upfront in the document. > > Do you have a a definition of "static labels" that we > can refer to? > > /Loa > Only in section 6 that MPLS-TP was mentioned. > Furthermore, the > reference > to T- > LDP signaled labels in Section 3 adds to the confusion. > > I propose that the Introduction and Scope sections be > explicit about the > > framework used to achieve the "Hard Pipe" stratum, that > is by > means of a > management system and static transport and service labels. > > > In fact, I would think the document value would be in > describing > more > details of > > the framework including configuration aspects, resource > and service > management > including resilience. These aspects have not been > sufficiently > addressed > and the > focus was more on how to use MPLS labels to > differentiate the > two strata. > > > 2. Section 1.1 - Scope: > As part of the second bullet, I cannot find in the > document how > a router > protects > > the traffic of the "Hard Pipe" stratum if the "Normal > IP/MPLS" > stratum > overbooks a > link. Having a separate label for the guaranteed > service is not > sufficient. The > authors should describe if LSP pre-emption and/or QoS > markings > are used to > differentiate the treatment across the strata. > > > 3. Section 3: > If the document objective is to describe the framework > used, > then this > section > > should begin by explaining the initial configuration > performed > by the > NMS to lay > the ground for the building of the two stratums. This > includes the > partitioning of the > links, the assignment of transport and service label > ranges in the > routers, the > overbooking strategy, etc. > > > Then, you can discuss how a guaranteed service is > configured in > the network > > using static transport labels and static service > labels. This should > cover the > placement of the working and backup paths since Section 6 > mentions MPLS-TP > protection is used. > > > Next, a description of how the transport LSP and > service are > monitored for > > continuity and defects. > > > Finally, the behavior when resources are overbooked and > what > services > are pre- > > empted or degraded should be described. > > ------------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > >> > Senior MPLS Expert loa@pi.nu > > > >> > Huawei Technologies (consultant) phone: +46 739 81 > 21 64 > > > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > >> > Senior MPLS Expert loa@pi.nu > > > >> > Huawei Technologies (consultant) phone: +46 739 81 > 21 64 > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu > > > Huawei Technologies (consultant) phone: +46 739 81 21 > 64 > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun May 3 07:00:38 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6391E1A1B25 for ; Sun, 3 May 2015 07:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 gsGN4CnEEOzt for ; Sun, 3 May 2015 07:00:31 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 065D61A1B24 for ; Sun, 3 May 2015 07:00:31 -0700 (PDT) Received: by wief7 with SMTP id f7so60420865wie.0 for ; Sun, 03 May 2015 07:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3MFnekiYITAK44aKmrkFyNIn9TXONLqqptMWYkcSvtM=; b=l6m2rj0jjfGsZT1ThtXuxxQRDLZRrtUtawkU7KFdOYwnI2zgZ9yaQ2Ug1Wsme8qsVB DO4FejkwusP/RL0jvihlW16STlYtHGolXEDuUKzAr/12u//pfsF2yhJoJ0YEIJkLswH0 cm6UvS4Ds0dsSbhvorJ/8pFscEmE0Th7uc3o5c9P9Em7dRdmg6pi9cvVuN5VzkHQpMSF EyejlC+sCKvVc3q1FljRYFdKtxwZ0Hjdy3IWDglQ0rIjlGS13JI85E/736kUVI8O7e1K oXibobgzCCPA4pbqlbZzcuEv6E0NKEsBi4QXOJqxh8gshiSY5/GxvTdgrUNbM3ahdPLA jPkQ== X-Received: by 10.180.101.3 with SMTP id fc3mr11792350wib.47.1430661627680; Sun, 03 May 2015 07:00:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.182.215 with HTTP; Sun, 3 May 2015 07:00:06 -0700 (PDT) In-Reply-To: <5545C354.8000204@pi.nu> References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu> <55448F85.5050803@pi.nu> <5545C354.8000204@pi.nu> From: "Andrew G. Malis" Date: Sun, 3 May 2015 10:00:06 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=f46d0444ec5f1c9be805152ddec0 Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 14:00:37 -0000 --f46d0444ec5f1c9be805152ddec0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Loa, It's both, basically any change to the network equipment from an NMS. Not much difference from "configured" or "installed", but to me the latter terms are more related to the long-term configuration, such as installing or removing interfaces, while provisioning is more short-term. Cheers, Andy On Sun, May 3, 2015 at 2:42 AM, Loa Andersson wrote: > Andy, > > Tnx - I have a question about "provisioned". I think "provisioning" is > the activity both to install and remove labels, right? > > Does "provisioned" mean both also, or just install? > > /Loa > > On 2015-05-02 15:54, Andrew G. Malis wrote: > >> Loa, >> >> Sure, that works for me too. A good word to use instead of "installed" >> is "provisioned". >> >> Cheers, >> Andy >> >> On Sat, May 2, 2015 at 4:49 AM, Loa Andersson > > wrote: >> >> Andy, >> >> So you say that even though the labels in draft-hao-mpls-ip-hard-pip= e >> are dynamically allocated we should call them "static", because that >> is >> how we defined them for MPLS-TP. >> >> Could you accept the terminology that Mustapha and I seems to be >> converging on: >> >> Configured labels - labels that are assigned and reclaimed by >> configuration. >> >> I think I prefer that we cahnge "assigned" for "installed", but for >> now >> that is not important. >> >> /Loa >> >> On 2015-05-01 15:36, Andrew G. Malis wrote: >> >> Loa, >> >> Those are exactly "static" labels as we've defined them for >> MPLS-TP, as >> they aren't being installed by a dynamic control plane on the >> routers >> (LDP or RSVP-TE). See the text in section 3.11 of RFC 5921: >> >> A PW or LSP may be statically configured without the >> support of a >> dynamic control plane. This may be either by direct >> configuration of >> the PEs/LSRs or via a network management system. >> >> >> Cheers, >> Andy >> >> >> On Fri, May 1, 2015 at 6:58 AM, Loa Andersson > >> >> wrote: >> >> Mustapha and Andy, >> >> If we are talking about manual configure (manually >> installed labels), >> this is not what is not what is going on in the hard-pipe >> network. >> >> It is of course possible to run any MPLS network with all >> or a subset >> of the labels manually installed. We did that in 1999 whenm >> I worked >> with a Swedish operator. Awaiting tests and decision on the >> mix of >> signalling protocols we for several months did run our >> network by >> installing all labels manually, we never thought about that >> as "static", >> but I could live with that terminology if we want to use it= . >> >> What is going on in the hard-pipe network is a bit >> different. The NMS >> (centralized controller) is configured with a label space >> per node to >> be used for the hard-pipe stratum. The NMS then allocate >> labels to be >> installed on the nodes as a LSP is requested and remove >> them and returns >> them to the pool when the LSP is taken down. >> >> I tend to think about this as dynamic configured labels. >> Dynamic as >> they are installed and removed depending on the life time >> of the LSPs. >> Configured as it is done by the NMS. >> >> Mustapha, >> >> Would "configured labels" cover the concerns you have. >> >> /Loa >> >> On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote: >> >> Thanks Andy for the reference. Indeed, I was referring = to >> assignment of >> initial label and of any subsequent label change of an >> LSP or a >> PW by >> configuration. This is sometimes referred to as =E2=80= =9Cmanual=E2=80=9D >> configuration >> and the LSP or PW is referred to as static. >> >> That definition fits I believe what is being described = in >> draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm. >> >> Regards, >> >> Mustapha. >> >> *From:*Andrew G. Malis [mailto:agmalis@gmail.com >> >> >] >> *Sent:* Thursday, April 30, 2015 8:52 AM >> *To:* Loa Andersson >> *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> >> >; Nevil >> Brownlee >> *Subject:* Re: [mpls] Review of >> draft-hao-mpls-ip-hard-pipe-01 >> >> Loa, >> >> I think the reference that you're looking for is >> section 3.11 of >> RFC 5921. >> >> Cheers, >> >> Andy >> >> On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson >> >> > >> > >>> wrote: >> >> Mustapha, >> >> That is still not a definition possible to refrence. >> >> I've always been a bit confused by the distinction >> between >> "static" and >> "dynamic", especially when it comes to labels, a bit >> less so if >> we talk >> about LSPs. >> >> To me the term "static" and "dynamic" seems to >> indicate how >> long lived >> or how easy they are to change. >> >> If an NMS or any centralized controller instal and remo= ve >> LSPs/labels >> with the same frequency as e.g. LDP are they still >> "static"? >> >> I agree that there is a possible classification of >> "configured >> LSPs/labels" vs. "signaled LSPs/labels". >> >> In that terminology I'd say that >> draft-hao-mpls-ip-hard-pipe uses >> configured labels. >> >> Would that terminology be acceptable for you? >> >> /Loa >> >> >> >> On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrot= e: >> >> Hi Loa, >> By static label, I meant a label which is assigned to a >> LSP or a >> PW by >> configuration and not by a control plane protocol. I >> believe this is >> what is being described in this draft but let me know >> if I am wrong. >> >> Regards, >> Mustapha. >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu >> > >> > >>] >> Sent: Wednesday, April 29, 2015 3:21 AM >> To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> >> > >> >> >> >> Cc: Nevil Brownlee >> Subject: Re: [mpls] Review of >> draft-hao-mpls-ip-hard-pipe-01 >> >> Mustapha, >> >> in line please. >> >> On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrot= e: >> >> Dear all, >> I was asked to review this draft which is intended to >> be handled >> in the >> >> Independent Stream. Below are my comments to the author= s. >> >> >> Members of this list can also provide comments to the >> authors. >> Please >> copy the >> >> Independent Submission Editorial Board at the following >> address: >> >> rfc-ise@rfc-editor.org >> > >> > > >> >> >> >> >> Regards, >> Mustapha. >> ---------------------------- >> https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 >> >> 1. Overall comment: >> This document describes how a guaranteed bandwidth >> service can >> be deployed >> >> in a MPLS network by partitioning the network resources >> into two >> managed >> layers, >> referred to as strata. The guaranteed service layer is >> referred >> to as >> "Hard Pipe" >> stratum. >> >> >> The management of the resources and the placement of >> the MPLS >> tunnels and >> >> services into the "Hard Pipe" stratum are performed >> with a >> management >> system. >> Thus the transport and service labels are static but >> this important >> information has >> not been stated upfront in the document. >> >> Do you have a a definition of "static labels" that we >> can refer to? >> >> /Loa >> Only in section 6 that MPLS-TP was mentioned. >> Furthermore, the >> reference >> to T- >> LDP signaled labels in Section 3 adds to the confusion. >> >> I propose that the Introduction and Scope sections >> be >> explicit about the >> >> framework used to achieve the "Hard Pipe" stratum, that >> is by >> means of a >> management system and static transport and service >> labels. >> >> >> In fact, I would think the document value would be in >> describing >> more >> details of >> >> the framework including configuration aspects, resource >> and service >> management >> including resilience. These aspects have not been >> sufficiently >> addressed >> and the >> focus was more on how to use MPLS labels to >> differentiate the >> two strata. >> >> >> 2. Section 1.1 - Scope: >> As part of the second bullet, I cannot find in the >> document how >> a router >> protects >> >> the traffic of the "Hard Pipe" stratum if the "Normal >> IP/MPLS" >> stratum >> overbooks a >> link. Having a separate label for the guaranteed >> service is not >> sufficient. The >> authors should describe if LSP pre-emption and/or QoS >> markings >> are used to >> differentiate the treatment across the strata. >> >> >> 3. Section 3: >> If the document objective is to describe the framework >> used, >> then this >> section >> >> should begin by explaining the initial configuration >> performed >> by the >> NMS to lay >> the ground for the building of the two stratums. This >> includes the >> partitioning of the >> links, the assignment of transport and service label >> ranges in the >> routers, the >> overbooking strategy, etc. >> >> >> Then, you can discuss how a guaranteed service is >> configured in >> the network >> >> using static transport labels and static service >> labels. This should >> cover the >> placement of the working and backup paths since Section= 6 >> mentions MPLS-TP >> protection is used. >> >> >> Next, a description of how the transport LSP and >> service are >> monitored for >> >> continuity and defects. >> >> >> Finally, the behavior when resources are overbooked and >> what >> services >> are pre- >> >> empted or degraded should be described. >> >> ------------------------------------ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org > > > mpls@ietf.org> >> >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> -- >> >> >> Loa Andersson email: >> loa@mail01.huawei.com >> > >> > > >> >> Senior MPLS Expert loa@pi.nu >> > >> > >> >> Huawei Technologies (consultant) phone: +46 739 81 >> 21 64 >> >> >> >> >> -- >> >> >> Loa Andersson email: >> loa@mail01.huawei.com >> > >> > > >> >> Senior MPLS Expert loa@pi.nu >> > >> > >> >> Huawei Technologies (consultant) phone: +46 739 81 >> 21 64 >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org > > > mpls@ietf.org> >> >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> -- >> >> >> Loa Andersson email: >> loa@mail01.huawei.com >> > >> >> Senior MPLS Expert loa@pi.nu >> > >> Huawei Technologies (consultant) phone: +46 739 81 21 >> 64 >> >> >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --f46d0444ec5f1c9be805152ddec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

It's both, basically any chang= e to the network equipment from an NMS. Not much difference from "conf= igured" or "installed", but to me the latter terms are more = related to the long-term configuration, such as installing or removing inte= rfaces, while provisioning is more short-term.

Che= ers,
Andy

On Sun, May 3, 2015 at 2:42 AM, Loa Andersson <loa@pi.nu> wrote:
Andy,

Tnx - I have a question about "provisioned". I think "provis= ioning" is
the activity both to install and remove labels, right?

Does "provisioned" mean both also, or just install?

/Loa

On 2015-05-02 15:54, Andrew G. Malis wrote:
Loa,

Sure, that works for me too. A good word to use instead of "installed&= quot;
is "provisioned".

Cheers,
Andy

On Sat, May 2, 2015 at 4:49 AM, Loa Andersson <loa@pi.nu
<mailto:loa@pi.nu>= > wrote:

=C2=A0 =C2=A0 Andy,

=C2=A0 =C2=A0 So you say that even though the labels in draft-hao-mpls-ip-h= ard-pipe
=C2=A0 =C2=A0 are dynamically allocated we should call them "static&qu= ot;, because that is
=C2=A0 =C2=A0 how we defined them for MPLS-TP.

=C2=A0 =C2=A0 Could you accept the terminology that Mustapha and I seems to= be
=C2=A0 =C2=A0 converging on:

=C2=A0 =C2=A0 Configured labels - labels that are assigned and reclaimed by=
=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 configuration.

=C2=A0 =C2=A0 I think I prefer that we cahnge "assigned" for &quo= t;installed", but for now
=C2=A0 =C2=A0 that is not important.

=C2=A0 =C2=A0 /Loa

=C2=A0 =C2=A0 On 2015-05-01 15:36, Andrew G. Malis wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Loa,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Those are exactly "static" labels as = we've defined them for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS-TP, as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 they aren't being installed by a dynamic co= ntrol plane on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 routers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (LDP or RSVP-TE). See the text in section 3.11 = of RFC 5921:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A PW or LSP may be statical= ly configured without the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 support of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dynamic control plane.=C2= =A0 This may be either by direct
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the PEs/LSRs or via a netwo= rk management system.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy


=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Fri, May 1, 2015 at 6:58 AM, Loa Andersson &= lt;loa@pi.nu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mustapha and Andy,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If we are talking about man= ual configure (manually
=C2=A0 =C2=A0 =C2=A0 =C2=A0 installed labels),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this is not what is not wha= t is going on in the hard-pipe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 network.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is of course possible to= run any MPLS network with all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or a subset
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the labels manually inst= alled. We did that in 1999 whenm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I worked
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with a Swedish operator. Aw= aiting tests and decision on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mix of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signalling protocols we for= several months did run our
=C2=A0 =C2=A0 =C2=A0 =C2=A0 network by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0installing all labels manua= lly, we never thought about that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as "static",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but I could live with that = terminology if we want to use it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What is going on in the har= d-pipe network is a bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 different. The NMS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(centralized controller) is= configured with a label space
=C2=A0 =C2=A0 =C2=A0 =C2=A0 per node to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be used for the hard-pipe s= tratum. The NMS then allocate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 labels to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0installed on the nodes as a= LSP is requested and remove
=C2=A0 =C2=A0 =C2=A0 =C2=A0 them and returns
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0them to the pool when the L= SP is taken down.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I tend to think about this = as dynamic configured labels.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Dynamic as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they are installed and remo= ved depending on the life time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the LSPs.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Configured as it is done by= the NMS.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mustapha,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would "configured labe= ls" cover the concerns you have.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/Loa

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 2015-04-30 15:42, Aissao= ui, Mustapha (Mustapha) wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks Andy f= or the reference. Indeed, I was referring to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assignment of=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initial label= and of any subsequent label change of an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LSP or a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PW by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration= . This is sometimes referred to as =E2=80=9Cmanual=E2=80=9D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the LSP o= r PW is referred to as static.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That definiti= on fits I believe what is being described in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hao-mpl= s-ip-hard-pipe-01 but Loa can confirm.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mustapha.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*From:*Andrew= G. Malis [mailto:ag= malis@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:agmalis@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:agmalis@gmail.com = <mailto:agmalis@g= mail.com>>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Sent:* Thurs= day, April 30, 2015 8:52 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*To:* Loa And= ersson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Cc:* Aissaou= i, Mustapha (Mustapha); = mpls@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org <mail= to:mpls@ietf.org>= >; Nevil
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Brownlee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Subject:* Re= : [mpls] Review of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-hao-mpls-ip-hard-pipe-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Loa,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think the r= eference that you're looking for is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 section 3.11 of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5921.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Apr 3= 0, 2015 at 3:41 AM, Loa Andersson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <loa@pi.nu <mailto:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu>>
<= div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu> <mailto:loa@pi.nu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu>>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mustapha,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That is still= not a definition possible to refrence.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I've alwa= ys been a bit confused by the distinction between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"static&= quot; and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"dynamic= ", especially when it comes to labels, a bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 less so if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we talk
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0about LSPs.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To me the ter= m=C2=A0 "static" and "dynamic" seems to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 indicate how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0long lived =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or how easy t= hey are to change.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If an NMS or = any centralized controller instal and remove
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LSPs/labels =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the same= frequency as e.g. LDP are they still
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "static"?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I agree that = there is a possible classification of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "configured
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LSPs/labels&q= uot; vs. "signaled LSPs/labels".

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In that termi= nology I'd say that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-hao-mpls-ip-hard-pipe uses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured la= bels.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would that te= rminology be acceptable for you?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/Loa



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 2015-04-29= 19:26, Aissaoui, Mustapha (Mustapha) wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Loa,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0By static lab= el, I meant a label which is assigned to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LSP or a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PW by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration= and not by a control plane protocol. I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 believe this is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what is being= described in this draft but let me know
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if I am wrong.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mustapha.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----Original= Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: Loa And= ersson [mailto:loa@pi.nu=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu> <mailto:loa@pi.nu <mailto:loa@pi.nu>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu> <mailto:loa@pi.nu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu>>>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: Wednesd= ay, April 29, 2015 3:21 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Aissaoui,= Mustapha (Mustapha); mp= ls@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org <mail= to:mpls@ietf.org>= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org <mailto:mpls@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org <mailto:mpls@ietf.org>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cc: Nevil Bro= wnlee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: Re: = [mpls] Review of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-hao-mpls-ip-hard-pipe-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mustapha,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in line pleas= e.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 2015-04-28= 18:01, Aissaoui, Mustapha (Mustapha) wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear all,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I was asked t= o review this draft which is intended to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be handled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Independent S= tream. Below are my comments to the authors.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Members of th= is list can also provide comments to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authors.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0copy the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Independent S= ubmission Editorial Board at the following
=C2=A0 =C2=A0 =C2=A0 =C2=A0 address:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 rfc-ise@rfc-editor.org <mailto:rfc-ise@rfc-editor.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:rfc-ise@rfc-editor.org <mailto:rfc-ise@rfc-editor.org&g= t;>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:rfc-ise@rfc-edito= r.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:rfc-ise@rfc-editor.org> <mailto:rfc-ise@rfc-editor.org=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:rfc-ise@rfc-editor.org>>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mustapha.
=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 https://tools.ietf.org/html/draft= -hao-mpls-ip-hard-pipe-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Overall co= mment:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document= describes how a guaranteed bandwidth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 service can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be deployed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a MPLS net= work by partitioning the network resources
=C2=A0 =C2=A0 =C2=A0 =C2=A0 into two
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0managed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0referred to a= s strata. The=C2=A0 guaranteed service layer is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 referred
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Hard Pi= pe"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stratum.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The managemen= t of the resources and the placement of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the MPLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tunnels and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services into= the=C2=A0 "Hard Pipe" stratum are performed with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0management =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0system.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thus the tran= sport and service labels are static but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this important
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information h= as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not been stat= ed upfront in the document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Do you have a= a definition of "static labels" that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 can refer to?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/Loa
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Only in secti= on 6 that MPLS-TP was mentioned.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Furthermore, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to T-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LDP signaled = labels in Section 3 adds to the confusion.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 I propose that the Introduction and Scope sections be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0explicit abou= t the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0framework use= d to achieve the "Hard Pipe" stratum, that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0means of a =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0management sy= stem and static transport and service labels.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In fact, I wo= uld think the document value would be in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 describing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0details of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the framework= including configuration aspects, resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0management =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including res= ilience. These aspects have not been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sufficiently
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addressed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0focus was mor= e on how to use MPLS labels to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 differentiate the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0two strata.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Section 1.= 1 - Scope:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As part of th= e second bullet, I cannot find in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 document how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a router
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protects

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the traffic o= f the "Hard Pipe" stratum if the "Normal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IP/MPLS"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stratum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0overbooks a =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0link. Having = a separate label for the guaranteed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 service is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sufficient. T= he
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authors shoul= d describe if LSP pre-emption and/or QoS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 markings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are used to =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0differentiate= the treatment across the strata.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Section 3:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the docume= nt objective is to describe the framework
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0section

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should begin = by explaining the initial configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 performed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NMS to lay =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the ground fo= r the building of the two stratums. This
=C2=A0 =C2=A0 =C2=A0 =C2=A0 includes the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0partitioning = of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0links, the as= signment of transport and service label
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ranges in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0routers, the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0overbooking s= trategy, etc.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Then, you can= discuss how a guaranteed service is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configured in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using static = transport labels and static service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 labels. This should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cover the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0placement of = the working and backup paths since Section 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mentions MPLS= -TP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protection is= used.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Next, a descr= iption of how the transport LSP and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 service are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0monitored for=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continuity an= d defects.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, the = behavior when resources are overbooked and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are pre-

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0empted or deg= raded should be described.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------= -----------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________= __________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mpls mailing = list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org>> <mailto:mpls@ietf.org <mailto:mpls@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org <mail= to:mpls@ietf.org>= >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mpls

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Loa Andersson= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 email:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@mail01.huawei.= com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com> <mailto:loa@mail01.huawei.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Senior MPLS E= xpert loa@pi.nu <mail= to:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu> <mailto:loa@pi.nu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu>>>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Huawei Techno= logies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81
=C2=A0 =C2=A0 =C2=A0 =C2=A0 21 64 <tel:%2B46%20739%2081%2021%2064> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<tel:%2B46= %20739%2081%2021%2064>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<tel:%2B46= %20739%2081%2021%2064>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Loa Andersson= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 email:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>&g= t;
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@mail01.huawei.= com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com> <mailto:loa@mail01.huawei.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Senior MPLS E= xpert loa@pi.nu <mail= to:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu> <mailto:loa@pi.nu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu>>>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Huawei Techno= logies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81
=C2=A0 =C2=A0 =C2=A0 =C2=A0 21 64 <tel:%2B46%20739%2081%2021%2064> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<tel:%2B46= %20739%2081%2021%2064>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<tel:%2B46= %20739%2081%2021%2064>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________= __________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mpls mailing = list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mpls@ietf.org>> <mailto:mpls@ietf.org <mailto:mpls@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org <mail= to:mpls@ietf.org>= >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mpls

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Loa Andersson=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:loa@mail01.huawei.com <ma= ilto:loa@mail01.= huawei.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu <mailto:loa@pi.nu>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Huawei Technologies (consul= tant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 64 <tel:%2B46%20739%2081%2021%2064>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<tel:%2B46%20739%2081%20= 21%2064>



=C2=A0 =C2=A0 --


=C2=A0 =C2=A0 Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
=C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com>
 =C2=A0 =C2=A0 Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
=C2=A0 =C2=A0 Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
=C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>



--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=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 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--f46d0444ec5f1c9be805152ddec0-- From nobody Sun May 3 09:41:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FB1A8720 for ; Sun, 3 May 2015 09:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 uRS2scy67nNb for ; Sun, 3 May 2015 09:41:36 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0BA1A871D for ; Sun, 3 May 2015 09:41:35 -0700 (PDT) Received: by wief7 with SMTP id f7so62127420wie.0 for ; Sun, 03 May 2015 09:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=cbYSdcGMy5vBfy7XYHBO+U+JGcxaEWleUFXARmgzuXY=; b=iGFKRynhSIU+3VC5WTKCZLoU3sQV5/mYAhbOsYKokgoISpe4H8ttaS+wzcfRsYvIM0 AqIS5uLg0XVSC5Rd5+nv64eALVPXvXG4UsCFwSYq3GsDrZCFGJZixMzozJ7LyhZ5iKb2 7R3UZgrRttirCQ/7ELoLi9XBooj0kMKbDY+/JLxAxwXYN2uxAorkTpJvy4apjCJTrceB lNENIfzge3QI60ufA9ZwdMLHndh02wQJzlA2Qnmy1ypA5XH2i842dFHj1r2otyguePWZ ohzCzlIhpKed1BmsU9IFqDYBhOiJzp245jLNdnJj0HIXlaHvo7OF8BcpNxymL7TlV24V nZGg== X-Received: by 10.180.87.101 with SMTP id w5mr12826918wiz.18.1430671294209; Sun, 03 May 2015 09:41:34 -0700 (PDT) Received: from [192.168.2.109] (p57B92295.dip0.t-ipconnect.de. [87.185.34.149]) by mx.google.com with ESMTPSA id vz8sm16703307wjc.27.2015.05.03.09.41.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2015 09:41:33 -0700 (PDT) Message-ID: <55464FBB.9020001@gmail.com> Date: Sun, 03 May 2015 18:41:31 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Andrew G. Malis" , Loa Andersson References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu> <55448F85.5050803@pi.nu> <5545C354.8000204@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 16:41:39 -0000 Hello Andy, You wrote: > It's both, basically any change to the network equipment from an NMS. I agree. > Not much difference from "configured" or "installed", but to me the > latter terms are more related to the long-term configuration, such as > installing or removing interfaces, while provisioning is more short-term. Indeed. A connection or service is provisioned. An interface or hardware unit is installed and/or configured. Best regards, Huub. > On Sun, May 3, 2015 at 2:42 AM, Loa Andersson > wrote: > > Andy, > > Tnx - I have a question about "provisioned". I think "provisioning" is > the activity both to install and remove labels, right? > > Does "provisioned" mean both also, or just install? > > /Loa > > On 2015-05-02 15:54, Andrew G. Malis wrote: > > Loa, > > Sure, that works for me too. A good word to use instead of > "installed" > is "provisioned". > > Cheers, > Andy > > On Sat, May 2, 2015 at 4:49 AM, Loa Andersson > >> wrote: > > Andy, > > So you say that even though the labels in > draft-hao-mpls-ip-hard-pipe > are dynamically allocated we should call them "static", > because that is > how we defined them for MPLS-TP. > > Could you accept the terminology that Mustapha and I seems > to be > converging on: > > Configured labels - labels that are assigned and reclaimed by > configuration. > > I think I prefer that we cahnge "assigned" for "installed", > but for now > that is not important. > > /Loa > > On 2015-05-01 15:36, Andrew G. Malis wrote: > > Loa, > > Those are exactly "static" labels as we've defined them for > MPLS-TP, as > they aren't being installed by a dynamic control plane > on the > routers > (LDP or RSVP-TE). See the text in section 3.11 of RFC 5921: > > A PW or LSP may be statically configured without the > support of a > dynamic control plane. This may be either by direct > configuration of > the PEs/LSRs or via a network management system. > > > Cheers, > Andy > > > On Fri, May 1, 2015 at 6:58 AM, Loa Andersson > > > > >>> wrote: > > Mustapha and Andy, > > If we are talking about manual configure (manually > installed labels), > this is not what is not what is going on in the > hard-pipe > network. > > It is of course possible to run any MPLS network > with all > or a subset > of the labels manually installed. We did that in > 1999 whenm > I worked > with a Swedish operator. Awaiting tests and > decision on the > mix of > signalling protocols we for several months did run our > network by > installing all labels manually, we never thought > about that > as "static", > but I could live with that terminology if we want > to use it. > > What is going on in the hard-pipe network is a bit > different. The NMS > (centralized controller) is configured with a > label space > per node to > be used for the hard-pipe stratum. The NMS then > allocate > labels to be > installed on the nodes as a LSP is requested and > remove > them and returns > them to the pool when the LSP is taken down. > > I tend to think about this as dynamic configured > labels. > Dynamic as > they are installed and removed depending on the > life time > of the LSPs. > Configured as it is done by the NMS. > > Mustapha, > > Would "configured labels" cover the concerns you have. > > /Loa > > On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) > wrote: > > Thanks Andy for the reference. Indeed, I was > referring to > assignment of > initial label and of any subsequent label > change of an > LSP or a > PW by > configuration. This is sometimes referred to > as “manual” > configuration > and the LSP or PW is referred to as static. > > That definition fits I believe what is being > described in > draft-hao-mpls-ip-hard-pipe-01 but Loa can > confirm. > > Regards, > > Mustapha. > > *From:*Andrew G. Malis > [mailto:agmalis@gmail.com > > > >>] > *Sent:* Thursday, April 30, 2015 8:52 AM > *To:* Loa Andersson > *Cc:* Aissaoui, Mustapha (Mustapha); > mpls@ietf.org > > > > >>; Nevil > Brownlee > *Subject:* Re: [mpls] Review of > draft-hao-mpls-ip-hard-pipe-01 > > Loa, > > I think the reference that you're looking for is > section 3.11 of > RFC 5921. > > Cheers, > > Andy > > On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson > > > > >> > > > > >>>> wrote: > > Mustapha, > > That is still not a definition possible to > refrence. > > I've always been a bit confused by the > distinction between > "static" and > "dynamic", especially when it comes to labels, > a bit > less so if > we talk > about LSPs. > > To me the term "static" and "dynamic" seems to > indicate how > long lived > or how easy they are to change. > > If an NMS or any centralized controller instal > and remove > LSPs/labels > with the same frequency as e.g. LDP are they still > "static"? > > I agree that there is a possible classification of > "configured > LSPs/labels" vs. "signaled LSPs/labels". > > In that terminology I'd say that > draft-hao-mpls-ip-hard-pipe uses > configured labels. > > Would that terminology be acceptable for you? > > /Loa > > > > On 2015-04-29 19:26, Aissaoui, Mustapha > (Mustapha) wrote: > > Hi Loa, > By static label, I meant a label which is > assigned to a > LSP or a > PW by > configuration and not by a control plane > protocol. I > believe this is > what is being described in this draft but let > me know > if I am wrong. > > Regards, > Mustapha. > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu > > > >> > > > > >>>] > Sent: Wednesday, April 29, 2015 3:21 AM > To: Aissaoui, Mustapha (Mustapha); > mpls@ietf.org > > > > >> > > > > > >>> > Cc: Nevil Brownlee > Subject: Re: [mpls] Review of > draft-hao-mpls-ip-hard-pipe-01 > > Mustapha, > > in line please. > > On 2015-04-28 18:01, Aissaoui, Mustapha > (Mustapha) wrote: > > Dear all, > I was asked to review this draft which is > intended to > be handled > in the > > Independent Stream. Below are my comments to > the authors. > > > Members of this list can also provide comments > to the > authors. > Please > copy the > > Independent Submission Editorial Board at the > following > address: > > rfc-ise@rfc-editor.org > > > >> > > > > >>> > > > > Regards, > Mustapha. > ---------------------------- > https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 > > 1. Overall comment: > This document describes how a guaranteed bandwidth > service can > be deployed > > in a MPLS network by partitioning the network > resources > into two > managed > layers, > referred to as strata. The guaranteed service > layer is > referred > to as > "Hard Pipe" > stratum. > > > The management of the resources and the > placement of > the MPLS > tunnels and > > services into the "Hard Pipe" stratum are > performed with a > management > system. > Thus the transport and service labels are > static but > this important > information has > not been stated upfront in the document. > > Do you have a a definition of "static labels" > that we > can refer to? > > /Loa > Only in section 6 that MPLS-TP was mentioned. > Furthermore, the > reference > to T- > LDP signaled labels in Section 3 adds to the > confusion. > > I propose that the Introduction and Scope > sections be > explicit about the > > framework used to achieve the "Hard Pipe" > stratum, that > is by > means of a > management system and static transport and > service labels. > > > In fact, I would think the document value > would be in > describing > more > details of > > the framework including configuration aspects, > resource > and service > management > including resilience. These aspects have not been > sufficiently > addressed > and the > focus was more on how to use MPLS labels to > differentiate the > two strata. > > > 2. Section 1.1 - Scope: > As part of the second bullet, I cannot find in the > document how > a router > protects > > the traffic of the "Hard Pipe" stratum if the > "Normal > IP/MPLS" > stratum > overbooks a > link. Having a separate label for the guaranteed > service is not > sufficient. The > authors should describe if LSP pre-emption > and/or QoS > markings > are used to > differentiate the treatment across the strata. > > > 3. Section 3: > If the document objective is to describe the > framework > used, > then this > section > > should begin by explaining the initial > configuration > performed > by the > NMS to lay > the ground for the building of the two > stratums. This > includes the > partitioning of the > links, the assignment of transport and service > label > ranges in the > routers, the > overbooking strategy, etc. > > > Then, you can discuss how a guaranteed service is > configured in > the network > > using static transport labels and static service > labels. This should > cover the > placement of the working and backup paths > since Section 6 > mentions MPLS-TP > protection is used. > > > Next, a description of how the transport LSP and > service are > monitored for > > continuity and defects. > > > Finally, the behavior when resources are > overbooked and > what > services > are pre- > > empted or degraded should be described. > > ------------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > > >> > > > > > >>> > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > >> > > > > >>> > Senior MPLS Expert loa@pi.nu > > > >> > > > > >>> > Huawei Technologies (consultant) phone: > +46 739 81 > 21 64 > > > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > >> > > > > >>> > Senior MPLS Expert loa@pi.nu > > > >> > > > > >>> > Huawei Technologies (consultant) phone: > +46 739 81 > 21 64 > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > > >> > > > > > >>> > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > >> > Senior MPLS Expert loa@pi.nu > > > >> > Huawei Technologies (consultant) phone: +46 > 739 81 21 > 64 > > > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu > > > Huawei Technologies (consultant) phone: +46 739 81 21 > 64 > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobody Sun May 3 23:03:34 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5750B1ACD7B for ; Sun, 3 May 2015 23:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.112 X-Spam-Level: * X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=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 HbKTnr-BEkQA for ; Sun, 3 May 2015 23:03:30 -0700 (PDT) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (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 13C651A92E3 for ; Sun, 3 May 2015 23:03:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=Mark-Tinkas-MacBook.local) by the-host.seacom.mu with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id NNTA5Q-0006PK-ND for mpls@ietf.org; Mon, 04 May 2015 08:03:26 +0200 To: mpls@ietf.org From: Mark Tinka x-enigmail-draft-status: N1110 message-id: <55470BAE.605@seacom.mu> Date: Mon, 4 May 2015 08:03:26 +0200 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 Content-Type: multipart/alternative; boundary="------------090203040902030901060000" Archived-At: Subject: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 06:03:32 -0000 This is a multi-part message in MIME format. --------------090203040902030901060000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello all. Being specific since I am an operator - IOS XR is now shipping LDPv6 capability in 5.3.0. I've been testing this over the weekend, and would just like to clarify whether code with dual-stack LDP support is meant to be backwards compatible with code that only has single-stack LDP support. IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detail here: http://tinyurl.com/mbt5z4l When we enable "address-family ipv6" for LDP in IOS XR, the box is unable to establish any LDP adjacencies. Given the code defaults to setting up adjacencies via IPv6, this makes sense since all the other routers around it do not yet run code that supports LDPv6. However, per the implementation notes from Cisco, they say after 15x seconds of no adjacency formation, the code should fall back to IPv4. I waited 1hr, this never happened. IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried as well. The box seemed to struggle building LDP adjacencies. Adjacencies rise, and then fall in the space of 3x seconds. I think this could be a bug, but just FYI. I'm, obviously, going to take this up with Cisco, but wondering whether IOS XR is in violation of the spec., or if it's just me. Mark. --------------090203040902030901060000 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello all.

Being specific since I am an operator - IOS XR is now shipping LDPv6 capability in 5.3.0.

I've been testing this over the weekend, and would just like to clarify whether code with dual-stack LDP support is meant to be backwards compatible with code that only has single-stack LDP support.

IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detail here:

        http://tinyurl.com/mbt5z4l

When we enable "address-family ipv6" for LDP in IOS XR, the box is unable to establish any LDP adjacencies. Given the code defaults to setting up adjacencies via IPv6, this makes sense since all the other routers around it do not yet run code that supports LDPv6. However, per the implementation notes from Cisco, they say after 15x seconds of no adjacency formation, the code should fall back to IPv4. I waited 1hr, this never happened.

IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried as well. The box seemed to struggle building LDP adjacencies. Adjacencies rise, and then fall in the space of 3x seconds. I think this could be a bug, but just FYI.

I'm, obviously, going to take this up with Cisco, but wondering whether IOS XR is in violation of the spec., or if it's just me.

Mark.
 --------------090203040902030901060000-- From nobody Mon May 4 07:55:23 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C2C1A1B92 for ; Mon, 4 May 2015 07:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ItZOhaFfc_RW for ; Mon, 4 May 2015 07:55:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EC11A1B91 for ; Mon, 4 May 2015 07:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6156; q=dns/txt; s=iport; t=1430751318; x=1431960918; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IU/4usjAqayw0hUz4bYAi9PQqm9OyY5RTJ7zNLQhZTI=; b=J3rZiiqqNjlVZK6idVrlBs7qB6ZfotLujZz7QWV6P2Tt5gyrrG975hNR 6Algb4eqx5WVJNfEvrDvmFZmkZXb0Wa9KedITtRB6frL2Xa5C8M8quR5W oo8wQAi9UyLp1csFL9Tg6SqVAlPIHadik6WLSkAU9uNXbOgajuOtkhDTv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BLBQC5hkdV/5RdJa1cgkVHU1cFBcVgCYFShgkCgSo4FAEBAQEBAQGBCoQgAQEBBHkQAgEIEQMBAigHMhQJCAIEAQ0FiCsIxSwBAQEBAQEBAwEBAQEBAQEBARmLOYR0EQeELQWPYoIrhBGGQYEkPYMVik+DB4NSI2CBJxyBUW8LAYE4gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,366,1427760000"; d="scan'208,217";a="146877653" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP; 04 May 2015 14:55:17 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t44EtHX5019294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 May 2015 14:55:17 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.246]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 4 May 2015 09:55:17 -0500 From: "Kamran Raza (skraza)" To: Mark Tinka , "mpls@ietf.org" Thread-Topic: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR Thread-Index: AQHQhjAZD6/y4clyfUa4ZMNHhzIwB51r+RCA Date: Mon, 4 May 2015 14:55:16 +0000 Message-ID: References: <55470BAE.605@seacom.mu> In-Reply-To: <55470BAE.605@seacom.mu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.86.253.14] Content-Type: multipart/alternative; boundary="_000_D16CFC4F5BAC0skrazaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 14:55:22 -0000 --_000_D16CFC4F5BAC0skrazaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mark, Yes, Cisco XR 5.3.0 dual-stack capable LDP is backward compatible with sing= le-stack LDP. I think when you say =93adjacencies=94, you meant =93session=94 and not =93= hello adjacencies=94. Please confirm. Could you share your topology /cfg etc ? What type of LSRs are XR neighbours ? Cisco ? Release ? Non Cisco ? Did you have reachability for IPv6 [transport] address ? Regarding knob for =93ipv4 transport preference=94: Please make sure that b= oth sides (LSRs) have the same preference otherwise the session will not ge= t established. Rgds, =97 Kamran From: Mark Tinka > Date: Monday, May 4, 2015 at 2:03 AM To: "mpls@ietf.org" > Subject: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS X= R Hello all. Being specific since I am an operator - IOS XR is now shipping LDPv6 capabi= lity in 5.3.0. I've been testing this over the weekend, and would just like to clarify whe= ther code with dual-stack LDP support is meant to be backwards compatible w= ith code that only has single-stack LDP support. IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detai= l here: http://tinyurl.com/mbt5z4l When we enable "address-family ipv6" for LDP in IOS XR, the box is unable t= o establish any LDP adjacencies. Given the code defaults to setting up adja= cencies via IPv6, this makes sense since all the other routers around it do= not yet run code that supports LDPv6. However, per the implementation note= s from Cisco, they say after 15x seconds of no adjacency formation, the cod= e should fall back to IPv4. I waited 1hr, this never happened. IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried= as well. The box seemed to struggle building LDP adjacencies. Adjacencies = rise, and then fall in the space of 3x seconds. I think this could be a bug= , but just FYI. I'm, obviously, going to take this up with Cisco, but wondering whether IOS= XR is in violation of the spec., or if it's just me. Mark. --_000_D16CFC4F5BAC0skrazaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0F9A68DD220B7A48B3B57AC4155D921F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Mark,

Yes, Cisco XR 5.3.0 dual-stack capable LDP is backward compatible with= single-stack LDP.  
I think when you say =93adjacencies=94, you meant =93session=94 and no= t =93hello adjacencies=94.  Please confirm.

Could you share your topology /cfg etc ?  
What type of LSRs are XR neighbours  ? Cisco ? Release ? Non Cisc= o ? 
Did you have reachability for IPv6 [transport] address ? 

Regarding knob for =93ipv4 transport preference=94: Please make sure t= hat both sides (LSRs) have the same preference otherwise the session will n= ot get established.

Rgds,
=97
Kamran

From: Mark Tinka <mark.tinka@seacom.mu>
Date: Monday, May 4, 2015 at 2:03 A= M
To: "mpls@ietf.org" <mpls@i= etf.org>
Subject: [mpls] LDPv6 Behaviour In = Dual Stack Network - Testing Cisco IOS XR

Hello all.

Being specific since I am an operator - IOS XR is now shipping LDPv6 capabi= lity in 5.3.0.

I've been testing this over the weekend, and would just like to clarify whe= ther code with dual-stack LDP support is meant to be backwards compatible w= ith code that only has single-stack LDP support.

IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detai= l here:

        http://tinyurl.com/mbt5z4l

When we enable "address-family ipv6" for LDP in IOS XR, the box i= s unable to establish any LDP adjacencies. Given the code defaults to setti= ng up adjacencies via IPv6, this makes sense since all the other routers ar= ound it do not yet run code that supports LDPv6. However, per the implementation notes from Cisco, they say after 15= x seconds of no adjacency formation, the code should fall back to IPv4. I w= aited 1hr, this never happened.

IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried= as well. The box seemed to struggle building LDP adjacencies. Adjacencies = rise, and then fall in the space of 3x seconds. I think this could be a bug= , but just FYI.

I'm, obviously, going to take this up with Cisco, but wondering whether IOS= XR is in violation of the spec., or if it's just me.

Mark.
 --_000_D16CFC4F5BAC0skrazaciscocom_-- From nobody Mon May 4 12:58:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA10C1B29AA; Mon, 4 May 2015 12:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1Sv6nrB6bbUU; Mon, 4 May 2015 12:58:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 528D71ACF19; Mon, 4 May 2015 12:58:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 61B901E301; Mon, 4 May 2015 19:58:05 +0000 (UTC) Date: Mon, 4 May 2015 15:58:05 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20150504195805.GB25036@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: mpls@ietf.org Subject: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 19:58:02 -0000 The BFD mailing list has been quiet since shortly after IETF 92. We have a number of documents that seem stable and ready to advance. This email begins a two week Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884. This last call will end on May 15. Simultaneously, the authors of this draft should state to the mailing list whether there is any IPR associated with this draft or not. This WGLC is also being cc'd to mpls@ietf to permit additional commentary. -- Jeff and Nobo From nobody Mon May 4 12:59:28 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19E1B29B6; Mon, 4 May 2015 12:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 myXM-hC8whgZ; Mon, 4 May 2015 12:59:23 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C631B29B3; Mon, 4 May 2015 12:59:22 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-df-55476b952c9d Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3D.1A.06409.59B67455; Mon, 4 May 2015 14:52:38 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Mon, 4 May 2015 15:59:09 -0400 From: Gregory Mirsky To: Jeffrey Haas , "rtg-bfd@ietf.org" Thread-Topic: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Index: AQHQhqSk0LBejmytJ0CYBhbjG8O/PZ1sPB8Q Date: Mon, 4 May 2015 19:59:08 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B978BB2@eusaamb103.ericsson.se> References: <20150504195805.GB25036@pfrc.org> In-Reply-To: <20150504195805.GB25036@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPoO60bPdQg9tfGS32H3zLanFr6UpW i89/tjE6MHssWfKTyeNy71bWAKYoLpuU1JzMstQifbsErowDxyULfrBXXFt6nLGB8QBbFyMn h4SAicSOA6vZIWwxiQv31gPFuTiEBI4ySryYuZQZwlnGKNHwfidYFZuAkcSLjT1gtoiAh0T3 seeMXYwcHMwCyhKn7sqAhIUFwiX2/N/AClESIbHrZANYiQhQ6+pPjiBhFgEViRWPLoBN4RXw ldi5bx6YLSSgKzHx1SZmEJtTQE/i7KYXTCA2I9Bt30+tAbOZBcQlbj2ZzwRxs4DEkj3nmSFs UYmXj/+xQthKEpOWnmOFqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ2FlIWmYhaZmF pGUBI8sqRo7S4tSy3HQjw02MwFg5JsHmuINxwSfLQ4wCHIxKPLwKSW6hQqyJZcWVuYcYpTlY lMR5y64cDBESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuEfjV6Lixx3vOjLnZrOw3oxJKeVd nyeeZirVGxzSVWZyrrfh1ndpB9WMOdGvltpcvVQcNjtsttdtZU2lsy/S+7YGvtBdv1w0r3T3 y63ymnNVBJUyZSTXizW/NaqfPC90t6LipdNTU2dNsWSrm8c4/blns8cM9Zl8PjIhD9zqby9o eHcz+Oo/JZbijERDLeai4kQAK2Uzj3YCAAA= Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 19:59:25 -0000 I'm not aware of any IPR related to this document. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, May 04, 2015 12:58 PM To: rtg-bfd@ietf.org Cc: mpls@ietf.org Subject: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarific= ations The BFD mailing list has been quiet since shortly after IETF 92. We have a= number of documents that seem stable and ready to advance. This email begins a two week Working Group Last Call for draft-ietf-bfd-rfc= 5884-clarifications-01, Clarifications to RFC 5884. This last call will end on May 15. Simultaneously, the authors of this draft should state to the mailing list = whether there is any IPR associated with this draft or not. This WGLC is also being cc'd to mpls@ietf to permit additional commentary. -- Jeff and Nobo _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Mon May 4 13:11:40 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014331B29C6 for ; Mon, 4 May 2015 13:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=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 c0xwwoiIeuEy for ; Mon, 4 May 2015 13:11:35 -0700 (PDT) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (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 66DCB1B29C7 for ; Mon, 4 May 2015 13:11:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=Mark-Tinkas-MacBook.local) by the-host.seacom.mu with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id NNUDF2-0007OF-E0; Mon, 04 May 2015 22:11:26 +0200 To: "Kamran Raza (skraza)" , "mpls@ietf.org" references: <55470BAE.605@seacom.mu> From: Mark Tinka x-enigmail-draft-status: N1110 message-id: <5547D26E.3050401@seacom.mu> Date: Mon, 4 May 2015 22:11:26 +0200 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: Content-Type: multipart/alternative; boundary="------------020801090908030901080700" Archived-At: Cc: "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 20:11:38 -0000 This is a multi-part message in MIME format. --------------020801090908030901080700 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kamran. Thanks for your feedback. Yes, I meant the TCP sessions. I opened a TAC case earlier today and provided them all the details. They are checking with the BU as the setup is normal. I'm guessing that because none of the neighbors are LDP dual-stack capable, this could be my issue. In this particular case, the directly attached neighbors are Juniper MX480 routers. As Junos do not currently dual-stack LDP, I'm guessing this could be issue. Which does not make sense to me if LDP in IOS XR 5.3.0 is backward compatible with code (whether from Cisco or another vendor) that is still running "old" LDP. IPv6 reachability between the Cisco and Juniper are fine. Mark. On 4/May/15 16:55, Kamran Raza (skraza) wrote: > Hi Mark, > > Yes, Cisco XR 5.3.0 dual-stack capable LDP is backward compatible with > single-stack LDP. =20 > I think when you say =93adjacencies=94, you meant =93session=94 and not= =93hello > adjacencies=94. Please confirm. > > Could you share your topology /cfg etc ? =20 > What type of LSRs are XR neighbours ? Cisco ? Release ? Non Cisco ?=20 > Did you have reachability for IPv6 [transport] address ?=20 > > Regarding knob for =93ipv4 transport preference=94: Please make sure th= at > both sides (LSRs) have the same preference otherwise the session will > not get established. > > Rgds, > =97 > Kamran > > From: Mark Tinka > > Date: Monday, May 4, 2015 at 2:03 AM > To: "mpls@ietf.org " > > Subject: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco > IOS XR > > Hello all. > > Being specific since I am an operator - IOS XR is now shipping LDPv6 > capability in 5.3.0. > > I've been testing this over the weekend, and would just like to > clarify whether code with dual-stack LDP support is meant to be > backwards compatible with code that only has single-stack LDP support. > > IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good > detail here: > > http://tinyurl.com/mbt5z4l > > When we enable "address-family ipv6" for LDP in IOS XR, the box is > unable to establish any LDP adjacencies. Given the code defaults to > setting up adjacencies via IPv6, this makes sense since all the other > routers around it do not yet run code that supports LDPv6. However, > per the implementation notes from Cisco, they say after 15x seconds of > no adjacency formation, the code should fall back to IPv4. I waited > 1hr, this never happened. > > IOS XR has a knob to force adjacencies to be setup over IPv4, which I > tried as well. The box seemed to struggle building LDP adjacencies. > Adjacencies rise, and then fall in the space of 3x seconds. I think > this could be a bug, but just FYI. > > I'm, obviously, going to take this up with Cisco, but wondering > whether IOS XR is in violation of the spec., or if it's just me. > > Mark. --------------020801090908030901080700 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Kamran.

Thanks for your feedback.

Yes, I meant the TCP sessions.

I opened a TAC case earlier today and provided them all the details. They are checking with the BU as the setup is normal.

I'm guessing that because none of the neighbors are LDP dual-stack capable, this could be my issue. In this particular case, the directly attached neighbors are Juniper MX480 routers. As Junos do not currently dual-stack LDP, I'm guessing this could be issue. Which does not make sense to me if LDP in IOS XR 5.3.0 is backward compatible with code (whether from Cisco or another vendor) that is still running "old" LDP.

IPv6 reachability between the Cisco and Juniper are fine.

Mark.

On 4/May/15 16:55, Kamran Raza (skraza) wrote:
Hi Mark,

Yes, Cisco XR 5.3.0 dual-stack capable LDP is backward compatible with single-stack LDP.
I think when you say adjacencies, you meant session and not hello adjacencies. Please confirm.

Could you share your topology /cfg etc ?
What type of LSRs are XR neighbours ? Cisco ? Release ? Non Cisco ?
Did you have reachability for IPv6 [transport] address ?

Regarding knob for ipv4 transport preference: Please make sure that both sides (LSRs) have the same preference otherwise the session will not get established.

Rgds,
Kamran

From: Mark Tinka <mark.tinka@seacom.mu>
Date: Monday, May 4, 2015 at 2:03 AM
To: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR

Hello all.

Being specific since I am an operator - IOS XR is now shipping LDPv6 capability in 5.3.0.

I've been testing this over the weekend, and would just like to clarify whether code with dual-stack LDP support is meant to be backwards compatible with code that only has single-stack LDP support.

IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detail here:

http://tinyurl.com/mbt5z4l

When we enable "address-family ipv6" for LDP in IOS XR, the box is unable to establish any LDP adjacencies. Given the code defaults to setting up adjacencies via IPv6, this makes sense since all the other routers around it do not yet run code that supports LDPv6. However, per the implementation notes from Cisco, they say after 15x seconds of no adjacency formation, the code should fall back to IPv4. I waited 1hr, this never happened.

IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried as well. The box seemed to struggle building LDP adjacencies. Adjacencies rise, and then fall in the space of 3x seconds. I think this could be a bug, but just FYI.

I'm, obviously, going to take this up with Cisco, but wondering whether IOS XR is in violation of the spec., or if it's just me.

Mark.

--------------020801090908030901080700-- From nobody Mon May 4 19:21:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB72D1B2DA8; Mon, 4 May 2015 19:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 dFuy505fD2BU; Mon, 4 May 2015 19:20:57 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202831B2D9C; Mon, 4 May 2015 19:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=879; q=dns/txt; s=iport; t=1430792457; x=1432002057; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CjsNiwIug3NhoKZLUse+kD7Ek2PdHS7+5ioK3hjfIW0=; b=Yi4xqNxRP9kpHzA4mF1SU2Nr+gBQ9WrjlJF1u8QgG/RXARCiYIMh4yHT 6LAQfX7eucih977sLD9B9ONDe+kaVslrGIs0CB5RpZ5KSorxCdkKXLFiD xApQVnaHPTx14pM7L3adi9NVmRbhlFj4Rl+kSfnwlDlClWAB4pEuoC9sN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBAC5J0hV/51dJa1cgwyBLwXFC2YJh1sCgTQ4FAEBAQEBAQGBCoQgAQEBBB0dNAsMBAIBCA4DBAEBCxQJBzIUCQgCBAENBQiII8ZAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s5hCIRASAxBwaDEYEWAQSSDaBwI4N0b4ELOYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,369,1427760000"; d="scan'208";a="147120429" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 05 May 2015 02:20:56 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t452KufA021761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 02:20:56 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.12]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 4 May 2015 21:20:56 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Index: AQHQhqSvikclWYniz02yMJJ3eYtf8p1snUdA Date: Tue, 5 May 2015 02:20:55 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D54471D50@xmb-rcd-x15.cisco.com> References: <20150504195805.GB25036@pfrc.org> In-Reply-To: <20150504195805.GB25036@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.33.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 02:20:59 -0000 I am not aware of any IPR related to this document. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, May 05, 2015 1:28 AM To: rtg-bfd@ietf.org Cc: mpls@ietf.org Subject: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications The BFD mailing list has been quiet since shortly after IETF 92. We have a= number of documents that seem stable and ready to advance. This email begins a two week Working Group Last Call for draft-ietf-bfd-rfc= 5884-clarifications-01, Clarifications to RFC 5884. This last call will end on May 15. Simultaneously, the authors of this draft should state to the mailing list = whether there is any IPR associated with this draft or not. This WGLC is also being cc'd to mpls@ietf to permit additional commentary. -- Jeff and Nobo From nobody Mon May 4 21:18:39 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52241B2E19 for ; Mon, 4 May 2015 21:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 4z_Gh3SHwYZL for ; Mon, 4 May 2015 21:18:30 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0941B2DB0 for ; Mon, 4 May 2015 21:18:30 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so91131025wic.1 for ; Mon, 04 May 2015 21:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JrsEuzHOfam1au6To/qjKrk1XAXhjWrEhdggI4qMuCI=; b=Zbbo2X90/NFN3SAodZC4vXvQsXP3YXI9Hi7dG0zuH+5WsQiIyPNIgeaaaDR1DT8ec+ Wk8dbBgsATO+dYUo3moLRYO4Uq4RshHeEG0c6M6xzGzwuRy5Mf29GyyXGIcqF660XHJj 2fzoqNh+Bit5OsxqAHWDROqX/8vgoHE9zeKsfOJNWhlCI0LQEzGbYJ9VnJDx4nhMQTCF T/qDKGcrthINnuv6fh9NCjwy0rXXNlC8uXXDOG5IJG6+oUAQPz03Rc/WKTKfnoKNzkwT gMzDABd5yqtjxa9yxbjhWkwdUHfuudF3mwibIaPWk4OP5HrqUnCqgBNIcq/mTvPUtjRM bqlQ== MIME-Version: 1.0 X-Received: by 10.180.160.169 with SMTP id xl9mr192742wib.42.1430799508947; Mon, 04 May 2015 21:18:28 -0700 (PDT) Received: by 10.194.223.1 with HTTP; Mon, 4 May 2015 21:18:28 -0700 (PDT) Received: by 10.194.223.1 with HTTP; Mon, 4 May 2015 21:18:28 -0700 (PDT) In-Reply-To: <55470BAE.605@seacom.mu> References: <55470BAE.605@seacom.mu> Date: Tue, 5 May 2015 00:18:28 -0400 Message-ID: From: Gyan Mishra To: Mark Tinka Content-Type: multipart/alternative; boundary=047d7b624ac279c94005154df8dd Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 04:18:36 -0000 --047d7b624ac279c94005154df8dd Content-Type: text/plain; charset=UTF-8 All With 6PE and 6vPE over IPv4 mpls core what is the business driver for Dual stack especially with BGP Free P core makes the core simple with minimal protocols for high speed forwarding plane. So what is the necessity for Dual stack core and running LDP v4 and v6. At this time we do not see any technical reason for Dual stack core. Gyan On May 4, 2015 2:03 AM, "Mark Tinka" wrote: > Hello all. > > Being specific since I am an operator - IOS XR is now shipping LDPv6 > capability in 5.3.0. > > I've been testing this over the weekend, and would just like to clarify > whether code with dual-stack LDP support is meant to be backwards > compatible with code that only has single-stack LDP support. > > IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good > detail here: > > http://tinyurl.com/mbt5z4l > > When we enable "address-family ipv6" for LDP in IOS XR, the box is unable > to establish any LDP adjacencies. Given the code defaults to setting up > adjacencies via IPv6, this makes sense since all the other routers around > it do not yet run code that supports LDPv6. However, per the implementation > notes from Cisco, they say after 15x seconds of no adjacency formation, the > code should fall back to IPv4. I waited 1hr, this never happened. > > IOS XR has a knob to force adjacencies to be setup over IPv4, which I > tried as well. The box seemed to struggle building LDP adjacencies. > Adjacencies rise, and then fall in the space of 3x seconds. I think this > could be a bug, but just FYI. > > I'm, obviously, going to take this up with Cisco, but wondering whether > IOS XR is in violation of the spec., or if it's just me. > > Mark. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --047d7b624ac279c94005154df8dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

All

With 6PE and 6vPE over=C2=A0 IPv4 mpls core what is the busi= ness driver for Dual stack especially with BGP Free P core makes the core s= imple with minimal protocols for high speed forwarding plane.

So what is the necessity for Dual stack core and running=C2= =A0 LDP v4 and v6.=C2=A0 At this time we do not see any technical reason fo= r Dual stack core.

Gyan

On May 4, 2015 2:03 AM, "Mark Tinka" &= lt;mark.tinka@seacom.mu> wro= te:
=20 =20 =20
Hello all.

Being specific since I am an operator - IOS XR is now shipping LDPv6 capability in 5.3.0.

I've been testing this over the weekend, and would just like to clarify whether code with dual-stack LDP support is meant to be backwards compatible with code that only has single-stack LDP support.

IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detail here:

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 http://tinyurl.com/mbt5z4l

When we enable "address-family ipv6" for LDP in IOS XR, the= box is unable to establish any LDP adjacencies. Given the code defaults to setting up adjacencies via IPv6, this makes sense since all the other routers around it do not yet run code that supports LDPv6. However, per the implementation notes from Cisco, they say after 15x seconds of no adjacency formation, the code should fall back to IPv4. I waited 1hr, this never happened.

IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried as well. The box seemed to struggle building LDP adjacencies. Adjacencies rise, and then fall in the space of 3x seconds. I think this could be a bug, but just FYI.

I'm, obviously, going to take this up with Cisco, but wondering whether IOS XR is in violation of the spec., or if it's just me.<= br>
Mark.

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7b624ac279c94005154df8dd-- From nobody Mon May 4 22:28:04 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2A11B2E36 for ; Mon, 4 May 2015 22:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=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 rKJil2lxUaEX for ; Mon, 4 May 2015 22:28:00 -0700 (PDT) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (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 A614A1A90FE for ; Mon, 4 May 2015 22:27:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=Mark-Tinkas-MacBook.local) by the-host.seacom.mu with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id NNV36K-00082S-2N; Tue, 05 May 2015 07:27:56 +0200 To: Gyan Mishra references: <55470BAE.605@seacom.mu> From: Mark Tinka message-id: <554854DB.4020605@seacom.mu> Date: Tue, 5 May 2015 07:27:55 +0200 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: Content-Type: multipart/alternative; boundary="------------080405070208090704000705" Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 05:28:02 -0000 This is a multi-part message in MIME format. --------------080405070208090704000705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Not everybody likes or runs MPLS. 6PE adds more complexity than native IPv6. Mark. On 5/May/15 06:18, Gyan Mishra wrote: > > All > > With 6PE and 6vPE over IPv4 mpls core what is the business driver for > Dual stack especially with BGP Free P core makes the core simple with > minimal protocols for high speed forwarding plane. > > So what is the necessity for Dual stack core and running LDP v4 and > v6. At this time we do not see any technical reason for Dual stack core. > > Gyan > > On May 4, 2015 2:03 AM, "Mark Tinka" > wrote: > > Hello all. > > Being specific since I am an operator - IOS XR is now shipping > LDPv6 capability in 5.3.0. > > I've been testing this over the weekend, and would just like to > clarify whether code with dual-stack LDP support is meant to be > backwards compatible with code that only has single-stack LDP support. > > IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in > good detail here: > > http://tinyurl.com/mbt5z4l > > When we enable "address-family ipv6" for LDP in IOS XR, the box is > unable to establish any LDP adjacencies. Given the code defaults > to setting up adjacencies via IPv6, this makes sense since all the > other routers around it do not yet run code that supports LDPv6. > However, per the implementation notes from Cisco, they say after > 15x seconds of no adjacency formation, the code should fall back > to IPv4. I waited 1hr, this never happened. > > IOS XR has a knob to force adjacencies to be setup over IPv4, > which I tried as well. The box seemed to struggle building LDP > adjacencies. Adjacencies rise, and then fall in the space of 3x > seconds. I think this could be a bug, but just FYI. > > I'm, obviously, going to take this up with Cisco, but wondering > whether IOS XR is in violation of the spec., or if it's just me. > > Mark. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --------------080405070208090704000705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Not everybody likes or runs MPLS.

6PE adds more complexity than native IPv6.

Mark.

On 5/May/15 06:18, Gyan Mishra wrote:

All

With 6PE and 6vPE over  IPv4 mpls core what is the business driver for Dual stack especially with BGP Free P core makes the core simple with minimal protocols for high speed forwarding plane.

So what is the necessity for Dual stack core and running  LDP v4 and v6.  At this time we do not see any technical reason for Dual stack core.

Gyan

On May 4, 2015 2:03 AM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:
Hello all.

Being specific since I am an operator - IOS XR is now shipping LDPv6 capability in 5.3.0.

I've been testing this over the weekend, and would just like to clarify whether code with dual-stack LDP support is meant to be backwards compatible with code that only has single-stack LDP support.

IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detail here:

        http://tinyurl.com/mbt5z4l

When we enable "address-family ipv6" for LDP in IOS XR, the box is unable to establish any LDP adjacencies. Given the code defaults to setting up adjacencies via IPv6, this makes sense since all the other routers around it do not yet run code that supports LDPv6. However, per the implementation notes from Cisco, they say after 15x seconds of no adjacency formation, the code should fall back to IPv4. I waited 1hr, this never happened.

IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried as well. The box seemed to struggle building LDP adjacencies. Adjacencies rise, and then fall in the space of 3x seconds. I think this could be a bug, but just FYI.

I'm, obviously, going to take this up with Cisco, but wondering whether IOS XR is in violation of the spec., or if it's just me.

Mark.

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


--------------080405070208090704000705-- From nobody Mon May 4 23:50:23 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500FB1B2E98 for ; Mon, 4 May 2015 23:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.176 X-Spam-Level: X-Spam-Status: No, score=0.176 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, FSL_HELO_BARE_IP_2=1.675, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, SPF_PASS=-0.001] autolearn=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 yte01UvtDYR6 for ; Mon, 4 May 2015 23:50:18 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 809B71B2E8E for ; Mon, 4 May 2015 23:50:17 -0700 (PDT) Received: by oica37 with SMTP id a37so132693340oic.0 for ; Mon, 04 May 2015 23:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:references:in-reply-to:sensitivity:importance :subject:to:cc:from:date:content-type:mime-version; bh=iNX6Fv0LPi+LrjrXv9kLkuRtJiznz9gR9siUYXtVA+k=; b=hEMySUqMnFAgxd2ycAdnNewg8cNmb8K0Q9uN+qRSw/yFcTL6YRRIJVgqs5/SeKeaFP tj1JIu/WAL20rVyFCY2KZSIxXHmlr63mXhEOhPCe8/xWmOho7Np6qJiwl7RIpi4MuY5t C5ELXD3Q2KLVJUbBeWeIaPLRFx6hyC9a0lYgM9JKbpohbWZ6CADtYItWS947epyz5uvH 5Pr9Fye84xY6R7GCccQx42+2EtX/1HYk+HSAP+zJBPqqF7HK1IyweyCeLnd6KykUvCi5 25aSojPoDipGDhQtjYPIUwcT0yzBTnxqwcZi7iQtW26t6eBSM+/SNBba7pCwxnAMwmhD hKlQ== X-Received: by 10.107.7.87 with SMTP id 84mr32362661ioh.76.1430808616862; Mon, 04 May 2015 23:50:16 -0700 (PDT) Received: from 172.29.197.220 (bda-74-82-80-127.bis6.us.blackberry.com. [74.82.80.127]) by mx.google.com with ESMTPSA id n6sm6782858igx.10.2015.05.04.23.50.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 May 2015 23:50:15 -0700 (PDT) X-rim-org-msg-ref-id: 697359156 Message-ID: <697359156-1430808613-cardhu_decombobulator_blackberry.rim.net-558397463-@b4.c4.bise6.blackberry> X-Priority: Normal References: <55470BAE.605@seacom.mu> <554854DB.4020605@seacom.mu> In-Reply-To: <554854DB.4020605@seacom.mu> Sensitivity: Normal Importance: Normal To: "Mark Tinka" From: hayabusagsm@gmail.com Date: Tue, 5 May 2015 06:50:18 +0000 Content-Type: multipart/alternative; boundary="part4300-boundary-1495542876-1101089908" MIME-Version: 1.0 Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: hayabusagsm@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 06:50:20 -0000 --part4300-boundary-1495542876-1101089908 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" DQpXZSBoYXZlIGJlZW4gcnVubmluZyA2UEUgYW5kIDZWUEUgZm9yIGEgd2hpbGUgYW5kIHdvcmtz IHZlcnkgd2VsbCBhbmQgYWxsIGlzIGRvbmUgYnkgdGhlIFBFIGFuZCBSUiBpcHY2IGxhYmVsZWQg dW5pY2FzdCBBRkkuICBBY3R1YWxseSBpcyBwcmV0dHkgc2ltcGxlIGNvbmZpZ3VyYXRpb24gb24g Ym90aCAgSU9TIG9yIFhSIHRvIHJ1bi4NCg0KSSB3b3VsZCB0aGluayBMRFB2NiB3b3VsZCBvbmx5 IGJlIGEgY29uc2lkZXJhdGlvbiBpZiB5b3UgYXJlIHJ1bm5pbmcgbXBscy4NCg0KR3lhbg0KU2Vu dCBmcm9tIG15IFZlcml6b24gV2lyZWxlc3MgQmxhY2tCZXJyeQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTWFyayBUaW5rYSA8bWFyay50aW5rYUBzZWFjb20ubXU+DQpEYXRl OiBUdWUsIDUgTWF5IDIwMTUgMDc6Mjc6NTUgDQpUbzogR3lhbiBNaXNocmE8aGF5YWJ1c2Fnc21A Z21haWwuY29tPg0KQ2M6IDxtcGxzQGlldGYub3JnPg0KU3ViamVjdDoNCiBSZTogW21wbHNdIExE UHY2IEJlaGF2aW91ciBJbiBEdWFsIFN0YWNrIE5ldHdvcmsgLSBUZXN0aW5nIENpc2NvIElPUyBY Ug0KDQpOb3QgZXZlcnlib2R5IGxpa2VzIG9yIHJ1bnMgTVBMUy4NCg0KNlBFIGFkZHMgbW9yZSBj b21wbGV4aXR5IHRoYW4gbmF0aXZlIElQdjYuDQoNCk1hcmsuDQoNCk9uIDUvTWF5LzE1IDA2OjE4 LCBHeWFuIE1pc2hyYSB3cm90ZToNCj4NCj4gQWxsDQo+DQo+IFdpdGggNlBFIGFuZCA2dlBFIG92 ZXIgIElQdjQgbXBscyBjb3JlIHdoYXQgaXMgdGhlIGJ1c2luZXNzIGRyaXZlciBmb3INCj4gRHVh bCBzdGFjayBlc3BlY2lhbGx5IHdpdGggQkdQIEZyZWUgUCBjb3JlIG1ha2VzIHRoZSBjb3JlIHNp bXBsZSB3aXRoDQo+IG1pbmltYWwgcHJvdG9jb2xzIGZvciBoaWdoIHNwZWVkIGZvcndhcmRpbmcg cGxhbmUuDQo+DQo+IFNvIHdoYXQgaXMgdGhlIG5lY2Vzc2l0eSBmb3IgRHVhbCBzdGFjayBjb3Jl IGFuZCBydW5uaW5nICBMRFAgdjQgYW5kDQo+IHY2LiAgQXQgdGhpcyB0aW1lIHdlIGRvIG5vdCBz ZWUgYW55IHRlY2huaWNhbCByZWFzb24gZm9yIER1YWwgc3RhY2sgY29yZS4NCj4NCj4gR3lhbg0K Pg0KPiBPbiBNYXkgNCwgMjAxNSAyOjAzIEFNLCAiTWFyayBUaW5rYSIgPG1hcmsudGlua2FAc2Vh Y29tLm11DQo+IDxtYWlsdG86bWFyay50aW5rYUBzZWFjb20ubXU+PiB3cm90ZToNCj4NCj4gICAg IEhlbGxvIGFsbC4NCj4NCj4gICAgIEJlaW5nIHNwZWNpZmljIHNpbmNlIEkgYW0gYW4gb3BlcmF0 b3IgLSBJT1MgWFIgaXMgbm93IHNoaXBwaW5nDQo+ICAgICBMRFB2NiBjYXBhYmlsaXR5IGluIDUu My4wLg0KPg0KPiAgICAgSSd2ZSBiZWVuIHRlc3RpbmcgdGhpcyBvdmVyIHRoZSB3ZWVrZW5kLCBh bmQgd291bGQganVzdCBsaWtlIHRvDQo+ICAgICBjbGFyaWZ5IHdoZXRoZXIgY29kZSB3aXRoIGR1 YWwtc3RhY2sgTERQIHN1cHBvcnQgaXMgbWVhbnQgdG8gYmUNCj4gICAgIGJhY2t3YXJkcyBjb21w YXRpYmxlIHdpdGggY29kZSB0aGF0IG9ubHkgaGFzIHNpbmdsZS1zdGFjayBMRFAgc3VwcG9ydC4N Cj4NCj4gICAgIElPUyBYUiA1LjMuMCdzIGltcGxlbWVudGF0aW9uIG9mIGR1YWwtc3RhY2sgSVB2 NiBpcyBleHBsYWluZWQgaW4NCj4gICAgIGdvb2QgZGV0YWlsIGhlcmU6DQo+DQo+ICAgICAgICAg ICAgIGh0dHA6Ly90aW55dXJsLmNvbS9tYnQ1ejRsDQo+DQo+ICAgICBXaGVuIHdlIGVuYWJsZSAi YWRkcmVzcy1mYW1pbHkgaXB2NiIgZm9yIExEUCBpbiBJT1MgWFIsIHRoZSBib3ggaXMNCj4gICAg IHVuYWJsZSB0byBlc3RhYmxpc2ggYW55IExEUCBhZGphY2VuY2llcy4gR2l2ZW4gdGhlIGNvZGUg ZGVmYXVsdHMNCj4gICAgIHRvIHNldHRpbmcgdXAgYWRqYWNlbmNpZXMgdmlhIElQdjYsIHRoaXMg bWFrZXMgc2Vuc2Ugc2luY2UgYWxsIHRoZQ0KPiAgICAgb3RoZXIgcm91dGVycyBhcm91bmQgaXQg ZG8gbm90IHlldCBydW4gY29kZSB0aGF0IHN1cHBvcnRzIExEUHY2Lg0KPiAgICAgSG93ZXZlciwg cGVyIHRoZSBpbXBsZW1lbnRhdGlvbiBub3RlcyBmcm9tIENpc2NvLCB0aGV5IHNheSBhZnRlcg0K PiAgICAgMTV4IHNlY29uZHMgb2Ygbm8gYWRqYWNlbmN5IGZvcm1hdGlvbiwgdGhlIGNvZGUgc2hv dWxkIGZhbGwgYmFjaw0KPiAgICAgdG8gSVB2NC4gSSB3YWl0ZWQgMWhyLCB0aGlzIG5ldmVyIGhh cHBlbmVkLg0KPg0KPiAgICAgSU9TIFhSIGhhcyBhIGtub2IgdG8gZm9yY2UgYWRqYWNlbmNpZXMg dG8gYmUgc2V0dXAgb3ZlciBJUHY0LA0KPiAgICAgd2hpY2ggSSB0cmllZCBhcyB3ZWxsLiBUaGUg Ym94IHNlZW1lZCB0byBzdHJ1Z2dsZSBidWlsZGluZyBMRFANCj4gICAgIGFkamFjZW5jaWVzLiBB ZGphY2VuY2llcyByaXNlLCBhbmQgdGhlbiBmYWxsIGluIHRoZSBzcGFjZSBvZiAzeA0KPiAgICAg c2Vjb25kcy4gSSB0aGluayB0aGlzIGNvdWxkIGJlIGEgYnVnLCBidXQganVzdCBGWUkuDQo+DQo+ ICAgICBJJ20sIG9idmlvdXNseSwgZ29pbmcgdG8gdGFrZSB0aGlzIHVwIHdpdGggQ2lzY28sIGJ1 dCB3b25kZXJpbmcNCj4gICAgIHdoZXRoZXIgSU9TIFhSIGlzIGluIHZpb2xhdGlvbiBvZiB0aGUg c3BlYy4sIG9yIGlmIGl0J3MganVzdCBtZS4NCj4NCj4gICAgIE1hcmsuDQo+DQo+ICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgbXBscyBt YWlsaW5nIGxpc3QNCj4gICAgIG1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3JnPg0K PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQoNCg0K --part4300-boundary-1495542876-1101089908 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11 dGYtOCIgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4NCiAgPC9oZWFkPg0KICA8Ym9keSBiZ2Nv bG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4NPGJyLz5XZSBoYXZlIGJlZW4gcnVubmluZyA2 UEUgYW5kIDZWUEUgZm9yIGEgd2hpbGUgYW5kIHdvcmtzIHZlcnkgd2VsbCBhbmQgYWxsIGlzIGRv bmUgYnkgdGhlIFBFIGFuZCBSUiBpcHY2IGxhYmVsZWQgdW5pY2FzdCBBRkkuICBBY3R1YWxseSBp cyBwcmV0dHkgc2ltcGxlIGNvbmZpZ3VyYXRpb24gb24gYm90aCAgSU9TIG9yIFhSIHRvIHJ1bi48 YnIvPjxici8+SSB3b3VsZCB0aGluayBMRFB2NiB3b3VsZCBvbmx5IGJlIGEgY29uc2lkZXJhdGlv biBpZiB5b3UgYXJlIHJ1bm5pbmcgbXBscy48YnIvPjxici8+R3lhbjxkaXY+U2VudCBmcm9tIG15 IFZlcml6b24gV2lyZWxlc3MgQmxhY2tCZXJyeTwvZGl2Pjxoci8+PGRpdj48Yj5Gcm9tOiA8L2I+ IE1hcmsgVGlua2EgJmx0O21hcmsudGlua2FAc2VhY29tLm11Jmd0Ow0KPC9kaXY+PGRpdj48Yj5E YXRlOiA8L2I+VHVlLCA1IE1heSAyMDE1IDA3OjI3OjU1ICswMjAwPC9kaXY+PGRpdj48Yj5Ubzog PC9iPkd5YW4gTWlzaHJhJmx0O2hheWFidXNhZ3NtQGdtYWlsLmNvbSZndDs8L2Rpdj48ZGl2Pjxi PkNjOiA8L2I+Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9kaXY+PGRpdj48Yj5TdWJqZWN0OiA8L2I+ UmU6IFttcGxzXSBMRFB2NiBCZWhhdmlvdXIgSW4gRHVhbCBTdGFjayBOZXR3b3JrIC0gVGVzdGlu ZyBDaXNjbyBJT1MgWFI8L2Rpdj48ZGl2Pjxici8+PC9kaXY+DQogICAgPGZvbnQgZmFjZT0iSGVs dmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZiI+Tm90IGV2ZXJ5Ym9keSBsaWtlcyBvcg0KICAgICAg cnVucyBNUExTLjxicj4NCiAgICAgIDxicj4NCiAgICAgIDZQRSBhZGRzIG1vcmUgY29tcGxleGl0 eSB0aGFuIG5hdGl2ZSBJUHY2Ljxicj4NCiAgICAgIDxicj4NCiAgICAgIE1hcmsuPGJyPg0KICAg IDwvZm9udD48YnI+DQogICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA1L01heS8x NSAwNjoxOCwgR3lhbiBNaXNocmEgd3JvdGU6PGJyPg0KICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1 b3RlDQpjaXRlPSJtaWQ6Q0FCTmh3VjBiWmpZam92RzRIN1ZtRmtRSGRWWGlyT19iT1BKUVdrMVlr SnlDWk9vOStBQG1haWwuZ21haWwuY29tIg0KICAgICAgdHlwZT0iY2l0ZSI+DQogICAgICA8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11 dGYtOCI+DQogICAgICA8cCBkaXI9Imx0ciI+QWxsPC9wPg0KICAgICAgPHAgZGlyPSJsdHIiPldp dGggNlBFIGFuZCA2dlBFIG92ZXLCoCBJUHY0IG1wbHMgY29yZSB3aGF0IGlzIHRoZQ0KICAgICAg ICBidXNpbmVzcyBkcml2ZXIgZm9yIER1YWwgc3RhY2sgZXNwZWNpYWxseSB3aXRoIEJHUCBGcmVl IFAgY29yZQ0KICAgICAgICBtYWtlcyB0aGUgY29yZSBzaW1wbGUgd2l0aCBtaW5pbWFsIHByb3Rv Y29scyBmb3IgaGlnaCBzcGVlZA0KICAgICAgICBmb3J3YXJkaW5nIHBsYW5lLjwvcD4NCiAgICAg IDxwIGRpcj0ibHRyIj5TbyB3aGF0IGlzIHRoZSBuZWNlc3NpdHkgZm9yIER1YWwgc3RhY2sgY29y ZSBhbmQNCiAgICAgICAgcnVubmluZ8KgIExEUCB2NCBhbmQgdjYuwqAgQXQgdGhpcyB0aW1lIHdl IGRvIG5vdCBzZWUgYW55DQogICAgICAgIHRlY2huaWNhbCByZWFzb24gZm9yIER1YWwgc3RhY2sg Y29yZS48YnI+DQogICAgICA8L3A+DQogICAgICA8cCBkaXI9Imx0ciI+R3lhbiA8L3A+DQogICAg ICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTWF5IDQsIDIwMTUgMjowMyBBTSwgIk1hcmsg VGlua2EiICZsdDs8YQ0KICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFp bHRvOm1hcmsudGlua2FAc2VhY29tLm11Ij48YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlh dGVkIiBocmVmPSJtYWlsdG86bWFyay50aW5rYUBzZWFjb20ubXUiPm1hcmsudGlua2FAc2VhY29t Lm11PC9hPjwvYT4mZ3Q7DQogICAgICAgIHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+DQog ICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg MA0KICAgICAgICAgIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQogICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4g PGZvbnQgZmFjZT0iSGVsdmV0aWNhLA0KICAgICAgICAgICAgICBBcmlhbCwgc2Fucy1zZXJpZiI+ SGVsbG8gYWxsLjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICBCZWluZyBz cGVjaWZpYyBzaW5jZSBJIGFtIGFuIG9wZXJhdG9yIC0gSU9TIFhSIGlzIG5vdw0KICAgICAgICAg ICAgICBzaGlwcGluZyBMRFB2NiBjYXBhYmlsaXR5IGluIDUuMy4wLjxicj4NCiAgICAgICAgICAg ICAgPGJyPg0KICAgICAgICAgICAgICBJJ3ZlIGJlZW4gdGVzdGluZyB0aGlzIG92ZXIgdGhlIHdl ZWtlbmQsIGFuZCB3b3VsZCBqdXN0DQogICAgICAgICAgICAgIGxpa2UgdG8gY2xhcmlmeSB3aGV0 aGVyIGNvZGUgd2l0aCBkdWFsLXN0YWNrIExEUCBzdXBwb3J0DQogICAgICAgICAgICAgIGlzIG1l YW50IHRvIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggY29kZSB0aGF0IG9ubHkNCiAgICAg ICAgICAgICAgaGFzIHNpbmdsZS1zdGFjayBMRFAgc3VwcG9ydC48YnI+DQogICAgICAgICAgICAg IDxicj4NCiAgICAgICAgICAgICAgSU9TIFhSIDUuMy4wJ3MgaW1wbGVtZW50YXRpb24gb2YgZHVh bC1zdGFjayBJUHY2IGlzDQogICAgICAgICAgICAgIGV4cGxhaW5lZCBpbiBnb29kIGRldGFpbCBo ZXJlOjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICDCoMKgwqAgwqDCoMKg IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICBocmVmPSJodHRwOi8v dGlueXVybC5jb20vbWJ0NXo0bCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90aW55dXJsLmNvbS9t YnQ1ejRsPC9hPjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICBXaGVuIHdl IGVuYWJsZSAiYWRkcmVzcy1mYW1pbHkgaXB2NiIgZm9yIExEUCBpbiBJT1MgWFIsDQogICAgICAg ICAgICAgIHRoZSBib3ggaXMgdW5hYmxlIHRvIGVzdGFibGlzaCBhbnkgTERQIGFkamFjZW5jaWVz LiBHaXZlbg0KICAgICAgICAgICAgICB0aGUgY29kZSBkZWZhdWx0cyB0byBzZXR0aW5nIHVwIGFk amFjZW5jaWVzIHZpYSBJUHY2LCB0aGlzDQogICAgICAgICAgICAgIG1ha2VzIHNlbnNlIHNpbmNl IGFsbCB0aGUgb3RoZXIgcm91dGVycyBhcm91bmQgaXQgZG8gbm90DQogICAgICAgICAgICAgIHll dCBydW4gY29kZSB0aGF0IHN1cHBvcnRzIExEUHY2LiBIb3dldmVyLCBwZXIgdGhlDQogICAgICAg ICAgICAgIGltcGxlbWVudGF0aW9uIG5vdGVzIGZyb20gQ2lzY28sIHRoZXkgc2F5IGFmdGVyIDE1 eA0KICAgICAgICAgICAgICBzZWNvbmRzIG9mIG5vIGFkamFjZW5jeSBmb3JtYXRpb24sIHRoZSBj b2RlIHNob3VsZCBmYWxsDQogICAgICAgICAgICAgIGJhY2sgdG8gSVB2NC4gSSB3YWl0ZWQgMWhy LCB0aGlzIG5ldmVyIGhhcHBlbmVkLjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg ICAgICBJT1MgWFIgaGFzIGEga25vYiB0byBmb3JjZSBhZGphY2VuY2llcyB0byBiZSBzZXR1cCBv dmVyDQogICAgICAgICAgICAgIElQdjQsIHdoaWNoIEkgdHJpZWQgYXMgd2VsbC4gVGhlIGJveCBz ZWVtZWQgdG8gc3RydWdnbGUNCiAgICAgICAgICAgICAgYnVpbGRpbmcgTERQIGFkamFjZW5jaWVz LiBBZGphY2VuY2llcyByaXNlLCBhbmQgdGhlbiBmYWxsDQogICAgICAgICAgICAgIGluIHRoZSBz cGFjZSBvZiAzeCBzZWNvbmRzLiBJIHRoaW5rIHRoaXMgY291bGQgYmUgYSBidWcsDQogICAgICAg ICAgICAgIGJ1dCBqdXN0IEZZSS48YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg ICAgSSdtLCBvYnZpb3VzbHksIGdvaW5nIHRvIHRha2UgdGhpcyB1cCB3aXRoIENpc2NvLCBidXQN CiAgICAgICAgICAgICAgd29uZGVyaW5nIHdoZXRoZXIgSU9TIFhSIGlzIGluIHZpb2xhdGlvbiBv ZiB0aGUgc3BlYy4sIG9yDQogICAgICAgICAgICAgIGlmIGl0J3MganVzdCBtZS48YnI+DQogICAg ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgTWFyay48YnI+DQogICAgICAgICAgICA8L2Zv bnQ+IDwvZGl2Pg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiAgICAgICAgICBtcGxzIG1haWxpbmcg bGlzdDxicj4NCiAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICA8YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiDQogICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4NCiAgICAgICAg ICA8YnI+DQogICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2tx dW90ZT4NCiAgICA8YnI+DQogIDwvYm9keT4NCjwvaHRtbD4NCg0K --part4300-boundary-1495542876-1101089908-- From nobody Mon May 4 23:56:47 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EB31B2EA5 for ; Mon, 4 May 2015 23:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GKsOKWAs6gCR for ; Mon, 4 May 2015 23:56:43 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA831B2EA4 for ; Mon, 4 May 2015 23:56:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 15386A1; Tue, 5 May 2015 08:56:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1430809001; bh=ZAlBDqvHC8t2ZlRnoECsKTmHAGAh8wEIGjPP906KOCQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=cPtXQbArqhKbpjmEHRQ7iOi4Or/Lp/vz9nlTadrzLo7pPPB3q7NSEdYmG72gGWLw9 lZWR+32T5LWGCDMCnC/2hpibuQ2A0oZY18tvi3CDuu2GRMYH1Oa9wpmjijIkuFHARe WDcwtfMHcdxMN22QCPD1wBcssEYkWQ6qsPxKo0Rw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0AB7B9F; Tue, 5 May 2015 08:56:41 +0200 (CEST) Date: Tue, 5 May 2015 08:56:41 +0200 (CEST) From: Mikael Abrahamsson To: Gyan Mishra In-Reply-To: Message-ID: References: <55470BAE.605@seacom.mu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 06:56:45 -0000 On Tue, 5 May 2015, Gyan Mishra wrote: > All > > With 6PE and 6vPE over IPv4 mpls core what is the business driver for Dual > stack especially with BGP Free P core makes the core simple with minimal > protocols for high speed forwarding plane. > > So what is the necessity for Dual stack core and running LDP v4 and v6. > At this time we do not see any technical reason for Dual stack core. Because if you're a greenfield operator which might get a /22 IPv4 space, using any part of this space for infrastructure is just stupid, and you might not want to number your core out of RFC1918 addresses. So the necessity is not for dual stack core but to be able to build a single stack IPv6 core and run 4PE over it. https://puck.nether.net/pipermail/cisco-nsp/2010-July/071550.html is 4 years and 10 months ago, and we're still not really close to possibility of building a core MPLS network without IPv4, even though we're closer than we were 5 years ago. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue May 5 00:14:29 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10521B2DEA for ; Tue, 5 May 2015 00:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=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 yz_aW3gCEH2g for ; Tue, 5 May 2015 00:14:24 -0700 (PDT) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (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 894F01B2DBD for ; Tue, 5 May 2015 00:14:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=Mark-Tinkas-MacBook.local) by the-host.seacom.mu with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id NNV83W-00087E-3V; Tue, 05 May 2015 09:14:20 +0200 To: hayabusagsm@gmail.com references: <55470BAE.605@seacom.mu> <554854DB.4020605@seacom.mu> <697359156-1430808613-cardhu_decombobulator_blackberry.rim.net-558397463-@b4.c4.bise6.blackberry> From: Mark Tinka message-id: <55486DCB.60401@seacom.mu> Date: Tue, 5 May 2015 09:14:19 +0200 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <697359156-1430808613-cardhu_decombobulator_blackberry.rim.net-558397463-@b4.c4.bise6.blackberry> Content-Type: multipart/alternative; boundary="------------040505010405080409080906" Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 07:14:25 -0000 This is a multi-part message in MIME format. --------------040505010405080409080906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit As I said on another forum, 6PE is stable, so it works. I just think it is unnecessary complexity if your network can do basic/simple IPv6. Moreover, I don't want my IPv6 falling over if MPLS dies. Yes, LDPv6 is if you run MPLS. But for me, native MPLS for IPv6 is better than tunneled MPLS for IPv6. We do use 6VPE, because we do sell l3vpnv6 services. 6VPE does not require 6PE, which suits me just fine. Mark. On 5/May/15 08:50, hayabusagsm@gmail.com wrote: > > We have been running 6PE and 6VPE for a while and works very well and > all is done by the PE and RR ipv6 labeled unicast AFI. Actually is > pretty simple configuration on both IOS or XR to run. > > I would think LDPv6 would only be a consideration if you are running mpls. > > Gyan > Sent from my Verizon Wireless BlackBerry > ------------------------------------------------------------------------ > *From: * Mark Tinka > *Date: *Tue, 5 May 2015 07:27:55 +0200 > *To: *Gyan Mishra > *Cc: * > *Subject: *Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing > Cisco IOS XR > > Not everybody likes or runs MPLS. > > 6PE adds more complexity than native IPv6. > > Mark. > > On 5/May/15 06:18, Gyan Mishra wrote: >> >> All >> >> With 6PE and 6vPE over IPv4 mpls core what is the business driver >> for Dual stack especially with BGP Free P core makes the core simple >> with minimal protocols for high speed forwarding plane. >> >> So what is the necessity for Dual stack core and running LDP v4 and >> v6. At this time we do not see any technical reason for Dual stack core. >> >> Gyan >> >> On May 4, 2015 2:03 AM, "Mark Tinka" wrote: >> >> Hello all. >> >> Being specific since I am an operator - IOS XR is now shipping >> LDPv6 capability in 5.3.0. >> >> I've been testing this over the weekend, and would just like to >> clarify whether code with dual-stack LDP support is meant to be >> backwards compatible with code that only has single-stack LDP >> support. >> >> IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in >> good detail here: >> >> http://tinyurl.com/mbt5z4l >> >> When we enable "address-family ipv6" for LDP in IOS XR, the box >> is unable to establish any LDP adjacencies. Given the code >> defaults to setting up adjacencies via IPv6, this makes sense >> since all the other routers around it do not yet run code that >> supports LDPv6. However, per the implementation notes from Cisco, >> they say after 15x seconds of no adjacency formation, the code >> should fall back to IPv4. I waited 1hr, this never happened. >> >> IOS XR has a knob to force adjacencies to be setup over IPv4, >> which I tried as well. The box seemed to struggle building LDP >> adjacencies. Adjacencies rise, and then fall in the space of 3x >> seconds. I think this could be a bug, but just FYI. >> >> I'm, obviously, going to take this up with Cisco, but wondering >> whether IOS XR is in violation of the spec., or if it's just me. >> >> Mark. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > --------------040505010405080409080906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit As I said on another forum, 6PE is stable, so it works. I just think it is unnecessary complexity if your network can do basic/simple IPv6. Moreover, I don't want my IPv6 falling over if MPLS dies.

Yes, LDPv6 is if you run MPLS. But for me, native MPLS for IPv6 is better than tunneled MPLS for IPv6.

We do use 6VPE, because we do sell l3vpnv6 services. 6VPE does not require 6PE, which suits me just fine.

Mark.

On 5/May/15 08:50, hayabusagsm@gmail.com wrote:

We have been running 6PE and 6VPE for a while and works very well and all is done by the PE and RR ipv6 labeled unicast AFI. Actually is pretty simple configuration on both IOS or XR to run.

I would think LDPv6 would only be a consideration if you are running mpls.

Gyan
Sent from my Verizon Wireless BlackBerry
From: Mark Tinka <mark.tinka@seacom.mu>
Date: Tue, 5 May 2015 07:27:55 +0200
Subject: Re: [mpls] LDPv6 Behaviour In Dual Stack Network - Testing Cisco IOS XR

Not everybody likes or runs MPLS.

6PE adds more complexity than native IPv6.

Mark.

On 5/May/15 06:18, Gyan Mishra wrote:

All

With 6PE and 6vPE over  IPv4 mpls core what is the business driver for Dual stack especially with BGP Free P core makes the core simple with minimal protocols for high speed forwarding plane.

So what is the necessity for Dual stack core and running  LDP v4 and v6.  At this time we do not see any technical reason for Dual stack core.

Gyan

On May 4, 2015 2:03 AM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:
Hello all.

Being specific since I am an operator - IOS XR is now shipping LDPv6 capability in 5.3.0.

I've been testing this over the weekend, and would just like to clarify whether code with dual-stack LDP support is meant to be backwards compatible with code that only has single-stack LDP support.

IOS XR 5.3.0's implementation of dual-stack IPv6 is explained in good detail here:

        http://tinyurl.com/mbt5z4l

When we enable "address-family ipv6" for LDP in IOS XR, the box is unable to establish any LDP adjacencies. Given the code defaults to setting up adjacencies via IPv6, this makes sense since all the other routers around it do not yet run code that supports LDPv6. However, per the implementation notes from Cisco, they say after 15x seconds of no adjacency formation, the code should fall back to IPv4. I waited 1hr, this never happened.

IOS XR has a knob to force adjacencies to be setup over IPv4, which I tried as well. The box seemed to struggle building LDP adjacencies. Adjacencies rise, and then fall in the space of 3x seconds. I think this could be a bug, but just FYI.

I'm, obviously, going to take this up with Cisco, but wondering whether IOS XR is in violation of the spec., or if it's just me.

Mark.

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



--------------040505010405080409080906-- From nobody Wed May 6 15:39:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED331B29F6 for ; Wed, 6 May 2015 15:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 b85MzVenyUHb for ; Wed, 6 May 2015 15:39:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AEBE1ACD9F for ; Wed, 6 May 2015 15:39:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSF46823; Wed, 06 May 2015 22:39:19 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 May 2015 23:39:18 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 6 May 2015 15:39:07 -0700 From: Lucy yong To: "draft-mirsky-mpls-residence-time@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Thread-Index: AQHQhky7CoX4gxzfLUGxZrSN4qgSRZ1vhCDw Date: Wed, 6 May 2015 22:39:07 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm> References: <55473BCB.70709@pi.nu> In-Reply-To: <55473BCB.70709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 22:39:23 -0000 SGkgQWxsLA0KDQpJIHJldmlld2VkIGRyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lIGFz IHRoZSBtZW1iZXIgb2YgTVBMUyBSZXZpZXcgVGVhbSBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNv bW1lbnRzOg0KDQppcyB0aGUgZG9jdW1lbnQgY29oZXJlbnQ/DQoNClllcy4gSXQgc3BlY2lmaWVz IGhvdyBNUExTIHN1cHBvcnRzIHJlc2lkZW5jZSB0aW1lIG1lYXN1cmVtZW50LiANCg0KaXMgaXQg dXNlZnVsIChpZSwgaXMgaXQgbGlrZWx5IHRvIGJlIGFjdHVhbGx5IHVzZWZ1bCBpbiBvcGVyYXRp b25hbCBuZXR3b3Jrcyk/DQoNClRoZSBkb2N1bWVudCBjbGFpbXMgdGhhdCBzdWNoIG1lYXN1cmVt ZW50IGNhbiBpbXByb3ZlIHRoZSBhY2N1cmFjeSBvZiBjbG9jayBzeW5jaHJvbml6YXRpb24gYWNy b3NzIHRoZSBuZXR3b3JrLiBJIGFtIG5vdCBhbiBvcGVyYXRvciBhbmQgYXV0aG9yIGFuZCBub3Qg c3VyZSBob3cgdXNlZnVsIHRoaXMgZmVhdHVyZSBwcm92aWRlcyBjb21wYXJlZCB0byB0aGUgY29t cGxleGl0eSBhZGRpbmcgdG8uIA0KDQppcyB0aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ IA0KWWVzLiBUaGUgZHJhZnQgcHJvdmlkZXMgYSBkZXRhaWwgc29sdXRpb24gaW4gY29udHJvbCBw bGFuZSBhbmQgZGF0YSBwbGFuZSB0byBhY2hpZXZlIHRoaXMgcHVycG9zZS4NCg0KaXMgdGhlIGRv Y3VtZW50IHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uPw0KWWVzLiBUaGUg ZG9jdW1lbnQgc3RhdGVzIHRoZSBwcm9ibGVtIGNsZWFybHkgYW5kIHByb3ZpZGVzIGEgc29sdXRp b24gdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0uICANCg0KSU1ITzogIGFmdGVyIGFkb3B0aW5nIGl0 IGFzIHRoZSBXRyBkcmFmdCwgdGhlIFdHIHNob3VsZCBmdXJ0aGVyIGV2YWx1YXRlIGlmIGNvbnRy b2wgcGxhbmUgYW5kIGRhdGEgcGxhbmUgc29sdXRpb24gY2FuIGJlIHNpbXBsaWZpZWQuIFRoZSBh cmVhcyBtYXkgYmUgY29uc2lkZXJlZDoNCjEpIERvIHdlIGhhdmUgdG8gdXNlIElHUCB0byBhbm5v dW5jZSBub2RlIFJUTSBjYXBhYmlsaXR5PyBDYW4gUlNWUC1URSByZXNvbHZlIHRoZSBpc3N1ZSBi eSBpdHNlbGY/DQoyKSBXaWxsIHBvc3NpYmxlIHRvIGVuaGFuY2UgUlJPIHRvIHNlcnZlIFJTTyBw dXJwb3NlIGluc3RlYWQgb2YgY2FycnlpbmcgYm90aCBSUk8gYW5kIFJTTyBpbiB0aGUgbWVzc2Fn ZT8NCjMpIFNpbmNlIHRoaXMgZmVhdHVyZSBpcyBkZXNpZ25lZCBmb3IgdGhlIExTUCB0aGF0IGlz IHVzZWQgZm9yIGNsb2NrIHN5bmNocm9uaXphdGlvbiwgc3VjaCBMU1BzIGFyZSBub3QgbWFqb3Jp dHksIHNvIGl0IHNob3VsZCBiZSBvcHRpb24gaW4gTFNQIHNldHVwLiBNYWtlIHRoYXQgdmVyeSBj bGVhci4NCjQpIHR3by1zdGVwIGNsb2NrIG1vZGUgaXMgcXVpdGUgY29tcGxleC4gVGhlIGRlc2Ny aXB0aW9uIGluIFNlY3Rpb24gNyBpcyBub3QgY2xlYXIgdG8gbWUgd2h5IHRoaXMgbW9kZSBpcyBu ZWNlc3NhcnkuIA0KDQpSZWdhcmRzLA0KTHVjeQ0KDQo= From nobody Wed May 6 21:37:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD531A92FE; Wed, 6 May 2015 21:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aKo5lA4VHZXM; Wed, 6 May 2015 21:37:41 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D527F1A9301; Wed, 6 May 2015 21:37:39 -0700 (PDT) Received: by labbd9 with SMTP id bd9so22013356lab.2; Wed, 06 May 2015 21:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gD2tj5dJ5Wv9lFPbgsflq5ltfKKdjcMyNA3oXAirs9g=; b=rKCnPeNpMocFHysUAZxN1PDiuvehazs8+r3MQawsFjsfft/rM83FKGGg+ze/xQVDJM 672OzsQohjc4LRblgQf1D0VfzdpgcwV94J52/ewE8Dmukk2Y5FE+BmTcbrkyeTyF0gUi VWOVtPSVdlNTyk/m091TvarLoh1K9gFWkfhyvN0HMYz+w6/E8RMSJ3rX6VTnO7cOQB4C mhXDd9FBeOZm4HNmOogCjZtJFn08TxDT4gIdnp/oxQ44QCDXgrDwb7eni/Q7hDmDU0BM 4hpUwE2kjYczUHsEi6vPrSZtcKc3cxIWxydJuaV7q3jzDsdk83mYsYqPF0jcCnz+SK1S yqaw== MIME-Version: 1.0 X-Received: by 10.152.5.134 with SMTP id s6mr1425905las.99.1430973458158; Wed, 06 May 2015 21:37:38 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Wed, 6 May 2015 21:37:38 -0700 (PDT) In-Reply-To: <20150504195805.GB25036@pfrc.org> References: <20150504195805.GB25036@pfrc.org> Date: Wed, 6 May 2015 21:37:38 -0700 Message-ID: From: Nobo Akiya To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e013d1010a821f10515767840 Archived-At: Cc: mpls , rtg-bfd@ietf.org Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 04:37:43 -0000 --089e013d1010a821f10515767840 Content-Type: text/plain; charset=UTF-8 Hi Jeff, I am not aware of any IPR related to this document. Thanks! -Nobo On Mon, May 4, 2015 at 12:58 PM, Jeffrey Haas wrote: > The BFD mailing list has been quiet since shortly after IETF 92. We have a > number of documents that seem stable and ready to advance. > > This email begins a two week Working Group Last Call for > draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884. > > This last call will end on May 15. > > Simultaneously, the authors of this draft should state to the mailing list > whether there is any IPR associated with this draft or not. > > This WGLC is also being cc'd to mpls@ietf to permit additional commentary. > > -- Jeff and Nobo > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --089e013d1010a821f10515767840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff,

I am not aware of any IPR rela= ted to this document.

Thanks!

=
-Nobo

On Mon, May 4, 2015 at 12:58 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
The BFD mailing list has been= quiet since shortly after IETF 92.=C2=A0 We have a
number of documents that seem stable and ready to advance.

This email begins a two week Working Group Last Call for
draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884.

This last call will end on May 15.

Simultaneously, the authors of this draft should state to the mailing list<= br> whether there is any IPR associated with this draft or not.

This WGLC is also being cc'd to mpls@ietf to permit additional commenta= ry.

-- Jeff and Nobo

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--089e013d1010a821f10515767840-- From nobody Wed May 6 22:49:16 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7041ACE9E for ; Wed, 6 May 2015 22:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 K5_G5slEVoMe for ; Wed, 6 May 2015 22:49:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B714A1ACE52 for ; Wed, 6 May 2015 22:49:11 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (25.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.154.19; Thu, 7 May 2015 05:48:54 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0154.018; Thu, 7 May 2015 05:48:54 +0000 From: Alexander Vainshtein To: Lucy yong Thread-Topic: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Thread-Index: AQHQhky8t8zjFSfNK0Wy5dLwJ5pE751vjlKAgABygh8= Date: Thu, 7 May 2015 05:48:54 +0000 Message-ID: <1430977731121.37704@ecitele.com> References: <55473BCB.70709@pi.nu>, <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [5.153.9.206] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 056929CBB8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(377454003)(53754006)(36756003)(122556002)(54356999)(76176999)(2900100001)(19580405001)(71446004)(40100003)(19580395003)(2950100001)(16236675004)(19627405001)(46102003)(19625215002)(50986999)(87936001)(2656002)(62966003)(77156002)(189998001)(66066001)(117636001)(102836002)(230783001)(5001960100002)(110136002)(106116001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_143097773112137704ecitelecom_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2015 05:48:54.2489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-mirsky-mpls-residence-time@tools.ietf.org" Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 05:49:15 -0000 --_000_143097773112137704ecitelecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lucy, Lots of thanks for a prompt and very detailed review. Please see my personal comments (I did not discuss them with other authors = yet) on some of your proposals for simplification inline below. Regards, Sasha ________________________________________ From: Lucy yong Sent: Thursday, May 7, 2015 1:39 AM To: draft-mirsky-mpls-residence-time@tools.ietf.org; mpls-chairs@tools.ietf= .org Cc: mpls@ietf.org Subject: RE: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Hi All, I reviewed draft-mirsky-mpls-residence-time as the member of MPLS Review Te= am and have the following comments: is the document coherent? Yes. It specifies how MPLS supports residence time measurement. is it useful (ie, is it likely to be actually useful in operational network= s)? The document claims that such measurement can improve the accuracy of clock= synchronization across the network. I am not an operator and author and no= t sure how useful this feature provides compared to the complexity adding t= o. is the document technically sound? Yes. The draft provides a detail solution in control plane and data plane t= o achieve this purpose. is the document ready to be considered for WG adoption? Yes. The document states the problem clearly and provides a solution to add= ress this problem. IMHO: after adopting it as the WG draft, the WG should further evaluate if= control plane and data plane solution can be simplified. The areas may be = considered: 1) Do we have to use IGP to announce node RTM capability? Can RSVP-TE resol= ve the issue by itself? [[Sasha]] I do not think so. One of the benefits of distributing RTM capabi= lities with IGP is that the CSPF algorithm can compute an explicit path to = the tail-end node that minimizes the number of transit nodes that are not R= TM-capable. This minimization, in its turn, makes clock synchronization mor= e accurate since the influence of residence time in each of the transit nod= es on the clock of synchronization is minimized (and potentially completely= eliminated). I do not see how RSVP-TE could provide this functionality all by itself, bu= t I may be missing something. 2) Will possible to enhance RRO to serve RSO purpose instead of carrying bo= th RRO and RSO in the message? [[Sasha]] This is probably possible, but may affect backward compatibility = with nodes that do not support RTM (or at least make it more complicated) 3) Since this feature is designed for the LSP that is used for clock synchr= onization, such LSPs are not majority, so it should be option in LSP setup.= Make that very clear.[[Sasha]] I fully agree. 4) two-step clock mode is quite complex. The description in Section 7 is no= t clear to me why this mode is necessary. [[Sasha]] I fully agree with you that 2-step clock is quite complex. Howeve= r, it is quite useful if forwarding HW is not capable of modifying the pack= et that is transmitted via one of its ports very close to the moment when i= t is actually transmitted (definitely after it has been extracted from the = egress queue for transmission). The 2-step clock addresses this issue by li= miting the HW functionality to just taking the timestamp at this moment (mu= ch simpler!) and passing it to SW handling so that, e.g., it can be insert= ed into the so-called "follow-up" packet. Not sure if this explanation really helps. Regards, Lucy --_000_143097773112137704ecitelecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lucy,

Lots of thanks for a prompt and= very detailed review.

Please see my personal comments= (I did not discuss them with other authors yet) on some of your proposals = for simplification inline below.

Regards,

Sasha

________________________________________

From: Lucy yong <lucy.yong@huawei.com>

Sent: Thursday, May 7, 2015 1:39 AM

To: draft-mirsky-mpls-residence-time@tools.ietf.org; mpls-chairs@tools.i= etf.org

Cc: mpls@ietf.org

Subject: RE: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

Hi All,

I reviewed draft-mirsky-mpls-residence-time as the member of MPLS Review= Team and have the following comments:

is the document coherent?

Yes. It specifies how MPLS supports residence time measurement.

is it useful (ie, is it likely to be actually useful in operational netw= orks)?

The document claims that such measurement can improve the accuracy of cl= ock synchronization across the network. I am not an operator and author and= not sure how useful this feature provides compared to the complexity addin= g to.

is the document technically sound?

Yes. The draft provides a detail solution in control plane and data plan= e to achieve this purpose.

is the document ready to be considered for WG adoption?

Yes. The document states the problem clearly and provides a solution to = address this problem.

IMHO:  after adopting it as the WG draft, the WG should further eva= luate if control plane and data plane solution can be simplified. The areas= may be considered:

1) Do we have to use IGP to announce node RTM capability? Can RSVP-TE re= solve the issue by itself?

[[Sasha]] I do not = think so. One of the benefits of distributing RTM capabilities with IGP is = that the CSPF algorithm can compute an explicit path to the tail-end node t= hat minimizes the number of transit nodes that are not RTM-capable. This minimization, in its turn, makes cloc= k synchronization more accurate since the influence of residence time in ea= ch of the transit nodes on the clock of synchronization is minimized (and p= otentially completely eliminated).

I do not see how RSVP-TE = could provide this functionality all by itself, but I may be missing someth= ing.

2) Will possible to enhance RRO to serve RSO purpose instead of carrying= both RRO and RSO in the message?

[[Sasha]] This is p= robably possible, but may affect backward compatibility with nodes that do = not support RTM (or at least make it more complicated) <= /span>

3) Since this feature is designed for the LSP that is used for clock syn= chronization, such LSPs are not majority, so it should be option in LSP set= up. Make that very clear.<= em>[[Sasha]] I fully agree. 

4) two-step clock mode is quite complex. The description in Section 7 is= not clear to me why this mode is necessary.

[[Sasha]] I fully a= gree with you that 2-step clock is quite complex. However, it is quite usef= ul if forwarding HW is not capable of modifying the packet that is transmit= ted via one of its ports very close to the moment when it is actually transmitted (definitely after it has bee= n extracted from the egress queue for transmission). The 2-step clock addre= sses this issue by limiting the HW functionality to just taking the ti= mestamp at this moment (much simpler!) and passing it to SW  handling so that, e.g., it can be inserted into= the so-called "follow-up" packet.

Not sure if this ex= planation really helps.

Regards,

Lucy

--_000_143097773112137704ecitelecom_-- From nobody Thu May 7 12:05:48 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5F91A8847 for ; Thu, 7 May 2015 12:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 D7gtnKCUyDOQ for ; Thu, 7 May 2015 12:05:46 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.3]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21791A882D for ; Thu, 7 May 2015 12:05:45 -0700 (PDT) Received: from [216.82.250.99] by server-3.bemta-12.messagelabs.com id 6C/C3-26447-987BB455; Thu, 07 May 2015 19:05:45 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-16.tower-126.messagelabs.com!1431025544!15232862!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12952 invoked from network); 7 May 2015 19:05:45 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-16.tower-126.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2015 19:05:45 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id C106C1F694 for ; Thu, 7 May 2015 19:05:44 +0000 (GMT) Received: from USADCWVEHT01.corp.global.level3.com (10.2.36.141) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 May 2015 13:05:44 -0600 Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by usadcwveht01.corp.global.level3.com ([::1]) with mapi id 14.03.0210.002; Thu, 7 May 2015 15:05:43 -0400 From: "Osborne, Eric" To: "mpls@ietf.org" Thread-Topic: Question on the wording in section 3 of draft-ietf-mpls-seamless-mcast Thread-Index: AdCI+LZvUi1dPGp4SRKZspxSakqu7w== Date: Thu, 7 May 2015 19:05:42 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD1A2368BD@USIDCWVEMBX03.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.141.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [mpls] Question on the wording in section 3 of draft-ietf-mpls-seamless-mcast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:05:47 -0000 Note: I sent this to draft-ietf-mpls-seamless-mcast@ietf.org but got some w= eird bounce so I'm not sure if it made it through. Section 3, bottom of p. 5 and into p. 6: "One possible way to support the global table multicast service is by relying on the MVPN procedures, as specified in [RFC6514], in which case the MVPN procedures specified in this[1] document would be used to support the global table multicast service. This[2] document specifies an alternative approach to support the global table multicast service." Does [1] refer to rfc6514 and [2] refer to draft-ietf-mpls-seamless-mcast? = =20 Does draft-ietf-mpls-seamless-mcast specify two approaches to global table = multicast and use both of the 'this' to refer to itself? eric From nobody Mon May 11 15:19:25 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD9F1A90BA; Mon, 11 May 2015 15:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 iyctjbJvDtEZ; Mon, 11 May 2015 15:19:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 89F901A90CF; Mon, 11 May 2015 15:18:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A103180209; Mon, 11 May 2015 15:17:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150511221702.1A103180209@rfc-editor.org> Date: Mon, 11 May 2015 15:17:02 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7537 on IANA Registries for LSP Ping Code Points X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:19:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7537 Title: IANA Registries for LSP Ping Code Points Author: B. Decraene, N. Akiya, C. Pignataro, L. Andersson, S. Aldrin Status: Standards Track Stream: IETF Date: May 2015 Mailbox: bruno.decraene@orange.com, nobo.akiya.dev@gmail.com, cpignata@cisco.com, loa@mail01.huawei.com, aldrin.ietf@gmail.com Pages: 7 Characters: 11895 Updates: RFC 4379, RFC 6424 I-D Tag: draft-ietf-mpls-lsp-ping-registry-03.txt URL: https://www.rfc-editor.org/info/rfc7537 RFCs 4379 and 6424 created name spaces for Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for Downstream Mapping object Flags (DS Flags), Multipath Types, Pad TLVs, and Interface and Label Stack Address Types. There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose. This document is a product of the Multiprotocol Label Switching 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/rfc.html 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 Tue May 12 05:21:19 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0711A6F27 for ; Tue, 12 May 2015 05:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 D13kfekw9ZUr for ; Tue, 12 May 2015 05:21:13 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67081A1A62 for ; Tue, 12 May 2015 05:21:12 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BEC6118013E6; Tue, 12 May 2015 14:21:10 +0200 (CEST) Message-ID: <5551F035.9060505@mail01.huawei.com> Date: Tue, 12 May 2015 14:21:09 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , Mach Chen , River Huang , Praveen Maheshwari , JiangTao Hao , "huubatwork@gmail.com" , "Aissaoui, Mustapha (Mustapha)" References: <20150512115837.15572.20077.idtracker@ietfa.amsl.com> In-Reply-To: <20150512115837.15572.20077.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------090200000104090308040209" Archived-At: Subject: Re: [mpls] New Version Notification for draft-hao-mpls-ip-hard-pipe-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:21:17 -0000 This is a multi-part message in MIME format. --------------090200000104090308040209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Working Group. draft-hao-mpls-ip-hard-pipe is a document intended to be published as and Independent RFC. We have just posted version -02, after the review initiated by the ISE. The reviewers were Huub and Mustapha. We have included responses to their comments (see text file). We have also fixed grammar and a number of typos. /Loa On 2015-05-12 13:58, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-hao-mpls-ip-hard-pipe-02.txt > has been successfully submitted by Loa Andersson and posted to the > IETF repository. > > Name: draft-hao-mpls-ip-hard-pipe > Revision: 02 > Title: Architecture of MPLS/IP Network with Hardened Pipes > Document date: 2015-05-12 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-hao-mpls-ip-hard-pipe-02.txt > Status: https://datatracker.ietf.org/doc/draft-hao-mpls-ip-hard-pipe/ > Htmlized: https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-hao-mpls-ip-hard-pipe-02 > > Abstract: > This document is intended to become an Informational RFC on the > independent stream. The document does not specify any new protocol > or procedures. It does explain how the MPLS standards > implementation, has been deployed and operated to meet the > requirements from operators that offer traditional Virtual Leased > Line services. > > This document describes an MPLS/IP network that has an infrastructure > that can be separated into two or more strata. For the > implementation described in this document the infrastructure has been > separated into two strata. One for the 'Hard Pipes', called the > 'Hard Pipe Stratum". And one for the normal IP/MPLS traffic - called > the 'Normal IP/MPLS stratum'. > > This document introduces the concept of "Hard Pipes", a Hard Pipe is > an MPLS Label Switched Path (LSP) or a Pseudowire (PW) with a > bandwidth that is guaranteed and can neither be exceeded nor > infringed upon. > > The Hard Pipe stratum does not use statistical multiplexing, for the > LSPs and PWs setup within this stratum the bandwidth are guaranteed > end to end. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > . > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --------------090200000104090308040209 Content-Type: text/plain; charset=windows-1252; name="hard-comments-pa3.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hard-comments-pa3.txt" ICAgICBSZXNwb25zZXMgdG8gdGhlIEluZGVwZW5kZXQgU3RyZWFtIHJldmlld2VycyBjb21t ZW50cyBvbiANCiAgICAgICAgICAgICAgICAgZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBl LTAxDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NClJldmlld2VyOiBIdXViIHZhbiBIZWx2b29ydCAobWFp bCB0byBhdXRob3JzIGFuZCBJU0UgT2N0IDIwMTQpDQoNCjEtMSBBZGQgRXRoZXJuZXQgTGVh c2VkIExpbmVzIGFzIGFuIGV4YW1wbGUgaW4gdGhlIEludHJvZHVjdGlvbi4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KT0xEDQogICBJUCBsZWFzZWQgbGluZSBzZXJ2aWNlcyBhbmQgVGltZSBEaXZpc2lv biBNdWx0aXBsZXggKFRETSkgbGVhc2VkIGxpbmUNCiAgIHNlcnZpY2VzIGFyZSBjb21tb25s eSBvZmZlcmVkIGJ5IG9wZXJhdG9ycyB3b3JsZHdpZGUuDQpORVcNCiAgIElQIGxlYXNlZCBs aW5lIHNlcnZpY2VzLCBFdGhlcm5ldCBQcml2YXRlIExpbmUgKEVQTCkgYW5kIFRpbWUgDQog ICBEaXZpc2lvbiBNdWx0aXBsZXggKFRETSkgbGVhc2VkIGxpbmUNCiAgIHNlcnZpY2VzIGFy ZSBjb21tb25seSBvZmZlcmVkIGJ5IG9wZXJhdG9ycyB3b3JsZHdpZGUuDQoNClN0YXR1czog QWNjZXB0ZWQuIEluY2x1ZGVkLg0KDQoxLTIgRWRpdG9yaWFsIGNoYW5nZSBpbiAybmQgcGFy YWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rpb24NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT0xEDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVGhleSBkbyBzbyByZWdhcmRsZXNzIG9mIHRoYXQgdGhlIHNhbWUN CiAgIG9wZXJhdG9ycyBvZnRlbiBvZmZlciBJUCBsZWFzZWQgbGluZSBzZXJ2aWNlcyB0byBh IGxvd2VyIHByaWNlIGFuZA0KICAgd2l0aCBhIGd1YXJhbnRlZWQgYmFuZHdpZHRoLg0KDQpO RVcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICBUaGV5IGRvIHNvIHJlZ2FyZGxlc3Mg b2YgdGhlIGZhY3QgdGhhdCB0aGUgc2FtZQ0KICAgb3BlcmF0b3JzIG9mdGVuIG9mZmVyIElQ IGxlYXNlZCBsaW5lIHNlcnZpY2VzLCBhbmQgRVBMIHNlcnZpY2VzLCBhdCBhDQogICBsb3dl ciBwcmljZSBhbmQgd2l0aCBhIGd1YXJhbnRlZWQgYmFuZHdpZHRoLg0KDQpTdGF0dXM6IEFj Y2VwdGVkLiBJbmNsdWRlZC4NCg0KMS0zIENsYXJpZmljYXRpb24gb2YgdGhpcmQgcGFyYWdy YXBoIGluIGludHJvZHVjdGlvbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KT0xEDQogICBUb2RheSB3ZSBzZWUgYSB0cmVuZCB0aGF0 IHRoZSBURE0gbmV0d29ya3MgZ3JhZHVhbGx5IGNhcnJpZXMgbGVzcyAgYW5kDQogICBsZXNz IHRyYWZmaWMsIA0KDQpORVcNCiAgIFRvZGF5IHdlIHNlZSBhIHRyZW5kIHRoYXQgdGhlIFRE TSAoaW4gcGFydGljdWxhciBTREgvU09ORVQpIG5ldHdvcmtzIA0KICAgZ3JhZHVhbGx5IGNh cnJpZXMgbGVzcyBhbmQgbGVzcyB0cmFmZmljLCANCg0KU3RhdHVzOiBBY2NlcHRlZC4gSW5j bHVkZWQuDQoNCjEtNCBFZGl0b3JpYWwgdXBkYXRlIHRvIDR0aCBwYXJhZ3JhcGggb2YgdGhl IEludHJvZHVjdGlvbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9MRA0KICAgVGhlIG9wZXJhdG9ycyBhbmQgdmVuZG9y cyB0aGF0IGJ1aWx0IGFuZCBkZXBsb3llZCB0aGUgSGFyZCBQaXBlDQogICBzZXJ2aWNlIGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGRpZCBzbyByZWNvZ25pemluZw0KTkVXDQogICBU aGUgb3BlcmF0b3JzIGFuZCB2ZW5kb3JzIHRoYXQgYnVpbHQgYW5kIGRlcGxveSB0aGUgSGFy ZCBQaXBlDQogICBzZXJ2aWNlIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGRvIHNvIHJl Y29nbml6aW5nIA0KDQpTdGF0dXM6IEFjY2VwdGVkLiBJbmNsdWRlZC4NCg0KMS01IEVQTCBh bmQgRVBMQU4gb3V0IG9mIFNjb3BlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGF0IHRoZSBlbmQgb2YgNXRoIHBhcmFnYXJw aCBvZiB0aGUgDQppbnRyb2R1Y3Rpb24uDQoNCiAgIEVQTCBhbmQgRVBMQU4gKEV0aGVybmV0 IFByaXZhdGUgTEFOKSBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzDQogICBkb2N1bWVudC4N Cg0KU3RhdHVzOiBBY2NlcHRlZCEgSW5jbHVkZWQuDQoNCjEtNiBHcmFtbWFyIGNvcnJlY3Rp b24gb2YgdGhlIDV0aCBwYXJhZ3JhcGggb2YgdGhlIEludHJvZHVjdGlvbg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpPTEQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2hlbiBndWFyYW50 ZWVkIGJhbmR3aWR0aCBhcmUgdGhlDQogICBwcmlvcml0eSBWaXJ0dWFsIFByaXZhdGUgV2ly ZSBTZXJ2aWNlcyAoVlBXUyksIC4uLg0KDQpORVcgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFdoZW4gZ3VhcmFudGVlZCBiYW5kd2lkdGggaXMgdGhlDQogICBwcmlv cml0eSBWaXJ0dWFsIFByaXZhdGUgV2lyZSBTZXJ2aWNlcyAoVlBXUyksIC4uLg0KDQpTdGF0 dXM6IEFjY2VwdGVkLiBJbmNsdWRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCjEtNyBHcmFt bWFyIGFuZCB0eXBvIGluIHRoZSBmaXJzdCBwYXJhZ2FyYXBoIG9mIFNlY3Rpb24gMg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCk9MRA0KICAgVGhlIGNvbmNlcHQgb2Ygc3RyYXRpZmllZCBvciBzdHJhdGEgbmV0d29y a3MgaGFzIGJlZW4gYXJvdW5kIGZvciBzb21lDQogICB0aW1lLiAgSXQgaGFzIGNvbWUgdG8g aGF2ZSBkaWZmZXJlbnQgbWVhbmluZyBpbiBkaWZmZXJlbnQgY29udGV4dHMuDQogICBUaGUg d2F5IHdlIHVzZSB0aGUgY29uY2VwdCBpcyB0aGF0IHdlIGxvZ2ljYWxseSBhc3NpZ24gY2Vy dGFpbg0KICAgY2hhcmFjdGVyaXN0aWNzIHRvIHBhcnQgb2YgdGhlIG5ldHdvcmsuICBUaGUg cGFydCBvZiB0aGUgbmV0d29yayB0aGF0DQogICBoYXMgdGhlIHNwZWNpYWwgY2hhcmFjdGVy aXN0aWNzIGZyb20gb25lIHN0cmF0dW0gYW5kIHRoZSAicmVtaW5kZXIgIiBhDQogICBzZWNv bmQgc3RyYXR1bS4gIFRoZSBuZXR3b3JrIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IHVz ZXMgYSBzaW5nbGUNCiAgIGxpbmsgbGF5ZXIgdGVjaG5vbG9neTogRXRoZXJuZXQuDQoNCk5F Vw0KICAgVGhlIGNvbmNlcHQgb2Ygc3RyYXRpZmllZCBvciBzdHJhdGEgbmV0d29ya3MgaGFz IGJlZW4gYXJvdW5kIGZvciBzb21lDQogICB0aW1lLiAgSXQgYXBwZWFycyB0byBoYXZlIGRp ZmZlcmVudCBtZWFuaW5nIGluIGRpZmZlcmVudCBjb250ZXh0cy4NCiAgIFRoZSB3YXkgd2Ug dXNlIHRoZSBjb25jZXB0IGlzIHRoYXQgd2UgbG9naWNhbGx5IGFzc2lnbiBjZXJ0YWluDQog ICBjaGFyYWN0ZXJpc3RpY3MgdG8gcGFydCBvZiB0aGUgbmV0d29yay4gIFRoZSBwYXJ0IG9m IHRoZSBuZXR3b3JrIHRoYXQNCiAgIGhhcyB0aGUgc3BlY2lhbCBjaGFyYWN0ZXJpc3RpY3Mg Zm9ybSBvbmUgc3RyYXR1bSBhbmQgdGhlICJyZW1haW5kZXIgIiBhDQogICBzZWNvbmQgc3Ry YXR1bS4gIFRoZSBuZXR3b3JrIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IHVzZXMgYSBz aW5nbGUNCiAgIGxpbmsgbGF5ZXIgdGVjaG5vbG9neSwgRXRoZXJuZXQuDQoNClN0YXR1czog QWNjZXB0ZWQuIEluY2x1ZGVkLg0KDQoxLTggR3JhbW1hciAybmQgcGFyYWdyYXBoIHNlY3Rp b24gMg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KT0xEDQoNCiAg IEluIG1hbnkgY2FzZXMsIGEgd2hvbGUgcGh5c2ljYWwgaW50ZXJmYWNlIGlzIGFzc2lnbmVk IHRvIGhhcmQNCiAgIHN0cmF0dW0uICBFc3BlY2lhbGx5IGluIHRoZSBzY2VuYXJpbyB0aGF0 IHRoZXJlIGFyZSBtYW55IHBoeXNpY2FsDQogICBsaW5rcyBiZXR3ZWVuIHR3byBub2Rlcy4N Cg0KTkVXDQoNCiAgIEluIG1hbnkgY2FzZXMsIGEgd2hvbGUgcGh5c2ljYWwgaW50ZXJmYWNl IGlzIGFzc2lnbmVkIHRvIGEgc2luZ2xlDQogICBoYXJkIHN0cmF0dW0uICBFc3BlY2lhbGx5 IGluIHRoZSBzY2VuYXJpbyB0aGF0IHRoZXJlIGFyZSBtYW55IHBoeXNpY2FsDQogICBsaW5r cyBiZXR3ZWVuIHR3byBub2Rlcy4NCg0KU3RhdHVzOiBBY2NlcHRlZC4gSW5jbHVkZWQuDQog ICAgICAgIERvIHdlIHdhbnQgdG8gcnVuIG1vcmUgdGhhbiBvbmUgaGFyZCBzdHJhdW0gb24g dGhlIHNhbWUgbm9kZQ0KICAgICAgICBvciBsaW5rPw0KDQpXZSBoYXZlIGFsc28gYWRkZWQg dGhpcyBmb3IgY2xhcmlmaWNhdGlvbg0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGFk ZHJlc3MgdGhlIG5ldHdvcmsgY29uZmlndXJhdGlvbg0KICAgcG9zc2liaWxpdGllcyBmb3Ig SGFyZCBQaXBlIGFuZCBJUC9NUExTIHN0cmF0YSBpbiBkZXRhaWwuDQogICBUaGVyZSBhcmUg Y29uZmlndXJhdGlvbiBvcHRpb25zLCB0aGUgYmFzaWMgY29uZmlndXJhdGlvbiBpcw0KICAg dGhhdCBvbmUgSGFyZCBQaXBlIHN0cmF0dW0gYW5kIG9uZSBJUC9NUExTIHN0cmF0dW0gYXJl DQogICBwcm92aXNpb25lZC4NCg0KICAgSG93ZXZlciBpdCBpcyBhbHNvIHBvc3NpYmxlIHRv IHByb3Zpc2lvbiBtb3JlIHRoYW4gb25lIEhhcmQNCiAgIFBpcGUgc3RyYXR1bSwgZS5nLiBp ZiBjdXN0b21lcnMgd2FudCBlbmhhbmNlZCBzZXBhcmF0aW9uIGZvcg0KICAgdGhlaXIgbGVh c2VkIGxpbmUuIEV2ZW4gdGhvdWdoIHRoZSBtYWluIGRyaXZlciBmb3IgdGhlIEhhcmQNCiAg IFBpcGUgdGVjaG5vbG9neSBpcyB0aGUgdGhlIGxlYXNlZCBsaW5lcywgYW55IHNlcnZpY2Ug dGhlcmUgYW4NCiAgIG9wZXJhdG9yIG5vdCB3YW50IHRvIHVzZSBzdGF0aXN0aWNhbCBtdWx0 aXBsZXhpbmcgd2lsbCBiZW5lZml0DQogICBmcm9tIHVzaW5nIHRoZSBIYXJkIFBpcGVzLiAN Cg0KMS05IEZpcnN0IHBhcmFncmFwaCBzZWN0aW9uIDIuMg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KT0xEDQogICBXZSBub3cgd2lzaCB0byB0byBkZWZpbmUgYSBIYXJk IFBpcGUgc3RyYXR1bSwgaS5lLiBhIHBhcnQgb2YgdGhlDQogICBuZXR3b3JrIHRoYXQgdHJl YXRzIGFsbCBwYWNrZXRzIHdpdGhvdXQgaW50cm9kdWNpbmcgYW55IGRlbGF5Lg0KDQpORVcN CiAgIChyZW1vdmUgdGhlIHBhcmFncmFwaCkuDQoNCkNoYW5nZSB0aGUgbmV4dCBwYXJhZ3Jh cGggbGlrZSB0aGlzDQoNCiAgIFdoZW4gdGhlIGludGVudGlvbnMgaXMgdG8gZGVmaW5lIGEg SGFyZCBQaXBlIHN0cmF0dW0sIGl0IGlzIGZvciANCiAgIGV4YW1wbGUgcG9zc2libGUgdG8g c3RhcnQgZnJvbSBhbiBlc3RpbWF0ZWQgdHJhZmZpYyBtYXRyaXggdG8gDQogICBlc3RpbWF0 ZSBob3cgbXVjaCBiYW5kd2lkdGggdG8gcmVzZXJ2ZSBvbiB0aGUgbGlua3Mgb2YgdGhlIA0K ICAgRXRoZXJuZXQgTGluayBMYXllciBuZXR3b3JrIGZvciB0aGUgSGFyZCBQaXBlcy4NCg0K DQpTdGF0dXM6IFByb3Bvc2VkDQoxLTEwIEdyYW1tYXIgM3JkIHBhcmFncmFwaCBzZWN0aW9u IDIuMg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KT0xEDQog ICAiLi4udGhhdCBoZSBub3JtYWwgdHJhZmZpYyBnZXQgdGhlLi4uIg0KDQpORVcNCiAgICIu Li50aGF0IGhlIG5vcm1hbCB0cmFmZmljIGdldHMgdGhlLi4uIg0KDQpTdGF0dXM6IEFjY2Vw dGVkLiBJbmNsdWRlZC4NCg0KDQoxLTExIExhbmd1YWdlIDFzdCBwYXJhZ3JhcGggc2VjdGlv biAyLjQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9M RA0KICAgU3RyYXR1bSBuZXR3b3JrcyBhcyB1c2UgdGhlIGNvbmNlcHQgY2FuIGJlIHNlZW4g YXMgdHdvIGJhc2ljYWxseS4uDQoNCkhVVUINCiAgIFN0cmF0dW0gbmV0d29ya3MgaW4gdGhl IHdheSB3ZSB1c2UgdGhlIGNvbmNlcHQgY2FuIGJlIHNlZW4gYXMgDQogICB0d28gYmFzaWNh bGx5Li4uDQoNCk5FVw0KICAgU3RyYXR1bSBuZXR3b3JrcyB0aGUgd2F5IHdlIHVzZSB0aGUg Y29uY2VwdCBjYW4gYmUgc2VlbiBhcyB0d28gDQogICBiYXNpY2FsbHkuLi4NCg0KU3RhdHVz OiBBY2NlcHRlZC4gSW5jbHVkZWQNCg0KDQoNCjEtMTEgU3ViLXN1Yi1idWxsZXQgb2YgdGhl IGZpcnN0IGJ1bGxldCBvZiBzZWN0aW9uIDMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9MRA0KICAgICAgICAgKyAgaWYgc3VjaCBh IHR1bm5lbCBleGlzdHMsIGl0IGlzIHVzZWQgdG8gZXN0YWJsaXNoIHRoZSBsZWFzZWQNCiAg ICAgICAgICAgIGxpbmUgYnkgYWRkaW5nIEwtbGFiZWxzIGZvcm1pbmcgYW4gTFNQIHRoYXQg YXJlIGNhcnJpZWQgYnkNCiAgICAgICAgICAgIHRoZSB0dW5uZWwuICBMLWxhYmVscyBhcmUg b25sdCB1bmRlcnN0b29kIGtub3cgYnkgdGhlDQogICAgICAgICAgICBpbmdyZXNzIGFuZCBl Z3Jlc3MgTFNScy4gIFRoZXkgbG9jYWwgdG8gdGhlIGVuZCBwb2ludHMgdGhlDQogICAgICAg ICAgICBzYW1lIHdheSBhcyBsYWJlbCBzaWduYWxsZWQgYnkgVGFyZ2V0ZWQgTERQICh0TERQ KSBbUkZDNTAzNl0NCiAgICAgICAgICAgIGFyZSBsb2NhbCB0aGUgZW5kIHBvaW50cyBvZiBh IHRhcmdldGVkIHNlc3Npb24gTFNQLg0KDQpIVVVCDQoNCiAgICAgICAgICsgIGlmIHN1Y2gg YSB0dW5uZWwgZXhpc3RzLCBpdCBpcyB1c2VkIHRvIGVzdGFibGlzaCB0aGUgbGVhc2VkDQog ICAgICAgICAgICBsaW5lIGJ5IGFkZGluZyBMLWxhYmVscyBmb3JtaW5nIGFuIExTUCB0aGF0 IGFyZSBjYXJyaWVkIGJ5DQogICAgICAgICAgICB0aGUgdHVubmVsLiAgTC1sYWJlbHMgYXJl IG5vdyB1bmRlcnN0b29kIG9ubHkgYnkgdGhlDQogICAgICAgICAgICBpbmdyZXNzIGFuZCBl Z3Jlc3MgTFNScy4gIFRoZXkgYXJlIGxvY2FsIHRvIHRoZSBlbmQgcG9pbnRzIHRoZQ0KICAg ICAgICAgICAgc2FtZSB3YXkgYXMgdGhlIGxhYmVsIHNpZ25hbGxlZCBieSBUYXJnZXRlZCBM RFAgKHRMRFApIFtSRkM1MDM2XQ0KICAgICAgICAgICAgYXJlIGxvY2FsIHRvIHRoZSBlbmQg cG9pbnRzIG9mIGEgdGFyZ2V0ZWQgc2Vzc2lvbiBMU1AuDQoNCk5FVw0KICAgICAgICAgKyAg aWYgc3VjaCBhIHR1bm5lbCBleGlzdHMsIGl0IGlzIHVzZWQgdG8gZXN0YWJsaXNoIHRoZSBs ZWFzZWQNCiAgICAgICAgICAgIGxpbmUgYnkgYWRkaW5nIEwtbGFiZWxzIGZvcm1pbmcgYW4g TFNQIHRoYXQgYXJlIGNhcnJpZWQgYnkNCiAgICAgICAgICAgIHRoZSB0dW5uZWwuICBMLWxh YmVscyBhcmUga25vd24gb25seSBvbmx5IGJ5IHRoZQ0KICAgICAgICAgICAgaW5ncmVzcyBh bmQgZWdyZXNzIExTUnMuICBUaGV5IGFyZSBsb2NhbCB0byB0aGUgZW5kIHBvaW50cyB0aGUN CiAgICAgICAgICAgIHNhbWUgd2F5IGFzIHRoZSBsYWJlbCBzaWduYWxsZWQgYnkgVGFyZ2V0 ZWQgTERQICh0TERQKSBbUkZDNTAzNl0NCiAgICAgICAgICAgIGFyZSBsb2NhbCB0byB0aGUg ZW5kIHBvaW50cyBvZiBhIHRhcmdldGVkIHNlc3Npb24gTFNQLg0KDQpTdGF0dXM6IEFjY2Vw dGVkLiBJbmNsdWRlZC4NCg0KMS0xMiBTZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMywg KGFmdGVyIHRoZSBidWxsZXRzKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPTEQNCiAgIFRodXMsIGdpdmVuIHRoZSBleGlz dGluZyBvZiBhIHZpYWJsZSBIYXJkIFBpcGUgc3RyYXR1bSwgTGVhc2VkIA0KICAgTGluZXMu Li4NCg0KSFVVQg0KICAgVGh1cywgZ2l2ZW4gdGhlIGV4aXN0YW5jZSBvZiBhIHZpYWJsZSBI YXJkIFBpcGUgc3RyYXR1bSwgTGVhc2VkIA0KICAgTGluZXMuLi4NCg0KTkVXDQogICBUaHVz LCBnaXZlbiB0aGUgZXhpc3RlbmNlIG9mIGEgdmlhYmxlIEhhcmQgUGlwZSBzdHJhdHVtLCBM ZWFzZWQgDQogICBMaW5lcy4uLg0KDQpTdGF0dXM6IEFjY2VwdGVkLiBJbmNsdWRlZA0KDQoN Cg0KMS0xMyBHcmFtbWFyIGZpcnN0IHBhcmFncmFwaCBzZWN0aW9uIDQuMQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT0xEDQogICBUaGUgb25seSBjb25m aWd1cmVkIGluZm9ybWF0aW9uIHRoYXQgYXJlIGFjdHVhbGx5IGtlcHQgb24gDQogICB0aGUg TFNScyBhcmUuLi4NCg0KTkVXDQogICBUaGUgb25seSBjb25maWd1cmVkIGluZm9ybWF0aW9u IHRoYXQgaXMgYWN0dWFsbHkga2VwdCBvbiB0aGUgTFNScw0KICAgaXMuLi4NCg0KU3RhdHVz OiBBY2NlcHRlZC4gSW5jbHVkZWQuDQoNCg0KMS0xNCBHcmFtbWFyIDFzdCBwYXJhZ3JhcGgg c2VjdGlvbiA0LjMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpPTEQNCiAgIFRoZSBhbm5vdGF0aW9ucyBnaXZlbiBiZWxvdyBhcmUgbm90IGEgcHJvZ3Jh bW1pbmcgZ3VpZGVsaW5lIG9yIGFuDQogICBpbmRpY2F0aW9uIGhvdyB0aGlzIGFyY2hpdGVj dHVyZSBjb3VsZCBiZSBpbXBsZW1lbnRlZC4gIEl0IGlzIA0KICAgcmF0aGVyIGFuIGluZGlj YXRpb24gb2YgaG93IG11Y2ggZGF0YSB0aGF0IG5lZWRzIHRvIGJlLi4uDQoNCk5FVw0KICAg VGhlIGFubm90YXRpb25zIGdpdmVuIGJlbG93IGFyZSBuZWl0aGVyIGEgcHJvZ3JhbW1pbmcg Z3VpZGVsaW5lIA0KICAgbm9yIGFuIGluZGljYXRpb24gaG93IHRoaXMgYXJjaGl0ZWN0dXJl IGNvdWxkIGJlIGltcGxlbWVudGVkLiBJdCANCiAgIGlzIHJhdGhlciBhbiBpbmRpY2F0aW9u IG9mIGhvdyBtdWNoIGRhdGEgbmVlZHMgdG8gYmUuLi4NCg0KU3RhdHVzOiBBY2NlcHRlZC4g SW5jbHVkZWQuDQoNCg0KMS0xNSBHcmFtbWFyIDJuZCBwYXJhZ3JhcGggc2VjdGlvbiA0LjMN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPTEQNCiAgIENvbnNp ZGVyIHRoZSBIYXJkIFBpcGUgc3RyYXR1bSBhcyBpdCBoYXMgYmVlbiBvdXRsaW5lIGluIEZp Z3VyZSAyLA0KICAgYWN0dWFsbHkgdGhlcmUgaXMgc29tZSBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIHJlbGF0ZWQgdG8gdGhlIEhhcmQNCiAgIFBpcGUgU3RyYXR1bSB0aGF0IG5vdCBpcyBz aG93biBpbiB0aGUgZmlndXJlLg0KDQpORVcNCiAgIENvbnNpZGVyaW5nIHRoZSBIYXJkIFBp cGUgc3RyYXR1bSBhcyBpdCBoYXMgYmVlbiBvdXRsaW5lIGluIEZpZ3VyZSAyLA0KICAgdGhl cmUgaXMgYWN0dWFsbHkgc29tZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8g dGhlIEhhcmQNCiAgIFBpcGUgU3RyYXR1bSB0aGF0IG5vdCBpcyBzaG93biBpbiB0aGUgZmln dXJlLg0KDQpTdGF0dXM6IEFjY2VwdGVkLiBJbmNsdWRlZC4NCg0KMS0xNiBHcmFtbWFyIDR0 aCBwYXJhZ3JhcGggc2VjdGlvbiA0LjMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KT0xEDQogICBUaGUgYW5ub3RhdGlvbiBbNCwwXUcgbWVhbnMgdGhhdCB0 aGUgYmFuZHdpZHRoIG9uIHRoZSBsaW5rIGJldHdlZW4gSg0KICAgYW5kIEsgdGhlcmUgYXJl IDRHIGFsbG9jYXRlZCB0byB0aGUgc3RyYXR1bSBhbmQgb2YgdGhlc2UgMEcgaGFzIGJlZW4N CiAgIGFsbG9jYXRlZCB0byBhIHNlcnZpY2UuDQoNCk5FVw0KICAgVGhlIGFubm90YXRpb24g WzQsMF1HIG1lYW5zIHRoYXQgdGhlIGJhbmR3aWR0aCBvbiB0aGUgbGluayBiZXR3ZWVuIEoN CiAgIGFuZCBLIHRoZXJlIGlzIDRHIGFsbG9jYXRlZCB0byB0aGUgc3RyYXR1bSBhbmQgb2Yg dGhlc2UgMEcgaGFzIGJlZW4NCiAgIGFsbG9jYXRlZCB0byBhIHNlcnZpY2UuDQoNClN0YXR1 czogQWNjZXB0ZWQuIEluY2x1ZGVkLg0KDQoNCjEtMTcgR3JhbW1hciAxMHRoIHBhcmFncmFw aCBzZWN0aW9uIDQuMw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9M RA0KICAgVGhlIEhhcmQgUGlwZSBTdHJhdHVtIGxpbmsgYmV0d2VlbiBub2RlcyBKIGFuZCBL IGhhcyA0IEcgYmFuZHdpZHRoDQogICBhbGxvY2F0ZWQ7IG9mIHRoZSB0b3RhbCBiYW5kd2lk dGggMS41IEcgYXJlIGFsbG9jYXRlZCBmb3IgTGVhc2VkDQogICBMaW5lcy4NCg0KTkVXDQog ICBUaGUgSGFyZCBQaXBlIFN0cmF0dW0gbGluayBiZXR3ZWVuIG5vZGVzIEogYW5kIEsgaGFz IDQgRyBiYW5kd2lkdGgNCiAgIGFsbG9jYXRlZDsgb2YgdGhlIHRvdGFsIGJhbmR3aWR0aCAx LjUgRyBpcyBhbGxvY2F0ZWQgZm9yIExlYXNlZA0KICAgTGluZXMuDQoNClN0YXR1czogQWNj ZXB0ZWQuIEluY2x1ZGVkLg0KDQoNCjEtMTggVHlwbyA0dGggcHJhZ3JhcGggc2VjdGlvbiA1 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT0xEDQogICAiLi4uKGF2YWlh YmxlIGJhbmR3aWR0aCkgd291bGQuLi4NCg0KTkVXIA0KICAgIi4uLihhdmFpbGFibGUgYmFu ZHdpZHRoKSB3b3VsZC4uLiINCg0KU3RhdHVzOiBBY2NlcHRlZC4gSW5jbHVkZWQuDQoNCg0K DQoxLTE5IExhbmd1YWdlIHBhcmFncmFwaCA1IHNlY3Rpb24gNQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KT0xEDQogICBJZiB0aGUgb3BlcmF0b3Igbm93IHdp c2hlcyB0byBlc3RhYmxpc2ggYSBuZXcgbGVhc2VkIGxpbmUgd2l0aCB0aGUNCiAgIGNyaXRl cmlhIHRoYXQgaXQgc2hvdWxkIG9yaWdpbmF0ZSBmcm9tIEYgYW5kIHRlcm1pbmF0ZSBhdCBH LCBoYXZlDQogICAwLjRHIGJhbmR3aWR0aCBhbmQgcGFzcyB0aHJvdWdoIG5vZGUgRSwgYW5h bHlzaXMgb2YgdGhlIEhhcmQgUGlwZQ0KICAgc3RyYXR1bSAoYWZ0ZXIgZXN0YWJsaXNoaW5n IHRoZSBmaXJzdCB0d28gbGlzdGVkIGxpbmVzKSBhbmQgdGhlDQogICBjcml0ZXJpYSBmb3Ig dGhlIG5ldyBsZWFzZWQgbGluZSB3b3VsZCBnaXZlIHRoZSBmb2xsb3dpbmc7DQoNCk5FVw0K ICAgSWYgdGhlIG9wZXJhdG9yIG5vdyB3aXNoZXMgdG8gZXN0YWJsaXNoIGEgbmV3IGxlYXNl ZCBsaW5lIHdpdGggdGhlDQogICByZXF1aXJlbWVudHMgdGhhdCBpdCBzaG91bGQgb3JpZ2lu YXRlIGZyb20gRiBhbmQgdGVybWluYXRlIGF0IEcsIGhhdmUNCiAgIDAuNEcgYmFuZHdpZHRo IGFuZCBwYXNzIHRocm91Z2ggbm9kZSBFLCBhbmFseXNpcyBvZiB0aGUgSGFyZCBQaXBlDQog ICBzdHJhdHVtIChhZnRlciBlc3RhYmxpc2hpbmcgdGhlIGZpcnN0IHR3byBsaXN0ZWQgbGlu ZXMpIGFuZCB0aGUNCiAgIHJlcXVpcmVtZW50cyBmb3IgdGhlIG5ldyBsZWFzZWQgbGluZSB3 b3VsZCBnaXZlIHRoZSBmb2xsb3dpbmc7DQoNClN0YXR1czogVG8gYmUgZGlzY3Vzc2VkLiBO b3QgaW5jbHVkZWQuIE15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCANCiAgICAgICAgcmVx dWlyZW1lbnRzIGFyZSBmb3IgdGhlIGltcGxlbWVudGF0aW9uLCB3aGlsZSBjcml0ZXJpYSBp cyANCiAgICAgICAgZm9yIGVzdGFibGlzaGluZyBMU1BzLiBCdXQgdGhpcyBpcyBub3QgYSBz dHJvbmcgb3Bpbmlvbi4NCg0KDQoxLTIwIEFkZGl0aW9uIDIgcGFyYWdyYXBoIFNlY3Rpb24g Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9MRA0KICAgVGhlIENv bm5lY3Rpb24gVmVyaWZpY2F0aW9uIChDVikgYW5kIENvbnRpbnVpdHkgQ2hlY2sgKENDKSBh cmUgcnVuDQogICBvdmVyIHRoZSB0dW5uZWxzLCBpLmUuIHRoZSBlbnRpcmUgdHVubmVsIGlz IHByb3RlY3RlZCBlbmQgdG8gZW5kLg0KDQpORVcNCiAgIFRoZSBDb25uZWN0aW9uIFZlcmlm aWNhdGlvbiAoQ1YpIGFuZCBDb250aW51aXR5IENoZWNrIChDQykgYXJlIHJ1bg0KICAgb3Zl ciB0aGUgdHVubmVscyBiZXR3ZWVuIHRoZSBNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAgRW5k IFBvaW50cw0KICAgKE1FUCkgYXQgZWFjaCBlbmQsIGkuZS4gdGhlIGVudGlyZSB0dW5uZWwg aXMgcHJvdGVjdGVkIGVuZCB0byBlbmQuDQoNClN0YXR1czogQWNjZXB0ZWQuIEluY2x1ZGVk Lg0KKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKw0KDQoNCg0KUmV2aWV3ZXI6IE11c3RhcGhhIEFpc3Nhb3Vp DQoNCldlIHRoaW5rIHRoYXQgYWxsIHRoZSBjb21tZW50cyBiZWxvdyBhcmUgYWRkcmVzc2Vk LCBzb21ldGltZXMgdGhyb3VnaCB0aGUNCnJlc3BvbnNlcyB0byBIdXViLCBvciBieSBleHBs aWNpdGx5IGFkZGluZyB0ZXh0Lg0KDQoyLTEgT3ZlcmFsbCBjb21tZW50DQotLS0tLS0tLS0t LS0tLS0tLS0tDQoxLiBPdmVyYWxsIGNvbW1lbnQ6DQpUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBob3cgYSBndWFyYW50ZWVkIGJhbmR3aWR0aCBzZXJ2aWNlIGNhbiBiZSANCmRlcGxveWVk IGluIGEgTVBMUyBuZXR3b3JrIGJ5IHBhcnRpdGlvbmluZyB0aGUgbmV0d29yayByZXNvdXJj ZXMgaW50byANCnR3byBtYW5hZ2VkIGxheWVycywgcmVmZXJyZWQgdG8gYXMgc3RyYXRhLiBU aGUgIGd1YXJhbnRlZWQgc2VydmljZSANCmxheWVyIGlzIHJlZmVycmVkIHRvIGFzICJIYXJk IFBpcGUiIHN0cmF0dW0uDQoNClJlc3BvbnNlOiBZZXMgdGhpcyBpcyBiYXNpY2FsbHkgY29y cmVjdCwgb25lIHBvaW50IG1pZ2h0IGJlIHRoYXQgDQogICAgICAgICAgZXZlbiB0aG91Z2gg dGhlIEhhcmQgUGlwZSBzdHJhdHVtIGFuZCB0aGUgTGVhc2VkIGxpbmUgDQogICAgICAgICAg c2VydmljZSBtYW5hZ2VkLCBpLmUuIExTUHMgYW5kIGxhYmVscyBhcmUgcHJvdmlzaW9uZWQg DQogICAgICAgICAgZWl0aGVyIG1hbnVhbGx5IG9mIGJ5IGFuIE5NUy4gVGhvdWdoIG1hbnVh bCBjb25maWd1cmF0aW9uDQogICAgICAgICAgaXMgbm90IHByYWN0aWNhbCB3aXRoIHRoZSBj aHVybiBhbmQgc2l6ZSBvZiBuZXR3b3JrIHRoYXQNCiAgICAgICAgICB3aWxsIGJlIGRlcGxv eWVkLg0KDQoyLTIgQ29uZmlndXJlZCBMYWJlbHMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K VGhlIG1hbmFnZW1lbnQgb2YgdGhlIHJlc291cmNlcyBhbmQgdGhlIHBsYWNlbWVudCBvZiB0 aGUgTVBMUyB0dW5uZWxzDQphbmQgc2VydmljZXMgaW50byB0aGUgICJIYXJkIFBpcGUiIHN0 cmF0dW0gYXJlIHBlcmZvcm1lZCB3aXRoIGEgDQptYW5hZ2VtZW50IHN5c3RlbS4gVGh1cyB0 aGUgdHJhbnNwb3J0IGFuZCBzZXJ2aWNlIGxhYmVscyBhcmUgc3RhdGljIA0KYnV0IHRoaXMg aW1wb3J0YW50IGluZm9ybWF0aW9uIGhhcyBub3QgYmVlbiBzdGF0ZWQgdXBmcm9udCBpbiB0 aGUgDQpkb2N1bWVudC4gDQoNClJlc3BvbnNlOiBXZSBhZ3JlZSB0byBjYWxsIHRoZSBsYWJl bHMgImNvbmZpZ3VyZWQgbGFiZWxzIiByYXRoZXIgdGhhbg0KICAgICAgICAgICJzdGF0aWMg bGFiZWxzIi4gV2lsbCBhZGQgdGhpcyBlYXJseSBpbiB0aGUgZG9jdW1lbnQuIEluIA0KICAg ICAgICAgIHZlcnNpb24gLTAxIHRoZSBOTVMgaXMgaW50cm9kdWNlZCBpbiBzZWN0aW9uIDIu Mi4NCg0KMi0zIE1lbnRpb25pbmcgTVBMUy1UUA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K T25seSBpbiBzZWN0aW9uIDYgdGhhdCBNUExTLVRQIHdhcyBtZW50aW9uZWQuDQoNClJlc3Bv bnNlOiBZZXMgLSB3ZSBtZW50aW9uIE1QTFMtVFAgYmVjYXVzZSB0aGUgdXNlIGUyZSBwcm90 ZWN0aW9uIGFzDQogICAgICAgICAgZGVmaW5lZCBmb3IgTVBMUy1UUC4gSG93ZXZlciBpdCBz aG91bGQgYmUgcmVtZW1iZXJlZCB0aGF0IA0KICAgICAgICAgIHRoZSBIYXJkIFBpcGUgaW4g aXRzZWxmIGlzIG5vdCBpbiBpdHNlbGYgTVBMUy1UUCwgSGFyZCANCiAgICAgICAgICBQaXBl cyBtaWdodCBiZSBwcm92aXNpb25lZCBpbiBib3RoIElQL01QTFMgYW5kIE1QTFMtVFAgDQog ICAgICAgICAgbmV0d29yay4NCg0KDQoyLTQgdExEUCBhbmQgY29uZnVzaW9uDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpGdXJ0aGVybW9yZSwgdGhlIHJlZmVyZW5jZSB0byBULUxEUCBz aWduYWxlZCBsYWJlbHMgaW4gU2VjdGlvbiAzIA0KYWRkcyB0byB0aGUgY29uZnVzaW9uLiAN Cg0KUmVzcG9uc2U6IFRoaXMgaXMgdGhlIG9ubHkgY29tbWVudHdlIGhhdmUgaGFkIG9uICJj b25mdXNpb24iIGJlY2F1c2UNCiAgICAgICAgICBvZiB0aGUgcmVmZXJlbmNlIHRvLCB0aGUg b25seSB0aGluZyBpdCBzYXlzIGlzIHRoYXQgbGlrZSANCiAgICAgICAgICB0TERQIGluc3Rh bGxlZCBsYWJlbHMsIHRoZXkgYXJlIG9ubHkgdW5kZXJzdG9vZCBieSB0aGUgZW5kDQogICAg ICAgICAgcG9pbnRzLiANCg0KMi01IEhvdyB0aGUgSGFyZCBQaXBlcyBhcmUgYWNoaWV2ZWQN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJIHByb3Bvc2UgdGhhdCB0 aGUgSW50cm9kdWN0aW9uIGFuZCBTY29wZSBzZWN0aW9ucyBiZSBleHBsaWNpdCBhYm91dA0K dGhlIGZyYW1ld29yayB1c2VkIHRvIGFjaGlldmUgdGhlICJIYXJkIFBpcGUiIHN0cmF0dW0s IHRoYXQgaXMgYnkgbWVhbnMgDQpvZiBhIG1hbmFnZW1lbnQgc3lzdGVtIGFuZCBzdGF0aWMg dHJhbnNwb3J0IGFuZCBzZXJ2aWNlIGxhYmVscy4NCg0KUmVzcG9uc2U6IFdlIGZsZXNoZWQg b3V0IHRoZSBJbnRyb2R1Y3Rpb24gYW5kIFNjb3BlIGFzIHJlcXVlc3RlZCwgDQogICAgICAg ICAgYnV0IHVzZSB0aGUgdGVybWlub2xvZ3kgYWdyZWVkIG9uIGluIHRoZSANCiAgICAgICAg ICBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QuIFdlIGhvcGUgdGhhdCB0aGlzIGFu c3dlcnMNCiAgICAgICAgICBxdWl0ZSBhIGJpdCBvZiB5b3VyIHF1ZXN0aW9ucy4gVGhpcyBo YXMgYmVlbiBhZGRlZCB0byB0aGUgDQogICAgICAgICAgaW50cm9kdWN0aW9uLg0KDQpPTEQN CiAgICBUaGUgc29sdXRpb24gc29vbiB0byBiZSBkZXBsb3llZCBoYXMgYW4gRXRoZXJuZXQg aW5mcmFzdHJ1Y3R1cmUsDQogICAgd2hpY2ggaGFzIGJlZW4gc3BsaXQgaW50byB0d28gcGFy YWxsZWwgbG9naWNhbCBuZXR3b3JrcyAtIHR3bw0KICAgIHBhcmFsbGVsIHN0cmF0YS4gIFRo ZSBmaXJzdCBzdHJhdHVtIC0gdGhlIEhhcmQgUGlwZSBzdHJhdHVtIC0gZG9lcw0KICAgIG5v dCB1c2Ugc3RhdGlzdGljYWwgbXVsdGlwbGV4aW5nLCBhbmQgYmFuZHdpZHRoIGlzIGd1YXJh bnRlZWQgZW5kIHRvDQogICAgZW5kLiAgVGhlIHNlY29uZCBzdHJhdHVtIC0gTm9ybWFsIElQ L01QTFMgc3RyYXR1bSAtIHdvcmtzIGFzIGEgbm9ybWFsDQogICAgSVAvTVBMUyBuZXR3b3Jr LiAgVGhlIHR3byBzdHJhdGEgc2hhcmUgdGhlIHNhbWUgcGh5c2ljYWwgbmV0d29yaywNCiAg ICBpLmUuIHJvdXRlcnMgYW5kIGxpbmtzLiAgVGhlIHJvdXRlcnMgd2lsbCBoYW5kbGUgdGhl IHRyYWZmaWMNCiAgICBiZWxvbmdpbmcgdG8gb25lIHN0cmF0dW0gZGlmZmVyZW50IGZyb20g aG93IHRyYWZmaWMgdGhlIG90aGVyIHN0cmF0dW0NCiAgICBpcyBoYW5kbGVkLg0KDQpORVcN CiAgICBUaGUgc29sdXRpb24gc29vbiB0byBiZSBkZXBsb3llZCBoYXMgYW4gRXRoZXJuZXQg aW5mcmFzdHJ1Y3R1cmUsDQogICAgd2hpY2ggaGFzIGJlZW4gc3BsaXQgaW50byB0d28gcGFy YWxsZWwgbG9naWNhbCBuZXR3b3JrcyAtIHR3bw0KICAgIHBhcmFsbGVsIHN0cmF0YS4gIFRo ZSBmaXJzdCBzdHJhdHVtIC0gdGhlIEhhcmQgUGlwZSBzdHJhdHVtIC0gZG9lcw0KICAgIG5v dCB1c2Ugc3RhdGlzdGljYWwgbXVsdGlwbGV4aW5nLCBhbmQgYmFuZHdpZHRoIGlzIGd1YXJh bnRlZWQgZW5kIHRvDQogICAgZW5kLiAgVGhlIHNlY29uZCBzdHJhdHVtIC0gTm9ybWFsIElQ L01QTFMgc3RyYXR1bSAtIHdvcmtzIGFzIGEgbm9ybWFsDQogICAgSVAvTVBMUyBuZXR3b3Jr LiAgVGhlIHR3byBzdHJhdGEgc2hhcmUgdGhlIHNhbWUgcGh5c2ljYWwgbmV0d29yaywNCiAg ICBpLmUuIHJvdXRlcnMgYW5kIGxpbmtzLiBCdXQgdGhlIHJlc291cmNlIHJlc2VydmVkIGZv ciB0aGUgSGFyZCBQaXBlIA0KICAgIHN0cmF0dW0gd2lsbCBuZXZlciBiZSBwcmVlbXB0ZWQg YnkgdGhlIE5vcm1hbCBJUC9NUExTIHN0cmF0dW0uDQoNCiAgICBUaGUgcm91dGVycyB3aWxs IGhhbmRsZSB0aGUgdHJhZmZpYyBiZWxvbmdpbmcgdG8gb25lIHN0cmF0dW0NCiAgICBkaWZm ZXJlbnQgZnJvbSBob3cgdHJhZmZpYyB0aGUgb3RoZXIgc3RyYXR1bSBpcyBoYW5kbGVkLiBU aGlzDQogICAgc2VwYXJhdGlvbiBpbiB0cmFmZmljIGhhbmRsaW5nIGlzIGJhc2VkIG9uIHN1 cHBvcnQgaW4gaGFyZHdhcmUuDQoNCjItNiBNb3JlIGRldGFpbHMNCi0tLS0tLS0tLS0tLS0t LS0NCkluIGZhY3QsIEkgd291bGQgdGhpbmsgdGhlIGRvY3VtZW50IHZhbHVlIHdvdWxkIGJl IGluIGRlc2NyaWJpbmcgDQptb3JlIGRldGFpbHMgb2YgdGhlIGZyYW1ld29yayBpbmNsdWRp bmcgY29uZmlndXJhdGlvbiBhc3BlY3RzLCANCnJlc291cmNlIGFuZCBzZXJ2aWNlIG1hbmFn ZW1lbnQgaW5jbHVkaW5nIHJlc2lsaWVuY2UuIFRoZXNlIGFzcGVjdHMNCmhhdmUgbm90IGJl ZW4gc3VmZmljaWVudGx5IGFkZHJlc3NlZCBhbmQgdGhlIGZvY3VzIHdhcyBtb3JlIG9uIGhv dyANCnRvIHVzZSBNUExTIGxhYmVscyB0byBkaWZmZXJlbnRpYXRlIHRoZSB0d28gc3RyYXRh Lg0KDQpSZXNwb25zZTogTW9zdCBvZiB0aGlzIGlzIGFjdHVhbGx5IHRoZXJlLCBvciBpbiBy ZWZyZW5jZWQgUkZDcy4gV2l0aA0KICAgICAgICAgIGFkZGluZyB0aGUgc3RhdGVtZW50IHRo ZSBzdHJhdGEgc2VwYXJ0aW9uIGlzIGRvbmUgYnkgSFcgDQogICAgICAgICAgc3VwcG9ydCB0 aGlzIHNob3VsZCBiZSBvYnZpb3VzIGVub3VnaC4NCg0KMi03IFNjb3BlDQotLS0tLS0tLS0N CjIuIFNlY3Rpb24gMS4xIC0gU2NvcGU6DQpBcyBwYXJ0IG9mIHRoZSBzZWNvbmQgYnVsbGV0 LCBJIGNhbm5vdCBmaW5kIGluIHRoZSBkb2N1bWVudCBob3cgYSANCnJvdXRlciBwcm90ZWN0 cyB0aGUgdHJhZmZpYyBvZiB0aGUgIkhhcmQgUGlwZSIgc3RyYXR1bSBpZiB0aGUgDQoiTm9y bWFsIElQL01QTFMiIHN0cmF0dW0gb3ZlcmJvb2tzIGEgbGluay4gSGF2aW5nIGEgc2VwYXJh dGUgbGFiZWwgDQpmb3IgdGhlIGd1YXJhbnRlZWQgc2VydmljZSBpcyBub3Qgc3VmZmljaWVu dC4gVGhlIGF1dGhvcnMgc2hvdWxkIA0KZGVzY3JpYmUgaWYgTFNQIHByZS1lbXB0aW9uIGFu ZC9vciBRb1MgbWFya2luZ3MgYXJlIHVzZWQgdG8gDQpkaWZmZXJlbnRpYXRlIHRoZSB0cmVh dG1lbnQgYWNyb3NzIHRoZSBzdHJhdGEuDQoNClJlc3BvbnNlOiBUaGUgaGFyZHdhcmUgc3Vw cG9ydCB3YXMgYWRkZWQgaW4gcmVzcG9uc2UgdG8gY29tbWVudCAyLjUuDQoNCjItOCBPYmpl Y3RpdmUNCi0tLS0tLS0tLS0tLS0NCg0KMy4gU2VjdGlvbiAzOg0KSWYgdGhlIGRvY3VtZW50 IG9iamVjdGl2ZSBpcyB0byBkZXNjcmliZSB0aGUgZnJhbWV3b3JrIHVzZWQsIHRoZW4gDQp0 aGlzIHNlY3Rpb24gc2hvdWxkIGJlZ2luIGJ5IGV4cGxhaW5pbmcgdGhlIGluaXRpYWwgY29u ZmlndXJhdGlvbiANCnBlcmZvcm1lZCBieSB0aGUgTk1TIHRvIGxheSB0aGUgZ3JvdW5kIGZv ciB0aGUgYnVpbGRpbmcgb2YgdGhlIHR3byANCnN0cmF0dW1zLiBUaGlzIGluY2x1ZGVzIHRo ZSBwYXJ0aXRpb25pbmcgb2YgdGhlIGxpbmtzLCB0aGUgYXNzaWdubWVudA0Kb2YgdHJhbnNw b3J0IGFuZCBzZXJ2aWNlIGxhYmVsIHJhbmdlcyBpbiB0aGUgcm91dGVycywgdGhlIG92ZXJi b29raW5nDQpzdHJhdGVneSwgZXRjLg0KDQpSZXNwb25zZTogVGhlcmUgaXMgcmVhbGx5IG5v dCBtdWNoIGRpZmZlcmVudCBmcm9tIHdoYXQgaXMgZG9uZSB3aXRoDQogICAgICAgICAgc3Rh dGlzdGljYWxseSBtdWx0aXBsZXhlZCBNUExTLg0KICAgICAgICAgIFJlYWxseSB0aGUgb25s eSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIEhhcmQgUGlwZSBzdHJhdHVtIA0KICAgICAgICAg IGFuZCB0aGUgSVAvTVBMUyBzdHJhdHVtLCBpcyB0aGF0IG5vIG92ZXJib29raW5nIGlzIGRv bmUgDQogICAgICAgICAgd2hlbiB0aGUgaGFyZCBwaXBlIHN0cmF0dW0gaXMgcHJvdmlzaW9u ZWQuDQoNCiAgICAgICAgICBXZSB3aWxsIGFkZCB0aGUgZm9sbG93aW5nIHRvIFNlY3Rpb24g MywgaW1tZWRpYXRlbHkgYWZ0ZXINCiAgICAgICAgICB0aGUgdGhlIFNlY3Rpb24gdGl0bGUu DQoNCiAgIldoZW4gdGhlIHN0cmF0dW1zIGFyZSBwcm92aXNpb25lZCB0aGUgSVAvTVBMUyBz dHJhdHVtIGlzIHNldCB1cCANCiAgIGV4YWN0bHkgYXMgYW55IG90aGVyIElQL01QTFMgbmV0 d29yay4gVGhlIG9uZSBzbWFsbCBkaWZmZXJlbmNlIA0KICAgYmV0d2VlbiBwcm92aXNpb25p bmcgdGhlIEhhcmQgUGlwZSBzdHJhdHVtIGFuZCB0aGUgSVAvTVBMUyBzdHJhdHVtDQogICBu byBvdmVyYm9va2luZyBpcyBkb25lIGZvciB0aGUgSGFyZCBQaXBlIHN0cmF0dW0uDQoNCiAg IE92ZXJib29raW5nIGFuZC9vciBjb25nZXN0aW9uIGluIHRoZSBJUC9NUExTIHN0cmF0dW0g Y2FuIG5vdCANCiAgIGVmZmVjdCB0aGUgSGFyZCBQaXBlIHN0cmF0dW0uIg0KDQpXZSBoYXZl IGFsc28gYWRkZWQ6DQoNCiAgICBBbGwgbGFiZWxzIHVzZWQgZm9yIHRoZSBIYXJkIFBpcGUg c3RyYXR1bSBhcmUgIkNvbmZpZ3VyZWQgTGFiZWxzIiwgaS5lLg0KICAgIGxhYmVscyB0aGF0 IGFyZSBwcm92aXNpb25lZCBhbmQgcmVjbGFpbWVkIGJ5IG1hbmFnZW1lbnQgYWN0aW9ucy4g VGhlc2UgDQogICAgbWFuYWdlbWVudCBhY3Rpb25zIGNhbiBiZSBieSBtYW51YWwgYWN0aW9u cyBvciBieSBhbiBOTVMgb3IgYSBjZW50cmFsaXplZA0KICAgIGNvbnRyb2xsZXIuIEZvciB0 aGUgc2l6ZSBvZiBuZXR3b3JrIGJlaW5nIGRlcGxveWVkIG1hbnVhbCBjb25maWd1cmF0aW9u IGlzDQogICAgbm90IHByYWN0aWNhbCwgd2UgYXJlIGRvaW5nIGJvdGggcHJvdmlzaW9uaW5n IGFuZCByZWNsYWltaW5nIGEgbGFiZWxzIGZyb20NCiAgICBhbiBOTVMuDQoNCjIuOSBNb25p dG9yaW5nDQotLS0tLS0tLS0tLS0tLQ0KVGhlbiwgeW91IGNhbiBkaXNjdXNzIGhvdyBhIGd1 YXJhbnRlZWQgc2VydmljZSBpcyBjb25maWd1cmVkIGluIHRoZSANCm5ldHdvcmsgdXNpbmcg c3RhdGljIHRyYW5zcG9ydCBsYWJlbHMgYW5kIHN0YXRpYyBzZXJ2aWNlIGxhYmVscy4gVGhp cw0Kc2hvdWxkIGNvdmVyIHRoZSBwbGFjZW1lbnQgb2YgdGhlIHdvcmtpbmcgYW5kIGJhY2t1 cCBwYXRocyBzaW5jZSANClNlY3Rpb24gNiBtZW50aW9ucyBNUExTLVRQIHByb3RlY3Rpb24g aXMgdXNlZC4NCg0KUmVzcG9uc2U6IEkgdGhpbmsgdGhhdCBpcyBpbiB0aGUgcHJldmlvdXMg dGV4dCwgd2UgYXJlIHVzaW5nIE1QTFMtVFAgT0FNDQogICAgICAgICAgZm9yIG1vbml0b3Jp bmcuDQogDQoNCjItMTAgTVBMUy1UUA0KLS0tLS0tLS0tLS0tDQpOZXh0LCBhIGRlc2NyaXB0 aW9uIG9mIGhvdyB0aGUgdHJhbnNwb3J0IExTUCBhbmQgc2VydmljZSBhcmUgbW9uaXRvcmVk DQpmb3IgY29udGludWl0eSBhbmQgZGVmZWN0cy4NCg0KUmVzcG9uc2U6IFdlIHVzZSB0aGUg T0FNIGRlZmluZWQgZm9yIE1QTFMtVFAgT0FNLg0KDQoyLTExIE92ZXJib29raW5nIA0KLS0t LS0tLS0tLS0tLS0tLQ0KRmluYWxseSwgdGhlIGJlaGF2aW9yIHdoZW4gcmVzb3VyY2VzIGFy ZSBvdmVyYm9va2VkIGFuZCB3aGF0IHNlcnZpY2VzDQphcmUgcHJlLWVtcHRlZCBvciBkZWdy YWRlZCBzaG91bGQgYmUgZGVzY3JpYmVkLg0KDQpSZXNwb25zZTogT3ZlcmJvb2tpbmcgaW4g dGhlIEhhcmQgUGlwZSBzdHJhdHVtIGlzIG5vdCBkb25lLCBpZiBpdCBpcw0KICAgICAgICAg IGl0IGlzIG5vIGxvbmdlciBhIEhhcmQgUGlwZSBzdHJhdHVtLg0KICAgICAgICAgIE92ZXJi b29raW5nIGluIHRoZSBJUC9NUExTIHN0cmF0dW0gZG9lcyBub3QgZWZmZWN0IHRoZSANCiAg ICAgICAgICBIYXJkIFBpcGUgc3RyYXR1bSwgYnV0IGlzIGFsc28gb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyANCiAgICAgICAgICBkb2N1bWVudC4NCg0KDQoNCg0KDQoNCg0KDQoNCg== --------------090200000104090308040209-- From nobody Tue May 12 07:15:52 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCC91B2D87 for ; Tue, 12 May 2015 07:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 uBNOlISNxDUX for ; Tue, 12 May 2015 07:15:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC5D1B2D78 for ; Tue, 12 May 2015 07:15:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 79F8E180092; Tue, 12 May 2015 07:14:06 -0700 (PDT) To: matthew.bocci@alcatel-lucent.com, martin.vigoureux@alcatel-lucent.com, stbryant@cisco.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150512141406.79F8E180092@rfc-editor.org> Date: Tue, 12 May 2015 07:14:06 -0700 (PDT) Archived-At: Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 14:15:50 -0000 The following errata report has been submitted for RFC5586, "MPLS Generic Associated Channel". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364 -------------------------------------- Type: Technical Reported by: Alexander ("Sasha") Vainshtein Section: 4.2.1 Original Text ------------- The Time-To-Live (TTL) field of the LSE that contains the GAL follows the definition and processing rules specified in [RFC3443]. Corrected Text -------------- The value of the Time-To-Live (TTL) field of the LSE that contains the GAL follows is irrelevant as long as it exceeds 1. (Setting this value to 0 or 1 SHOULD be avoided because it could result in trapping the OAM packets in with wrong reason: "TTL expiration" instead of "GAL encountered"). Notes ----- The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet. As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5586 (draft-ietf-mpls-tp-gach-gal-06) -------------------------------------- Title : MPLS Generic Associated Channel Publication Date : June 2009 Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue May 12 23:59:18 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2618D1A037D for ; Tue, 12 May 2015 23:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Wjfofon6x402 for ; Tue, 12 May 2015 23:59:14 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2261A037F for ; Tue, 12 May 2015 23:59:14 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 7276E18016BD; Wed, 13 May 2015 08:59:12 +0200 (CEST) Message-ID: <5552F63E.9030806@pi.nu> Date: Wed, 13 May 2015 08:59:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: RFC Errata System , matthew.bocci@alcatel-lucent.com, martin.vigoureux@alcatel-lucent.com, stbryant@cisco.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, swallow@cisco.com, rcallon@juniper.net References: <20150512141406.79F8E180092@rfc-editor.org> In-Reply-To: <20150512141406.79F8E180092@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org Subject: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 06:59:17 -0000 Folks, MPLS chairs have discussed the errata. We feel that it is a change to the document rather than an errata, on that ground it should be rejected. We think that the appropriate would be to revisit this if the document is updated. I'm always uncertain of the procedures around accepting/rejecting errata, but I guess it requires AD decision. Deborah, Can you mark this a "rejected"? /Loa On 2015-05-12 16:14, RFC Errata System wrote: > The following errata report has been submitted for RFC5586, > "MPLS Generic Associated Channel". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364 > > -------------------------------------- > Type: Technical > Reported by: Alexander ("Sasha") Vainshtein > > Section: 4.2.1 > > Original Text > ------------- > The Time-To-Live (TTL) field of the LSE that contains the GAL follows > the definition and processing rules specified in [RFC3443]. > > Corrected Text > -------------- > The value of the Time-To-Live (TTL) field of the LSE that contains the > GAL follows is irrelevant as long as it exceeds 1. (Setting this value > to 0 or 1 SHOULD be avoided because it could result in trapping the OAM > packets in with wrong reason: "TTL expiration" instead of "GAL > encountered"). > > Notes > ----- > The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet. > As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5586 (draft-ietf-mpls-tp-gach-gal-06) > -------------------------------------- > Title : MPLS Generic Associated Channel > Publication Date : June 2009 > Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 13 04:59:20 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1C1A0091 for ; Wed, 13 May 2015 04:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pDAIcwIr5DBu for ; Wed, 13 May 2015 04:59:17 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0021A009C for ; Wed, 13 May 2015 04:59:17 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 59c33555.2b82cc479940.4689344.00-2443.13160663.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 13 May 2015 11:59:17 +0000 (UTC) X-MXL-Hash: 55533c950ede7db2-586db5a160e70ad671c09ff9c384cb06fb9dd034 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 88c33555.0.4689291.00-2324.13160513.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 13 May 2015 11:59:06 +0000 (UTC) X-MXL-Hash: 55533c8a43b4c6bd-b280b1bc7c050aa237aa2fdd6cef67357d1725c2 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4DBx4Rr020996; Wed, 13 May 2015 07:59:04 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4DBwmac020859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 May 2015 07:58:58 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 13 May 2015 11:58:28 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.60]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Wed, 13 May 2015 07:58:28 -0400 From: "BRUNGARD, DEBORAH A" To: Loa Andersson , RFC Errata System , "matthew.bocci@alcatel-lucent.com" , "martin.vigoureux@alcatel-lucent.com" , "stbryant@cisco.com" , "akatlas@gmail.com" , "aretana@cisco.com" , "swallow@cisco.com" , "rcallon@juniper.net" Thread-Topic: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) Thread-Index: AQHQjL4ohIEkwtWSvE6tQju61In63Z15vjEAgAAQXGA= Date: Wed, 13 May 2015 11:58:28 +0000 Message-ID: References: <20150512141406.79F8E180092@rfc-editor.org> <5552F63E.9030806@pi.nu> In-Reply-To: <5552F63E.9030806@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.220.184] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=FPCsMZUs c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=MnVN9kwoSRcA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=h1PgugrvaO0A:10 a=gxZvrgisA] X-AnalysisOut: [AAA:8 a=AUd_NHdVAAAA:8 a=pGLkceISAAAA:8 a=OUXY8nFuAAAA:8 a] X-AnalysisOut: [=IRDgFnn-AAAA:8 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=i0EeH8] X-AnalysisOut: [6SAAAA:8 a=NT5lnU8okoi3fqLv5MsA:9 a=CjuIK1q_8ugA:10 a=mhd2] X-AnalysisOut: [NDuUijAA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 11:59:19 -0000 Will do - Thanks Loa- Deborah -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Wednesday, May 13, 2015 2:59 AM To: RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@a= lcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; BRUNGARD, DEBORAH= A; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net Cc: Alexander.Vainshtein@ecitele.com; mpls@ietf.org Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) Folks, MPLS chairs have discussed the errata. We feel that it is a change to the document rather than an errata, on that ground it should be rejected. We think that the appropriate would be to revisit this if the document is updated. I'm always uncertain of the procedures around accepting/rejecting errata, but I guess it requires AD decision. Deborah, Can you mark this a "rejected"? /Loa On 2015-05-12 16:14, RFC Errata System wrote: > The following errata report has been submitted for RFC5586, > "MPLS Generic Associated Channel". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5586&eid=3D4364 > > -------------------------------------- > Type: Technical > Reported by: Alexander ("Sasha") Vainshtein > > Section: 4.2.1 > > Original Text > ------------- > The Time-To-Live (TTL) field of the LSE that contains the GAL follows > the definition and processing rules specified in [RFC3443]. > > Corrected Text > -------------- > The value of the Time-To-Live (TTL) field of the LSE that contains the > GAL follows is irrelevant as long as it exceeds 1. (Setting this value > to 0 or 1 SHOULD be avoided because it could result in trapping the OAM > packets in with wrong reason: "TTL expiration" instead of "GAL > encountered"). > > Notes > ----- > The processing rules specific in RFC 3443 deal with handling TTL in the L= SE of a labeled packets that are forwarded based on this LSE, or with setti= ng the TTL value by a LER pushing a label stack on an unlabeled packet. > As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packe= ts based on the LSE that contains GAL, hence these rules are mainly not app= licable. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5586 (draft-ietf-mpls-tp-gach-gal-06) > -------------------------------------- > Title : MPLS Generic Associated Channel > Publication Date : June 2009 > Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 13 05:14:40 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976851A8753 for ; Wed, 13 May 2015 05:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.491 X-Spam-Level: X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 uUH2ZJd97Nbb for ; Wed, 13 May 2015 05:14:37 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F471A1B6F for ; Wed, 13 May 2015 05:14:36 -0700 (PDT) Received: from AM3PR03MB0775.eurprd03.prod.outlook.com (25.160.211.139) by AM3PR03MB0773.eurprd03.prod.outlook.com (25.160.210.27) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 13 May 2015 12:14:19 +0000 Received: from AM3PR03MB0775.eurprd03.prod.outlook.com ([25.160.211.139]) by AM3PR03MB0775.eurprd03.prod.outlook.com ([25.160.211.139]) with mapi id 15.01.0160.009; Wed, 13 May 2015 12:14:19 +0000 From: Alexander Vainshtein To: "BRUNGARD, DEBORAH A" , Loa Andersson Thread-Topic: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) Thread-Index: AQHQjL4nsr+eVgEnQkSV6+FhG15t2Z15eyMAgABTnwCAAAMZcA== Date: Wed, 13 May 2015 12:14:18 +0000 Message-ID: References: <20150512141406.79F8E180092@rfc-editor.org> <5552F63E.9030806@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: att.com; dkim=none (message not signed) header.d=none; x-originating-ip: [147.234.56.21] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB0773; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AM3PR03MB0773; BCL:0; PCL:0; RULEID:; SRVR:AM3PR03MB0773; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(377424004)(24454002)(51704005)(252514010)(13464003)(16799955002)(74316001)(102836002)(15975445007)(106116001)(86362001)(92566002)(77156002)(62966003)(2950100001)(2900100001)(40100003)(46102003)(66066001)(15188155005)(189998001)(5001770100001)(2656002)(87936001)(76576001)(5001960100002)(33656002)(54356999)(50986999)(76176999)(19580395003)(19580405001)(122556002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB0773; H:AM3PR03MB0775.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2015 12:14:18.1461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR03MB0773 Archived-At: Cc: "mpls@ietf.org" , "rcallon@juniper.net" Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 12:14:39 -0000 Deborah, Loa and all, I accept the decision to reject the errata, of course. Revisiting this issue if/when the document is updated is OK with me, even i= f must admit that I do not understand the difference between this and the = disposition of errata that says "take into account when the document is upd= ated" (or something like this). I would just like to clarify that my interest in the issue was triggered by= a question I've received from the field, when a person examining some capt= ure as asked me: "Why is the TTL in the LSE containing GAL set to 2" Is this standard?" I have looked up RFC 5586, and I did not find a straightforward answer to t= his question. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20 Sent: Wednesday, May 13, 2015 2:58 PM To: Loa Andersson; RFC Errata System; matthew.bocci@alcatel-lucent.com; mar= tin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; ar= etana@cisco.com; swallow@cisco.com; rcallon@juniper.net Cc: Alexander Vainshtein; mpls@ietf.org Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364= ) Will do - Thanks Loa- Deborah -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, May 13, 2015 2:59 AM To: RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@a= lcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; BRUNGARD, DEBORAH= A; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net Cc: Alexander.Vainshtein@ecitele.com; mpls@ietf.org Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) Folks, MPLS chairs have discussed the errata. We feel that it is a change to the document rather than an errata, on that = ground it should be rejected. We think that the appropriate would be to revisit this if the document is u= pdated. I'm always uncertain of the procedures around accepting/rejecting errata, b= ut I guess it requires AD decision. Deborah, Can you mark this a "rejected"? /Loa On 2015-05-12 16:14, RFC Errata System wrote: > The following errata report has been submitted for RFC5586, "MPLS=20 > Generic Associated Channel". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5586&eid=3D4364 > > -------------------------------------- > Type: Technical > Reported by: Alexander ("Sasha") Vainshtein=20 > > > Section: 4.2.1 > > Original Text > ------------- > The Time-To-Live (TTL) field of the LSE that contains the GAL follows > the definition and processing rules specified in [RFC3443]. > > Corrected Text > -------------- > The value of the Time-To-Live (TTL) field of the LSE that contains=20 > the GAL follows is irrelevant as long as it exceeds 1. (Setting this=20 > value to 0 or 1 SHOULD be avoided because it could result in trapping=20 > the OAM packets in with wrong reason: "TTL expiration" instead of "GAL=20 > encountered"). > > Notes > ----- > The processing rules specific in RFC 3443 deal with handling TTL in the L= SE of a labeled packets that are forwarded based on this LSE, or with setti= ng the TTL value by a LER pushing a label stack on an unlabeled packet. > As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packe= ts based on the LSE that contains GAL, hence these rules are mainly not app= licable. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. > > -------------------------------------- > RFC5586 (draft-ietf-mpls-tp-gach-gal-06) > -------------------------------------- > Title : MPLS Generic Associated Channel > Publication Date : June 2009 > Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 13 08:43:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2021B2FCC for ; Wed, 13 May 2015 08:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ydIcxje7l1qE for ; Wed, 13 May 2015 08:43:21 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC8A1B2FCA for ; Wed, 13 May 2015 08:43:21 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id ACAAF1800A76; Wed, 13 May 2015 17:43:19 +0200 (CEST) Message-ID: <55537115.60002@pi.nu> Date: Wed, 13 May 2015 17:43:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexander Vainshtein , "BRUNGARD, DEBORAH A" References: <20150512141406.79F8E180092@rfc-editor.org> <5552F63E.9030806@pi.nu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , "rcallon@juniper.net" Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 15:43:24 -0000 Sasha, I think the rationale is that the wg chairs don't see this as an errata, but rather as a change. Not being an errata, it seems odd to use the errata system to maintain a non-errata. /Loa On 2015-05-13 14:14, Alexander Vainshtein wrote: > Deborah, Loa and all, > I accept the decision to reject the errata, of course. > > Revisiting this issue if/when the document is updated is OK with me, even if must admit that I do not understand the difference between this and the disposition of errata that says "take into account when the document is updated" (or something like this). > > I would just like to clarify that my interest in the issue was triggered by a question I've received from the field, when a person examining some capture as asked me: > "Why is the TTL in the LSE containing GAL set to 2" Is this standard?" > > I have looked up RFC 5586, and I did not find a straightforward answer to this question. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] > Sent: Wednesday, May 13, 2015 2:58 PM > To: Loa Andersson; RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net > Cc: Alexander Vainshtein; mpls@ietf.org > Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) > > Will do - > Thanks Loa- > Deborah > > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, May 13, 2015 2:59 AM > To: RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; BRUNGARD, DEBORAH A; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net > Cc: Alexander.Vainshtein@ecitele.com; mpls@ietf.org > Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) > > Folks, > > MPLS chairs have discussed the errata. > > We feel that it is a change to the document rather than an errata, on that ground it should be rejected. > > We think that the appropriate would be to revisit this if the document is updated. > > I'm always uncertain of the procedures around accepting/rejecting errata, but I guess it requires AD decision. > > Deborah, > > Can you mark this a "rejected"? > > > /Loa > > On 2015-05-12 16:14, RFC Errata System wrote: >> The following errata report has been submitted for RFC5586, "MPLS >> Generic Associated Channel". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364 >> >> -------------------------------------- >> Type: Technical >> Reported by: Alexander ("Sasha") Vainshtein >> >> >> Section: 4.2.1 >> >> Original Text >> ------------- >> The Time-To-Live (TTL) field of the LSE that contains the GAL follows >> the definition and processing rules specified in [RFC3443]. >> >> Corrected Text >> -------------- >> The value of the Time-To-Live (TTL) field of the LSE that contains >> the GAL follows is irrelevant as long as it exceeds 1. (Setting this >> value to 0 or 1 SHOULD be avoided because it could result in trapping >> the OAM packets in with wrong reason: "TTL expiration" instead of "GAL >> encountered"). >> >> Notes >> ----- >> The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet. >> As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or rejected. >> When a decision is reached, the verifying party (IESG) can log in to >> change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5586 (draft-ietf-mpls-tp-gach-gal-06) >> -------------------------------------- >> Title : MPLS Generic Associated Channel >> Publication Date : June 2009 >> Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. >> Category : PROPOSED STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 13 10:40:01 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C941A909C for ; Wed, 13 May 2015 10:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.492 X-Spam-Level: X-Spam-Status: No, score=0.492 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 PaL_K7loNEqu for ; Wed, 13 May 2015 10:39:57 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090711A908A for ; Wed, 13 May 2015 10:39:55 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (25.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 13 May 2015 16:49:19 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0166.017; Wed, 13 May 2015 16:49:19 +0000 From: Alexander Vainshtein To: Loa Andersson , "BRUNGARD, DEBORAH A" Thread-Topic: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) Thread-Index: AQHQjZzAsr+eVgEnQkSV6+FhG15t2Q== Date: Wed, 13 May 2015 16:49:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Infraware POLARIS Mobile Mailer v2.5 authentication-results: pi.nu; dkim=none (message not signed) header.d=none; x-originating-ip: [109.253.142.204] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(479174004)(13464003)(51704005)(252514010)(377424004)(377454003)(76576001)(189998001)(19617315012)(50226001)(2656002)(87936001)(46102003)(2900100001)(16799955002)(92566002)(86362001)(62966003)(77156002)(74316001)(122556002)(5001960100002)(50986999)(15188155005)(19580405001)(40100003)(19580395003)(5001770100001)(106116001)(33656002)(19625215002)(102836002)(15975445007)(66066001)(16236675004)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780EB97294D9CD37A9711A19DD90DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2015 16:49:18.3269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: "mpls@ietf.org" , "rcallon@juniper.net" Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 17:39:59 -0000 --_000_DB3PR03MB0780EB97294D9CD37A9711A19DD90DB3PR03MB0780eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpJIGRvIG5vdCBhcmd1ZSB3aXRoIHRoZSBkZWNpc2lvbi4NCg0KDQoNCkkgd291bGQg c2ltcGx5IGxpa2UgdG8gdW5kZXJzdGFuZA0KDQooYSkgd2hldGhlciB5b3UgdGhpbmsgdGhhdCB0 aGlzIGNoYW5nZSBzaG91bGQgYmUgY29uc2lkZXJlZCBpZi93aGVuIDU1ODZiaXMgaXMgY29uc2lk ZXJlZA0KDQooYikgaG93IHRvIHByZXNlcnZlIHRoaXMgaW5wdXQgaWYgaXQgaGFzIGFueSB2YWx1 ZS4NCg0KDQoNCk15IGd1dCBmZWVsaW5nIGFmdGVyIHJlYWRpbmcgeW91ciBvcmlnaW5hbCBlbWFp bCB3YXMgdGhhdCB0aGUgY2hhbmdlIGlzIHdvcnRoIGNvbnNpZGVyaW5nLiBBbmQgSSBkbyBub3Qg a25vdyB0aGUgYW5zd2VyIGZvciAoYikuDQoNCg0KDQpUaHVtYiB0eXBlZCBvbiBteSBMRywNClNh c2hhDQoNCi0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLQ0KRnJvbTogTG9hIEFuZGVyc3Nv bg0KRGF0ZTogMTMvMDUvMjAxNSAxODo0Mw0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluO0JSVU5H QVJELCBERUJPUkFIIEE7DQpDYzogbXBsc0BpZXRmLm9yZzttYXR0aGV3LmJvY2NpQGFsY2F0ZWwt bHVjZW50LmNvbTttYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbTtzdGJyeWFudEBj aXNjby5jb207YWthdGxhc0BnbWFpbC5jb207YXJldGFuYUBjaXNjby5jb207cmNhbGxvbkBqdW5p cGVyLm5ldDtzd2FsbG93QGNpc2NvLmNvbTsNClN1YmplY3Q6UmU6IHRvIGJlIHJlamVjdGVkIC0g UmU6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM1NTg2ICg0MzY0KQ0KDQpTYXNoYSwN Cg0KSSB0aGluayB0aGUgcmF0aW9uYWxlIGlzIHRoYXQgdGhlIHdnIGNoYWlycyBkb24ndCBzZWUg dGhpcyBhcyBhbg0KZXJyYXRhLCBidXQgcmF0aGVyIGFzIGEgY2hhbmdlLg0KDQpOb3QgYmVpbmcg YW4gZXJyYXRhLCBpdCBzZWVtcyBvZGQgdG8gdXNlIHRoZSBlcnJhdGEgc3lzdGVtIHRvIG1haW50 YWluIGENCm5vbi1lcnJhdGEuDQoNCi9Mb2ENCg0KT24gMjAxNS0wNS0xMyAxNDoxNCwgQWxleGFu ZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+IERlYm9yYWgsIExvYSBhbmQgYWxsLA0KPiBJIGFjY2Vw dCB0aGUgZGVjaXNpb24gdG8gcmVqZWN0IHRoZSBlcnJhdGEsIG9mIGNvdXJzZS4NCj4NCj4gUmV2 aXNpdGluZyB0aGlzIGlzc3VlIGlmL3doZW4gdGhlIGRvY3VtZW50IGlzIHVwZGF0ZWQgaXMgT0sg d2l0aCBtZSwgZXZlbiBpZiBtdXN0IGFkbWl0IHRoYXQgIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhl IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIGFuZCB0aGUgZGlzcG9zaXRpb24gb2YgZXJyYXRhIHRo YXQgc2F5cyAidGFrZSBpbnRvIGFjY291bnQgd2hlbiB0aGUgZG9jdW1lbnQgaXMgdXBkYXRlZCIg KG9yIHNvbWV0aGluZyBsaWtlIHRoaXMpLg0KPg0KPiBJIHdvdWxkIGp1c3QgbGlrZSB0byBjbGFy aWZ5IHRoYXQgbXkgaW50ZXJlc3QgaW4gdGhlIGlzc3VlIHdhcyB0cmlnZ2VyZWQgYnkgYSBxdWVz dGlvbiBJJ3ZlIHJlY2VpdmVkIGZyb20gdGhlIGZpZWxkLCB3aGVuIGEgcGVyc29uIGV4YW1pbmlu ZyBzb21lIGNhcHR1cmUgYXMgYXNrZWQgbWU6DQo+ICJXaHkgaXMgdGhlIFRUTCBpbiB0aGUgTFNF IGNvbnRhaW5pbmcgR0FMIHNldCB0byAyIiBJcyB0aGlzIHN0YW5kYXJkPyINCj4NCj4gSSBoYXZl IGxvb2tlZCB1cCBSRkMgNTU4NiwgYW5kIEkgZGlkIG5vdCBmaW5kIGEgc3RyYWlnaHRmb3J3YXJk IGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uLg0KPg0KPiBSZWdhcmRzLA0KPiBTYXNoYQ0KPg0KPiBP ZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPiBFbWFp bDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCUlVOR0FSRCwgREVCT1JBSCBBIFttYWlsdG86ZGIzNTQ2 QGF0dC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDEzLCAyMDE1IDI6NTggUE0NCj4gVG86 IExvYSBBbmRlcnNzb247IFJGQyBFcnJhdGEgU3lzdGVtOyBtYXR0aGV3LmJvY2NpQGFsY2F0ZWwt bHVjZW50LmNvbTsgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb207IHN0YnJ5YW50 QGNpc2NvLmNvbTsgYWthdGxhc0BnbWFpbC5jb207IGFyZXRhbmFAY2lzY28uY29tOyBzd2FsbG93 QGNpc2NvLmNvbTsgcmNhbGxvbkBqdW5pcGVyLm5ldA0KPiBDYzogQWxleGFuZGVyIFZhaW5zaHRl aW47IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IHRvIGJlIHJlamVjdGVkIC0gUmU6IFtU ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM1NTg2ICg0MzY0KQ0KPg0KPiBXaWxsIGRvIC0N Cj4gVGhhbmtzIExvYS0NCj4gRGVib3JhaA0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KPiBTZW50OiBX ZWRuZXNkYXksIE1heSAxMywgMjAxNSAyOjU5IEFNDQo+IFRvOiBSRkMgRXJyYXRhIFN5c3RlbTsg bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb207IG1hcnRpbi52aWdvdXJldXhAYWxjYXRl bC1sdWNlbnQuY29tOyBzdGJyeWFudEBjaXNjby5jb207IGFrYXRsYXNAZ21haWwuY29tOyBCUlVO R0FSRCwgREVCT1JBSCBBOyBhcmV0YW5hQGNpc2NvLmNvbTsgc3dhbGxvd0BjaXNjby5jb207IHJj YWxsb25AanVuaXBlci5uZXQNCj4gQ2M6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t OyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IHRvIGJlIHJlamVjdGVkIC0gUmU6IFtUZWNobmlj YWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM1NTg2ICg0MzY0KQ0KPg0KPiBGb2xrcywNCj4NCj4gTVBM UyBjaGFpcnMgaGF2ZSBkaXNjdXNzZWQgdGhlIGVycmF0YS4NCj4NCj4gV2UgZmVlbCB0aGF0IGl0 IGlzIGEgY2hhbmdlIHRvIHRoZSBkb2N1bWVudCByYXRoZXIgdGhhbiBhbiBlcnJhdGEsIG9uIHRo YXQgZ3JvdW5kIGl0IHNob3VsZCBiZSByZWplY3RlZC4NCj4NCj4gV2UgdGhpbmsgdGhhdCB0aGUg YXBwcm9wcmlhdGUgd291bGQgYmUgdG8gcmV2aXNpdCB0aGlzIGlmIHRoZSBkb2N1bWVudCBpcyB1 cGRhdGVkLg0KPg0KPiBJJ20gYWx3YXlzIHVuY2VydGFpbiBvZiB0aGUgcHJvY2VkdXJlcyBhcm91 bmQgYWNjZXB0aW5nL3JlamVjdGluZyBlcnJhdGEsIGJ1dCBJIGd1ZXNzIGl0IHJlcXVpcmVzIEFE IGRlY2lzaW9uLg0KPg0KPiBEZWJvcmFoLA0KPg0KPiBDYW4geW91IG1hcmsgdGhpcyBhICJyZWpl Y3RlZCI/DQo+DQo+DQo+IC9Mb2ENCj4NCj4gT24gMjAxNS0wNS0xMiAxNjoxNCwgUkZDIEVycmF0 YSBTeXN0ZW0gd3JvdGU6DQo+PiBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4g c3VibWl0dGVkIGZvciBSRkM1NTg2LCAiTVBMUw0KPj4gR2VuZXJpYyBBc3NvY2lhdGVkIENoYW5u ZWwiLg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBZ b3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCj4+IGh0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTU1ODYmZWlkPTQzNjQNCj4+DQo+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gVHlwZTogVGVjaG5pY2Fs DQo+PiBSZXBvcnRlZCBieTogQWxleGFuZGVyICgiU2FzaGEiKSBWYWluc2h0ZWluDQo+PiA8QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+Pg0KPj4gU2VjdGlvbjogNC4yLjENCj4+ DQo+PiBPcmlnaW5hbCBUZXh0DQo+PiAtLS0tLS0tLS0tLS0tDQo+PiAgICAgIFRoZSBUaW1lLVRv LUxpdmUgKFRUTCkgZmllbGQgb2YgdGhlIExTRSB0aGF0IGNvbnRhaW5zIHRoZSBHQUwgZm9sbG93 cw0KPj4gICAgICB0aGUgZGVmaW5pdGlvbiBhbmQgcHJvY2Vzc2luZyBydWxlcyBzcGVjaWZpZWQg aW4gW1JGQzM0NDNdLg0KPj4NCj4+IENvcnJlY3RlZCBUZXh0DQo+PiAtLS0tLS0tLS0tLS0tLQ0K Pj4gVGhlIHZhbHVlIG9mIHRoZSAgVGltZS1Uby1MaXZlIChUVEwpIGZpZWxkIG9mIHRoZSBMU0Ug dGhhdCBjb250YWlucw0KPj4gdGhlIEdBTCBmb2xsb3dzIGlzIGlycmVsZXZhbnQgYXMgbG9uZyBh cyBpdCBleGNlZWRzIDEuIChTZXR0aW5nIHRoaXMNCj4+IHZhbHVlIHRvIDAgb3IgMSBTSE9VTEQg YmUgYXZvaWRlZCBiZWNhdXNlIGl0IGNvdWxkIHJlc3VsdCBpbiB0cmFwcGluZw0KPj4gdGhlIE9B TSBwYWNrZXRzIGluIHdpdGggd3JvbmcgcmVhc29uOiAiVFRMIGV4cGlyYXRpb24iIGluc3RlYWQg b2YgIkdBTA0KPj4gZW5jb3VudGVyZWQiKS4NCj4+DQo+PiBOb3Rlcw0KPj4gLS0tLS0NCj4+IFRo ZSBwcm9jZXNzaW5nIHJ1bGVzIHNwZWNpZmljIGluIFJGQyAzNDQzIGRlYWwgd2l0aCBoYW5kbGlu ZyBUVEwgaW4gdGhlIExTRSBvZiBhIGxhYmVsZWQgcGFja2V0cyB0aGF0IGFyZSBmb3J3YXJkZWQg YmFzZWQgb24gdGhpcyBMU0UsIG9yIHdpdGggc2V0dGluZyB0aGUgVFRMIHZhbHVlIGJ5IGEgTEVS IHB1c2hpbmcgYSBsYWJlbCBzdGFjayBvbiBhbiB1bmxhYmVsZWQgcGFja2V0Lg0KPj4gQXMgcGVy IHRoZSBsYXN0IHBhcmEgaW4gU2VjdGlvbiA0LjIsIExTUnMgYW5kIExFUnMgTVVTVCBOT1QgZm9y d2FyZCBwYWNrZXRzIGJhc2VkIG9uIHRoZSBMU0UgdGhhdCBjb250YWlucyBHQUwsIGhlbmNlIHRo ZXNlIHJ1bGVzIGFyZSBtYWlubHkgbm90IGFwcGxpY2FibGUuDQo+Pg0KPj4gSW5zdHJ1Y3Rpb25z Og0KPj4gLS0tLS0tLS0tLS0tLQ0KPj4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQg YXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj4+IHVzZSAiUmVwbHkgQWxsIiB0 byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLg0KPj4g V2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cpIGNh biBsb2cgaW4gdG8NCj4+IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlm IG5lY2Vzc2FyeS4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4gUkZDNTU4NiAoZHJhZnQtaWV0Zi1tcGxzLXRwLWdhY2gtZ2FsLTA2KQ0KPj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IFRpdGxlICAgICAgICAgICAgICAg OiBNUExTIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsDQo+PiBQdWJsaWNhdGlvbiBEYXRlICAg IDogSnVuZSAyMDA5DQo+PiBBdXRob3IocykgICAgICAgICAgIDogTS4gQm9jY2ksIEVkLiwgTS4g Vmlnb3VyZXV4LCBFZC4sIFMuIEJyeWFudCwgRWQuDQo+PiBDYXRlZ29yeSAgICAgICAgICAgIDog UFJPUE9TRUQgU1RBTkRBUkQNCj4+IFNvdXJjZSAgICAgICAgICAgICAgOiBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZw0KPj4gQXJlYSAgICAgICAgICAgICAgICA6IFJvdXRpbmcNCj4+IFN0 cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+PiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0K Pj4NCj4NCg0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1h aWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAg ICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQp ICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_DB3PR03MB0780EB97294D9CD37A9711A19DD90DB3PR03MB0780eurp_ Content-Type: text/html; charset="utf-8" Content-ID: <8AC7B0A6E7F9B94F8D702FC16F7E13CB@ECI365.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8c3R5bGU+PCEtLSAuRW1haWxRdW90ZSB7 IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3JkZXItbGVmdDogIzgwMDAw MCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206 MDsiPkxvYSw8L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPkkg ZG8gbm90IGFyZ3VlIHdpdGggdGhlIGRlY2lzaW9uLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9w OjA7bWFyZ2luLWJvdHRvbTowOyI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDtt YXJnaW4tYm90dG9tOjA7Ij5JIHdvdWxkIHNpbXBseSBsaWtlIHRvIHVuZGVyc3RhbmQ8L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPihhKSB3aGV0aGVyIHlvdSB0 aGluayB0aGF0IHRoaXMgY2hhbmdlIHNob3VsZCBiZSBjb25zaWRlcmVkIGlmL3doZW4gNTU4NmJp cyBpcyBjb25zaWRlcmVkPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9t OjA7Ij4oYikgaG93IHRvIHByZXNlcnZlIHRoaXMgaW5wdXQgaWYgaXQgaGFzIGFueSB2YWx1ZS48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+TXkgZ3V0IGZlZWxpbmcg YWZ0ZXIgcmVhZGluZyB5b3VyIG9yaWdpbmFsIGVtYWlsIHdhcyB0aGF0IHRoZSBjaGFuZ2UgaXMg d29ydGggY29uc2lkZXJpbmcuIEFuZCBJIGRvIG5vdCBrbm93IHRoZSBhbnN3ZXIgZm9yIChiKS48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwvcD4N CjxkZXYzX2pqeT5UaHVtYiB0eXBlZCBvbiBteSBMRyw8YnI+DQpTYXNoYTwvZGV2M19qank+PGJy Pg0KPGJyPg0KLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tPGJyPg0KPGI+RnJvbTombmJz cDs8L2I+TG9hIEFuZGVyc3Nvbjxsb2FAcGkubnU+PGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+MTMv MDUvMjAxNSAxODo0Mzxicj4NCjxiPlRvOiZuYnNwOzwvYj5BbGV4YW5kZXIgVmFpbnNodGVpbjtC UlVOR0FSRCwgREVCT1JBSCBBOzxicj4NCjxiPkNjOiZuYnNwOzwvYj5tcGxzQGlldGYub3JnO21h dHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tO21hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1s dWNlbnQuY29tO3N0YnJ5YW50QGNpc2NvLmNvbTtha2F0bGFzQGdtYWlsLmNvbTthcmV0YW5hQGNp c2NvLmNvbTtyY2FsbG9uQGp1bmlwZXIubmV0O3N3YWxsb3dAY2lzY28uY29tOzxicj4NCjxiPlN1 YmplY3Q6PC9iPlJlOiB0byBiZSByZWplY3RlZCAtIFJlOiBbVGVjaG5pY2FsIEVycmF0YSBSZXBv cnRlZF0gUkZDNTU4NiAoNDM2NCk8YnI+DQo8YnI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNs YXNzPSJQbGFpblRleHQiPlNhc2hhLDxicj4NCjxicj4NCkkgdGhpbmsgdGhlIHJhdGlvbmFsZSBp cyB0aGF0IHRoZSB3ZyBjaGFpcnMgZG9uJ3Qgc2VlIHRoaXMgYXMgYW48YnI+DQplcnJhdGEsIGJ1 dCByYXRoZXIgYXMgYSBjaGFuZ2UuPGJyPg0KPGJyPg0KTm90IGJlaW5nIGFuIGVycmF0YSwgaXQg c2VlbXMgb2RkIHRvIHVzZSB0aGUgZXJyYXRhIHN5c3RlbSB0byBtYWludGFpbiBhPGJyPg0Kbm9u LWVycmF0YS48YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0KT24gMjAxNS0wNS0xMyAxNDoxNCwg QWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6PGJyPg0KJmd0OyBEZWJvcmFoLCBMb2EgYW5kIGFs bCw8YnI+DQomZ3Q7IEkgYWNjZXB0IHRoZSBkZWNpc2lvbiB0byByZWplY3QgdGhlIGVycmF0YSwg b2YgY291cnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJldmlzaXRpbmcgdGhpcyBpc3N1ZSBpZi93 aGVuIHRoZSBkb2N1bWVudCBpcyB1cGRhdGVkIGlzIE9LIHdpdGggbWUsIGV2ZW4gaWYgbXVzdCBh ZG1pdCB0aGF0ICZuYnNwO0kgZG8gbm90IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biB0aGlzIGFuZCB0aGUgZGlzcG9zaXRpb24gb2YgZXJyYXRhIHRoYXQgc2F5cyAmcXVvdDt0YWtl IGludG8gYWNjb3VudCB3aGVuIHRoZSBkb2N1bWVudCBpcyB1cGRhdGVkJnF1b3Q7IChvciBzb21l dGhpbmcgbGlrZSB0aGlzKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdvdWxkIGp1c3QgbGlrZSB0 byBjbGFyaWZ5IHRoYXQgbXkgaW50ZXJlc3QgaW4gdGhlIGlzc3VlIHdhcyB0cmlnZ2VyZWQgYnkg YSBxdWVzdGlvbiBJJ3ZlIHJlY2VpdmVkIGZyb20gdGhlIGZpZWxkLCB3aGVuIGEgcGVyc29uIGV4 YW1pbmluZyBzb21lIGNhcHR1cmUgYXMgYXNrZWQgbWU6PGJyPg0KJmd0OyAmcXVvdDtXaHkgaXMg dGhlIFRUTCBpbiB0aGUgTFNFIGNvbnRhaW5pbmcgR0FMIHNldCB0byAyJnF1b3Q7IElzIHRoaXMg c3RhbmRhcmQ/JnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBoYXZlIGxvb2tlZCB1cCBSRkMg NTU4NiwgYW5kIEkgZGlkIG5vdCBmaW5kIGEgc3RyYWlnaHRmb3J3YXJkIGFuc3dlciB0byB0aGlz IHF1ZXN0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBTYXNoYTxi cj4NCiZndDs8YnI+DQomZ3Q7IE9mZmljZTogJiM0Mzs5NzItMzkyNjYzMDI8YnI+DQomZ3Q7IENl bGw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7OTcyLTU0OTI2NjMwMjxicj4N CiZndDsgRW1haWw6ICZuYnNwOyZuYnNwO0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7 IEZyb206IEJSVU5HQVJELCBERUJPUkFIIEEgWzxhIGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0LmNv bSI+bWFpbHRvOmRiMzU0NkBhdHQuY29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwg TWF5IDEzLCAyMDE1IDI6NTggUE08YnI+DQomZ3Q7IFRvOiBMb2EgQW5kZXJzc29uOyBSRkMgRXJy YXRhIFN5c3RlbTsgbWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb207IG1hcnRpbi52aWdv dXJldXhAYWxjYXRlbC1sdWNlbnQuY29tOyBzdGJyeWFudEBjaXNjby5jb207IGFrYXRsYXNAZ21h aWwuY29tOyBhcmV0YW5hQGNpc2NvLmNvbTsgc3dhbGxvd0BjaXNjby5jb207IHJjYWxsb25AanVu aXBlci5uZXQ8YnI+DQomZ3Q7IENjOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgbXBsc0BpZXRmLm9y Zzxicj4NCiZndDsgU3ViamVjdDogUkU6IHRvIGJlIHJlamVjdGVkIC0gUmU6IFtUZWNobmljYWwg RXJyYXRhIFJlcG9ydGVkXSBSRkM1NTg2ICg0MzY0KTxicj4NCiZndDs8YnI+DQomZ3Q7IFdpbGwg ZG8gLTxicj4NCiZndDsgVGhhbmtzIExvYS08YnI+DQomZ3Q7IERlYm9yYWg8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZy b206IExvYSBBbmRlcnNzb24gWzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPm1haWx0bzpsb2FA cGkubnU8L2E+XTxicj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBNYXkgMTMsIDIwMTUgMjo1OSBB TTxicj4NCiZndDsgVG86IFJGQyBFcnJhdGEgU3lzdGVtOyBtYXR0aGV3LmJvY2NpQGFsY2F0ZWwt bHVjZW50LmNvbTsgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb207IHN0YnJ5YW50 QGNpc2NvLmNvbTsgYWthdGxhc0BnbWFpbC5jb207IEJSVU5HQVJELCBERUJPUkFIIEE7IGFyZXRh bmFAY2lzY28uY29tOyBzd2FsbG93QGNpc2NvLmNvbTsgcmNhbGxvbkBqdW5pcGVyLm5ldDxicj4N CiZndDsgQ2M6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBtcGxzQGlldGYub3Jn PGJyPg0KJmd0OyBTdWJqZWN0OiB0byBiZSByZWplY3RlZCAtIFJlOiBbVGVjaG5pY2FsIEVycmF0 YSBSZXBvcnRlZF0gUkZDNTU4NiAoNDM2NCk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb2xrcyw8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBNUExTIGNoYWlycyBoYXZlIGRpc2N1c3NlZCB0aGUgZXJyYXRhLjxi cj4NCiZndDs8YnI+DQomZ3Q7IFdlIGZlZWwgdGhhdCBpdCBpcyBhIGNoYW5nZSB0byB0aGUgZG9j dW1lbnQgcmF0aGVyIHRoYW4gYW4gZXJyYXRhLCBvbiB0aGF0IGdyb3VuZCBpdCBzaG91bGQgYmUg cmVqZWN0ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2UgdGhpbmsgdGhhdCB0aGUgYXBwcm9wcmlh dGUgd291bGQgYmUgdG8gcmV2aXNpdCB0aGlzIGlmIHRoZSBkb2N1bWVudCBpcyB1cGRhdGVkLjxi cj4NCiZndDs8YnI+DQomZ3Q7IEknbSBhbHdheXMgdW5jZXJ0YWluIG9mIHRoZSBwcm9jZWR1cmVz IGFyb3VuZCBhY2NlcHRpbmcvcmVqZWN0aW5nIGVycmF0YSwgYnV0IEkgZ3Vlc3MgaXQgcmVxdWly ZXMgQUQgZGVjaXNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgRGVib3JhaCw8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBDYW4geW91IG1hcmsgdGhpcyBhICZxdW90O3JlamVjdGVkJnF1b3Q7Pzxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAvTG9hPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMjAxNS0w NS0xMiAxNjoxNCwgUkZDIEVycmF0YSBTeXN0ZW0gd3JvdGU6PGJyPg0KJmd0OyZndDsgVGhlIGZv bGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNTU4NiwgJnF1 b3Q7TVBMUzxicj4NCiZndDsmZ3Q7IEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsJnF1b3Q7Ljxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFu ZCBhdDo8YnI+DQomZ3Q7Jmd0OyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTU1ODYmYW1wO2VpZD00MzY0IiB0YXJnZXQ9Il9CTEFO SyI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9NTU4NiZh bXA7ZWlkPTQzNjQ8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7IFR5cGU6IFRlY2huaWNhbDxi cj4NCiZndDsmZ3Q7IFJlcG9ydGVkIGJ5OiBBbGV4YW5kZXIgKCZxdW90O1Nhc2hhJnF1b3Q7KSBW YWluc2h0ZWluPGJyPg0KJmd0OyZndDsgJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU2VjdGlvbjogNC4yLjE8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9yaWdpbmFsIFRleHQ8YnI+DQomZ3Q7Jmd0OyAtLS0tLS0t LS0tLS0tPGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIFRp bWUtVG8tTGl2ZSAoVFRMKSBmaWVsZCBvZiB0aGUgTFNFIHRoYXQgY29udGFpbnMgdGhlIEdBTCBm b2xsb3dzPGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIGRl ZmluaXRpb24gYW5kIHByb2Nlc3NpbmcgcnVsZXMgc3BlY2lmaWVkIGluIFtSRkMzNDQzXS48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENvcnJlY3RlZCBUZXh0PGJyPg0KJmd0OyZndDsgLS0t LS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyBUaGUgdmFsdWUgb2YgdGhlICZuYnNwO1RpbWUtVG8t TGl2ZSAoVFRMKSBmaWVsZCBvZiB0aGUgTFNFIHRoYXQgY29udGFpbnM8YnI+DQomZ3Q7Jmd0OyB0 aGUgR0FMIGZvbGxvd3MgaXMgaXJyZWxldmFudCBhcyBsb25nIGFzIGl0IGV4Y2VlZHMgMS4gKFNl dHRpbmcgdGhpczxicj4NCiZndDsmZ3Q7IHZhbHVlIHRvIDAgb3IgMSBTSE9VTEQgYmUgYXZvaWRl ZCBiZWNhdXNlIGl0IGNvdWxkIHJlc3VsdCBpbiB0cmFwcGluZzxicj4NCiZndDsmZ3Q7IHRoZSBP QU0gcGFja2V0cyBpbiB3aXRoIHdyb25nIHJlYXNvbjogJnF1b3Q7VFRMIGV4cGlyYXRpb24mcXVv dDsgaW5zdGVhZCBvZiAmcXVvdDtHQUw8YnI+DQomZ3Q7Jmd0OyBlbmNvdW50ZXJlZCZxdW90Oyku PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBOb3Rlczxicj4NCiZndDsmZ3Q7IC0tLS0tPGJy Pg0KJmd0OyZndDsgVGhlIHByb2Nlc3NpbmcgcnVsZXMgc3BlY2lmaWMgaW4gUkZDIDM0NDMgZGVh bCB3aXRoIGhhbmRsaW5nIFRUTCBpbiB0aGUgTFNFIG9mIGEgbGFiZWxlZCBwYWNrZXRzIHRoYXQg YXJlIGZvcndhcmRlZCBiYXNlZCBvbiB0aGlzIExTRSwgb3Igd2l0aCBzZXR0aW5nIHRoZSBUVEwg dmFsdWUgYnkgYSBMRVIgcHVzaGluZyBhIGxhYmVsIHN0YWNrIG9uIGFuIHVubGFiZWxlZCBwYWNr ZXQuPGJyPg0KJmd0OyZndDsgQXMgcGVyIHRoZSBsYXN0IHBhcmEgaW4gU2VjdGlvbiA0LjIsIExT UnMgYW5kIExFUnMgTVVTVCBOT1QgZm9yd2FyZCBwYWNrZXRzIGJhc2VkIG9uIHRoZSBMU0UgdGhh dCBjb250YWlucyBHQUwsIGhlbmNlIHRoZXNlIHJ1bGVzIGFyZSBtYWlubHkgbm90IGFwcGxpY2Fi bGUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJbnN0cnVjdGlvbnM6PGJyPg0KJmd0OyZn dDsgLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkg cG9zdGVkIGFzICZxdW90O1JlcG9ydGVkJnF1b3Q7LiBJZiBuZWNlc3NhcnksIHBsZWFzZTxicj4N CiZndDsmZ3Q7IHVzZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3VsZCBiZSB2ZXJpZmllZCBvciByZWplY3RlZC48YnI+DQomZ3Q7Jmd0OyBXaGVuIGEgZGVj aXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVTRykgY2FuIGxvZyBpbiB0 bzxicj4NCiZndDsmZ3Q7IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlm IG5lY2Vzc2FyeS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsgUkZDNTU4NiAoZHJhZnQtaWV0Zi1t cGxzLXRwLWdhY2gtZ2FsLTA2KTxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsgVGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7OiBNUExTIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsPGJyPg0KJmd0OyZndDsgUHVi bGljYXRpb24gRGF0ZSAmbmJzcDsmbmJzcDsmbmJzcDs6IEp1bmUgMjAwOTxicj4NCiZndDsmZ3Q7 IEF1dGhvcihzKSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs6IE0uIEJvY2NpLCBFZC4sIE0uIFZpZ291cmV1eCwgRWQuLCBTLiBCcnlh bnQsIEVkLjxicj4NCiZndDsmZ3Q7IENhdGVnb3J5ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogUFJPUE9TRUQgU1RBTkRB UkQ8YnI+DQomZ3Q7Jmd0OyBTb3VyY2UgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBNdWx0aXByb3Rv Y29sIExhYmVsIFN3aXRjaGluZzxicj4NCiZndDsmZ3Q7IEFyZWEgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiBSb3V0aW5nPGJyPg0KJmd0OyZndDsgU3RyZWFtICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzogSUVURjxicj4NCiZndDsmZ3Q7IFZlcmlmeWluZyBQYXJ0eSAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs6IElFU0c8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQot LSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2VtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208YnI+DQpTZW5pb3IgTVBMUyBFeHBlcnQgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bG9hQHBpLm51PGJyPg0KSHVhd2VpIFRl Y2hub2xvZ2llcyAoY29uc3VsdGFudCkgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGhvbmU6ICYj NDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DB3PR03MB0780EB97294D9CD37A9711A19DD90DB3PR03MB0780eurp_-- From nobody Wed May 13 15:55:54 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585B21B3190; Wed, 13 May 2015 15:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 ruYYkUJLbauZ; Wed, 13 May 2015 15:55:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 314DA1B3198; Wed, 13 May 2015 15:55:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8423A180452; Wed, 13 May 2015 15:54:02 -0700 (PDT) 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 Message-Id: <20150513225402.8423A180452@rfc-editor.org> Date: Wed, 13 May 2015 15:54:02 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7524 on Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:55:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7524 Title: Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) Author: Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad Status: Standards Track Stream: IETF Date: May 2015 Mailbox: yakov@juniper.net, erosen@juniper.net, raggarwa_1@yahoo.com, thomas.morin@orange.com, irene.grosclaude@orange.com, n.leymann@telekom.de, samirsaad1@outlook.com Pages: 42 Characters: 105804 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-seamless-mcast-17.txt URL: https://www.rfc-editor.org/info/rfc7524 DOI: http://dx.doi.org/10.17487/RFC7524 This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS. This document is a product of the Multiprotocol Label Switching 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/rfc.html 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 Thu May 14 02:27:05 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D879D1B3574 for ; Thu, 14 May 2015 02:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01] autolearn=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 gPHPt3Y_rdpz for ; Thu, 14 May 2015 02:27:01 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24E11B356A for ; Thu, 14 May 2015 02:27:00 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 235B81800A76; Thu, 14 May 2015 11:26:59 +0200 (CEST) Message-ID: <55546A61.7080007@pi.nu> Date: Thu, 14 May 2015 11:26:57 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexander Vainshtein , "BRUNGARD, DEBORAH A" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , "rcallon@juniper.net" Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:27:04 -0000 Sasha, On 2015-05-13 18:49, Alexander Vainshtein wrote: > Loa, > > I do not argue with the decision. > > I would simply like to understand > > (a) whether you think that this change should be considered if/when > 5586bis is considered We have a a proposed changed, and it should certainly be considered if/when we do a 5586bis. > > (b) how to preserve this input if it has any value. The simple answer is that I don't know if the IETF have a method to do this - other than the mail archives. I've a set of notes with potential changes/updates/extensions to the MPLS RFCs and the RFCs that I been involved in writing. Sometimes the number of entries towards one item/issues gets such that it makes sense to do something, but when a full bis is not motivated. What I've don in such cases is towrite a small ID to preserve the input. If you want it is possible to turn the "errata" into a draft. We would then get wg consensus and if published it is guaranteed to be considered when we do the bis. If not I think we need to trust that we keep our notes straight. /Loa > > My gut feeling after reading your original email was that the change is > worth considering. And I do not know the answer for (b). > > Thumb typed on my LG, > Sasha > > ------ Original message ------ > *From: *Loa Andersson > *Date: *13/05/2015 18:43 > *To: *Alexander Vainshtein;BRUNGARD, DEBORAH A; > *Cc: > *mpls@ietf.org;matthew.bocci@alcatel-lucent.com;martin.vigoureux@alcatel-lucent.com;stbryant@cisco.com;akatlas@gmail.com;aretana@cisco.com;rcallon@juniper.net;swallow@cisco.com; > *Subject:*Re: to be rejected - Re: [Technical Errata Reported] RFC5586 > (4364) > > Sasha, > > I think the rationale is that the wg chairs don't see this as an > errata, but rather as a change. > > Not being an errata, it seems odd to use the errata system to maintain a > non-errata. > > /Loa > > On 2015-05-13 14:14, Alexander Vainshtein wrote: >> Deborah, Loa and all, >> I accept the decision to reject the errata, of course. >> >> Revisiting this issue if/when the document is updated is OK with me, even if must admit that I do not understand the difference between this and the disposition of errata that says "take into account when the document is updated" (or something like this). >> >> I would just like to clarify that my interest in the issue was triggered by a question I've received from the field, when a person examining some capture as asked me: >> "Why is the TTL in the LSE containing GAL set to 2" Is this standard?" >> >> I have looked up RFC 5586, and I did not find a straightforward answer to this question. >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: Alexander.Vainshtein@ecitele.com >> >> -----Original Message----- >> From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] >> Sent: Wednesday, May 13, 2015 2:58 PM >> To: Loa Andersson; RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net >> Cc: Alexander Vainshtein; mpls@ietf.org >> Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) >> >> Will do - >> Thanks Loa- >> Deborah >> >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Wednesday, May 13, 2015 2:59 AM >> To: RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; BRUNGARD, DEBORAH A; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net >> Cc: Alexander.Vainshtein@ecitele.com; mpls@ietf.org >> Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) >> >> Folks, >> >> MPLS chairs have discussed the errata. >> >> We feel that it is a change to the document rather than an errata, on that ground it should be rejected. >> >> We think that the appropriate would be to revisit this if the document is updated. >> >> I'm always uncertain of the procedures around accepting/rejecting errata, but I guess it requires AD decision. >> >> Deborah, >> >> Can you mark this a "rejected"? >> >> >> /Loa >> >> On 2015-05-12 16:14, RFC Errata System wrote: >>> The following errata report has been submitted for RFC5586, "MPLS >>> Generic Associated Channel". >>> >>> -------------------------------------- >>> You may review the report below and at: >>>http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Alexander ("Sasha") Vainshtein >>> >>> >>> Section: 4.2.1 >>> >>> Original Text >>> ------------- >>> The Time-To-Live (TTL) field of the LSE that contains the GAL follows >>> the definition and processing rules specified in [RFC3443]. >>> >>> Corrected Text >>> -------------- >>> The value of the Time-To-Live (TTL) field of the LSE that contains >>> the GAL follows is irrelevant as long as it exceeds 1. (Setting this >>> value to 0 or 1 SHOULD be avoided because it could result in trapping >>> the OAM packets in with wrong reason: "TTL expiration" instead of "GAL >>> encountered"). >>> >>> Notes >>> ----- >>> The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet. >>> As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or rejected. >>> When a decision is reached, the verifying party (IESG) can log in to >>> change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5586 (draft-ietf-mpls-tp-gach-gal-06) >>> -------------------------------------- >>> Title : MPLS Generic Associated Channel >>> Publication Date : June 2009 >>> Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>> >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu May 14 02:52:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9D1B35B6 for ; Thu, 14 May 2015 02:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.491 X-Spam-Level: X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 C-rrrcvbTLmi for ; Thu, 14 May 2015 02:51:59 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D36E1B35AF for ; Thu, 14 May 2015 02:51:59 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (25.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 09:51:39 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0166.017; Thu, 14 May 2015 09:51:39 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) Thread-Index: AQHQjZzAsr+eVgEnQkSV6+FhG15t2Z17NQWAgAAGrjA= Date: Thu, 14 May 2015 09:51:38 +0000 Message-ID: References: <55546A61.7080007@pi.nu> In-Reply-To: <55546A61.7080007@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pi.nu; dkim=none (message not signed) header.d=none; x-originating-ip: [147.234.56.21] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(51704005)(377454003)(377424004)(252514010)(479174004)(106116001)(74316001)(87936001)(40100003)(2656002)(122556002)(76576001)(33656002)(86362001)(54356999)(76176999)(50986999)(15188155005)(16799955002)(66066001)(62966003)(77156002)(19580405001)(19580395003)(5001960100002)(92566002)(102836002)(15975445007)(189998001)(2900100001)(2950100001)(46102003)(110136002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 09:51:38.1645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777 Archived-At: Cc: "mpls@ietf.org" , "rcallon@juniper.net" Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:52:02 -0000 TG9hLA0KTG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IGFuZCBoaWdobHkgaW5mb3JtYXRpdmUg cmVzcG9uc2UuDQpJIHdpbGwgY29uc2lkZXIgd3JpdGluZyBhIHNob3J0IElEIGFkZHJlc3Npbmcg dGhpcyBpc3N1ZSB3aXRoIDU1ODYuDQoNClJlZ2FyZHMsDQpTYXNoYQ0KDQpPZmZpY2U6ICs5NzIt MzkyNjYzMDINCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDINCkVtYWlsOiAgIEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XSANClNlbnQ6IFRodXJzZGF5LCBNYXkg MTQsIDIwMTUgMTI6MjcgUE0NClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgQlJVTkdBUkQsIERF Qk9SQUggQQ0KQ2M6IG1wbHNAaWV0Zi5vcmc7IG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQu Y29tOyBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbTsgc3RicnlhbnRAY2lzY28u Y29tOyBha2F0bGFzQGdtYWlsLmNvbTsgYXJldGFuYUBjaXNjby5jb207IHJjYWxsb25AanVuaXBl ci5uZXQ7IHN3YWxsb3dAY2lzY28uY29tDQpTdWJqZWN0OiBSZTogdG8gYmUgcmVqZWN0ZWQgLSBS ZTogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzU1ODYgKDQzNjQpDQoNClNhc2hhLA0K DQpPbiAyMDE1LTA1LTEzIDE4OjQ5LCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gTG9h LA0KPg0KPiBJIGRvIG5vdCBhcmd1ZSB3aXRoIHRoZSBkZWNpc2lvbi4NCj4NCj4gSSB3b3VsZCBz aW1wbHkgbGlrZSB0byB1bmRlcnN0YW5kDQo+DQo+IChhKSB3aGV0aGVyIHlvdSB0aGluayB0aGF0 IHRoaXMgY2hhbmdlIHNob3VsZCBiZSBjb25zaWRlcmVkIGlmL3doZW4gDQo+IDU1ODZiaXMgaXMg Y29uc2lkZXJlZA0KDQpXZSBoYXZlIGEgYSBwcm9wb3NlZCBjaGFuZ2VkLCBhbmQgaXQgc2hvdWxk IGNlcnRhaW5seSBiZSBjb25zaWRlcmVkIGlmL3doZW4gd2UgZG8gYSA1NTg2YmlzLg0KDQo+DQo+ IChiKSBob3cgdG8gcHJlc2VydmUgdGhpcyBpbnB1dCBpZiBpdCBoYXMgYW55IHZhbHVlLg0KDQpU aGUgc2ltcGxlIGFuc3dlciBpcyB0aGF0IEkgZG9uJ3Qga25vdyBpZiB0aGUgSUVURiBoYXZlIGEg bWV0aG9kIHRvIGRvIHRoaXMgLSBvdGhlciB0aGFuIHRoZSBtYWlsIGFyY2hpdmVzLg0KDQpJJ3Zl IGEgc2V0IG9mIG5vdGVzIHdpdGggcG90ZW50aWFsIGNoYW5nZXMvdXBkYXRlcy9leHRlbnNpb25z IHRvIHRoZSBNUExTIFJGQ3MgYW5kIHRoZSBSRkNzIHRoYXQgSSBiZWVuIGludm9sdmVkIGluIHdy aXRpbmcuDQoNClNvbWV0aW1lcyB0aGUgbnVtYmVyIG9mIGVudHJpZXMgdG93YXJkcyBvbmUgaXRl bS9pc3N1ZXMgZ2V0cyBzdWNoIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gZG8gc29tZXRoaW5nLCBi dXQgd2hlbiBhIGZ1bGwgYmlzIGlzIG5vdCBtb3RpdmF0ZWQuIA0KV2hhdCBJJ3ZlIGRvbiBpbiBz dWNoIGNhc2VzIGlzIHRvd3JpdGUgYSBzbWFsbCBJRCB0byBwcmVzZXJ2ZSB0aGUgaW5wdXQuDQoN CklmIHlvdSB3YW50IGl0IGlzIHBvc3NpYmxlIHRvIHR1cm4gdGhlICJlcnJhdGEiIGludG8gYSBk cmFmdC4NCldlIHdvdWxkIHRoZW4gZ2V0IHdnIGNvbnNlbnN1cyBhbmQgaWYgcHVibGlzaGVkIGl0 IGlzIGd1YXJhbnRlZWQgdG8gYmUgY29uc2lkZXJlZCB3aGVuIHdlIGRvIHRoZSBiaXMuDQoNCklm IG5vdCBJIHRoaW5rIHdlIG5lZWQgdG8gdHJ1c3QgdGhhdCB3ZSBrZWVwIG91ciBub3RlcyBzdHJh aWdodC4NCg0KL0xvYQ0KDQo+DQo+IE15IGd1dCBmZWVsaW5nIGFmdGVyIHJlYWRpbmcgeW91ciBv cmlnaW5hbCBlbWFpbCB3YXMgdGhhdCB0aGUgY2hhbmdlIA0KPiBpcyB3b3J0aCBjb25zaWRlcmlu Zy4gQW5kIEkgZG8gbm90IGtub3cgdGhlIGFuc3dlciBmb3IgKGIpLg0KPg0KPiBUaHVtYiB0eXBl ZCBvbiBteSBMRywNCj4gU2FzaGENCj4NCj4gLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0t DQo+ICpGcm9tOiAqTG9hIEFuZGVyc3Nvbg0KPiAqRGF0ZTogKjEzLzA1LzIwMTUgMTg6NDMNCj4g KlRvOiAqQWxleGFuZGVyIFZhaW5zaHRlaW47QlJVTkdBUkQsIERFQk9SQUggQTsNCj4gKkNjOg0K PiAqbXBsc0BpZXRmLm9yZzttYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbTttYXJ0aW4u dmlnb3VyZXV4QGFsY2F0DQo+IGVsLWx1Y2VudC5jb207c3RicnlhbnRAY2lzY28uY29tO2FrYXRs YXNAZ21haWwuY29tO2FyZXRhbmFAY2lzY28uY29tO3INCj4gY2FsbG9uQGp1bmlwZXIubmV0O3N3 YWxsb3dAY2lzY28uY29tOw0KPiAqU3ViamVjdDoqUmU6IHRvIGJlIHJlamVjdGVkIC0gUmU6IFtU ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM1NTg2DQo+ICg0MzY0KQ0KPg0KPiBTYXNoYSwN Cj4NCj4gSSB0aGluayB0aGUgcmF0aW9uYWxlIGlzIHRoYXQgdGhlIHdnIGNoYWlycyBkb24ndCBz ZWUgdGhpcyBhcyBhbiANCj4gZXJyYXRhLCBidXQgcmF0aGVyIGFzIGEgY2hhbmdlLg0KPg0KPiBO b3QgYmVpbmcgYW4gZXJyYXRhLCBpdCBzZWVtcyBvZGQgdG8gdXNlIHRoZSBlcnJhdGEgc3lzdGVt IHRvIG1haW50YWluIA0KPiBhIG5vbi1lcnJhdGEuDQo+DQo+IC9Mb2ENCj4NCj4gT24gMjAxNS0w NS0xMyAxNDoxNCwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+PiBEZWJvcmFoLCBMb2Eg YW5kIGFsbCwNCj4+IEkgYWNjZXB0IHRoZSBkZWNpc2lvbiB0byByZWplY3QgdGhlIGVycmF0YSwg b2YgY291cnNlLg0KPj4NCj4+IFJldmlzaXRpbmcgdGhpcyBpc3N1ZSBpZi93aGVuIHRoZSBkb2N1 bWVudCBpcyB1cGRhdGVkIGlzIE9LIHdpdGggbWUsIGV2ZW4gaWYgbXVzdCBhZG1pdCB0aGF0ICBJ IGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhpcyBhbmQgdGhlIGRp c3Bvc2l0aW9uIG9mIGVycmF0YSB0aGF0IHNheXMgInRha2UgaW50byBhY2NvdW50IHdoZW4gdGhl IGRvY3VtZW50IGlzIHVwZGF0ZWQiIChvciBzb21ldGhpbmcgbGlrZSB0aGlzKS4NCj4+DQo+PiBJ IHdvdWxkIGp1c3QgbGlrZSB0byBjbGFyaWZ5IHRoYXQgbXkgaW50ZXJlc3QgaW4gdGhlIGlzc3Vl IHdhcyB0cmlnZ2VyZWQgYnkgYSBxdWVzdGlvbiBJJ3ZlIHJlY2VpdmVkIGZyb20gdGhlIGZpZWxk LCB3aGVuIGEgcGVyc29uIGV4YW1pbmluZyBzb21lIGNhcHR1cmUgYXMgYXNrZWQgbWU6DQo+PiAi V2h5IGlzIHRoZSBUVEwgaW4gdGhlIExTRSBjb250YWluaW5nIEdBTCBzZXQgdG8gMiIgSXMgdGhp cyBzdGFuZGFyZD8iDQo+Pg0KPj4gSSBoYXZlIGxvb2tlZCB1cCBSRkMgNTU4NiwgYW5kIEkgZGlk IG5vdCBmaW5kIGEgc3RyYWlnaHRmb3J3YXJkIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uLg0KPj4N Cj4+IFJlZ2FyZHMsDQo+PiBTYXNoYQ0KPj4NCj4+IE9mZmljZTogKzk3Mi0zOTI2NjMwMg0KPj4g Q2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPj4gRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogQlJVTkdBUkQsIERFQk9SQUggQSBbbWFpbHRvOmRiMzU0NkBhdHQuY29tXQ0KPj4gU2VudDog V2VkbmVzZGF5LCBNYXkgMTMsIDIwMTUgMjo1OCBQTQ0KPj4gVG86IExvYSBBbmRlcnNzb247IFJG QyBFcnJhdGEgU3lzdGVtOyANCj4+IG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tOyAN Cj4+IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tOyBzdGJyeWFudEBjaXNjby5j b207IA0KPj4gYWthdGxhc0BnbWFpbC5jb207IGFyZXRhbmFAY2lzY28uY29tOyBzd2FsbG93QGNp c2NvLmNvbTsgDQo+PiByY2FsbG9uQGp1bmlwZXIubmV0DQo+PiBDYzogQWxleGFuZGVyIFZhaW5z aHRlaW47IG1wbHNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiB0byBiZSByZWplY3RlZCAtIFJl OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNTU4NiANCj4+ICg0MzY0KQ0KPj4NCj4+ IFdpbGwgZG8gLQ0KPj4gVGhhbmtzIExvYS0NCj4+IERlYm9yYWgNCj4+DQo+Pg0KPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FA cGkubnVdDQo+PiBTZW50OiBXZWRuZXNkYXksIE1heSAxMywgMjAxNSAyOjU5IEFNDQo+PiBUbzog UkZDIEVycmF0YSBTeXN0ZW07IG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tOyANCj4+ IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tOyBzdGJyeWFudEBjaXNjby5jb207 IA0KPj4gYWthdGxhc0BnbWFpbC5jb207IEJSVU5HQVJELCBERUJPUkFIIEE7IGFyZXRhbmFAY2lz Y28uY29tOyANCj4+IHN3YWxsb3dAY2lzY28uY29tOyByY2FsbG9uQGp1bmlwZXIubmV0DQo+PiBD YzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IG1wbHNAaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IHRvIGJlIHJlamVjdGVkIC0gUmU6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBS RkM1NTg2IA0KPj4gKDQzNjQpDQo+Pg0KPj4gRm9sa3MsDQo+Pg0KPj4gTVBMUyBjaGFpcnMgaGF2 ZSBkaXNjdXNzZWQgdGhlIGVycmF0YS4NCj4+DQo+PiBXZSBmZWVsIHRoYXQgaXQgaXMgYSBjaGFu Z2UgdG8gdGhlIGRvY3VtZW50IHJhdGhlciB0aGFuIGFuIGVycmF0YSwgb24gdGhhdCBncm91bmQg aXQgc2hvdWxkIGJlIHJlamVjdGVkLg0KPj4NCj4+IFdlIHRoaW5rIHRoYXQgdGhlIGFwcHJvcHJp YXRlIHdvdWxkIGJlIHRvIHJldmlzaXQgdGhpcyBpZiB0aGUgZG9jdW1lbnQgaXMgdXBkYXRlZC4N Cj4+DQo+PiBJJ20gYWx3YXlzIHVuY2VydGFpbiBvZiB0aGUgcHJvY2VkdXJlcyBhcm91bmQgYWNj ZXB0aW5nL3JlamVjdGluZyBlcnJhdGEsIGJ1dCBJIGd1ZXNzIGl0IHJlcXVpcmVzIEFEIGRlY2lz aW9uLg0KPj4NCj4+IERlYm9yYWgsDQo+Pg0KPj4gQ2FuIHlvdSBtYXJrIHRoaXMgYSAicmVqZWN0 ZWQiPw0KPj4NCj4+DQo+PiAvTG9hDQo+Pg0KPj4gT24gMjAxNS0wNS0xMiAxNjoxNCwgUkZDIEVy cmF0YSBTeXN0ZW0gd3JvdGU6DQo+Pj4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBi ZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNTU4NiwgIk1QTFMgDQo+Pj4gR2VuZXJpYyBBc3NvY2lhdGVk IENoYW5uZWwiLg0KPj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+PiBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCj4+Pmh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTU1ODYmZWlkPTQzNjQN Cj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gVHlw ZTogVGVjaG5pY2FsDQo+Pj4gUmVwb3J0ZWQgYnk6IEFsZXhhbmRlciAoIlNhc2hhIikgVmFpbnNo dGVpbiANCj4+PiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+Pj4NCj4+PiBT ZWN0aW9uOiA0LjIuMQ0KPj4+DQo+Pj4gT3JpZ2luYWwgVGV4dA0KPj4+IC0tLS0tLS0tLS0tLS0N Cj4+PiAgICAgIFRoZSBUaW1lLVRvLUxpdmUgKFRUTCkgZmllbGQgb2YgdGhlIExTRSB0aGF0IGNv bnRhaW5zIHRoZSBHQUwgZm9sbG93cw0KPj4+ICAgICAgdGhlIGRlZmluaXRpb24gYW5kIHByb2Nl c3NpbmcgcnVsZXMgc3BlY2lmaWVkIGluIFtSRkMzNDQzXS4NCj4+Pg0KPj4+IENvcnJlY3RlZCBU ZXh0DQo+Pj4gLS0tLS0tLS0tLS0tLS0NCj4+PiBUaGUgdmFsdWUgb2YgdGhlICBUaW1lLVRvLUxp dmUgKFRUTCkgZmllbGQgb2YgdGhlIExTRSB0aGF0IGNvbnRhaW5zIA0KPj4+IHRoZSBHQUwgZm9s bG93cyBpcyBpcnJlbGV2YW50IGFzIGxvbmcgYXMgaXQgZXhjZWVkcyAxLiAoU2V0dGluZyB0aGlz IA0KPj4+IHZhbHVlIHRvIDAgb3IgMSBTSE9VTEQgYmUgYXZvaWRlZCBiZWNhdXNlIGl0IGNvdWxk IHJlc3VsdCBpbiANCj4+PiB0cmFwcGluZyB0aGUgT0FNIHBhY2tldHMgaW4gd2l0aCB3cm9uZyBy ZWFzb246ICJUVEwgZXhwaXJhdGlvbiIgDQo+Pj4gaW5zdGVhZCBvZiAiR0FMIGVuY291bnRlcmVk IikuDQo+Pj4NCj4+PiBOb3Rlcw0KPj4+IC0tLS0tDQo+Pj4gVGhlIHByb2Nlc3NpbmcgcnVsZXMg c3BlY2lmaWMgaW4gUkZDIDM0NDMgZGVhbCB3aXRoIGhhbmRsaW5nIFRUTCBpbiB0aGUgTFNFIG9m IGEgbGFiZWxlZCBwYWNrZXRzIHRoYXQgYXJlIGZvcndhcmRlZCBiYXNlZCBvbiB0aGlzIExTRSwg b3Igd2l0aCBzZXR0aW5nIHRoZSBUVEwgdmFsdWUgYnkgYSBMRVIgcHVzaGluZyBhIGxhYmVsIHN0 YWNrIG9uIGFuIHVubGFiZWxlZCBwYWNrZXQuDQo+Pj4gQXMgcGVyIHRoZSBsYXN0IHBhcmEgaW4g U2VjdGlvbiA0LjIsIExTUnMgYW5kIExFUnMgTVVTVCBOT1QgZm9yd2FyZCBwYWNrZXRzIGJhc2Vk IG9uIHRoZSBMU0UgdGhhdCBjb250YWlucyBHQUwsIGhlbmNlIHRoZXNlIHJ1bGVzIGFyZSBtYWlu bHkgbm90IGFwcGxpY2FibGUuDQo+Pj4NCj4+PiBJbnN0cnVjdGlvbnM6DQo+Pj4gLS0tLS0tLS0t LS0tLQ0KPj4+IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIu IElmIG5lY2Vzc2FyeSwgcGxlYXNlIA0KPj4+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdo ZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLg0KPj4+IFdoZW4gYSBkZWNp c2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKSBjYW4gbG9nIGluIHRv IA0KPj4+IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2Fy eS4NCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4g UkZDNTU4NiAoZHJhZnQtaWV0Zi1tcGxzLXRwLWdhY2gtZ2FsLTA2KQ0KPj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gVGl0bGUgICAgICAgICAgICAgICA6IE1Q TFMgR2VuZXJpYyBBc3NvY2lhdGVkIENoYW5uZWwNCj4+PiBQdWJsaWNhdGlvbiBEYXRlICAgIDog SnVuZSAyMDA5DQo+Pj4gQXV0aG9yKHMpICAgICAgICAgICA6IE0uIEJvY2NpLCBFZC4sIE0uIFZp Z291cmV1eCwgRWQuLCBTLiBCcnlhbnQsIEVkLg0KPj4+IENhdGVnb3J5ICAgICAgICAgICAgOiBQ Uk9QT1NFRCBTVEFOREFSRA0KPj4+IFNvdXJjZSAgICAgICAgICAgICAgOiBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZw0KPj4+IEFyZWEgICAgICAgICAgICAgICAgOiBSb3V0aW5nDQo+Pj4g U3RyZWFtICAgICAgICAgICAgICA6IElFVEYNCj4+PiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVT Rw0KPj4+DQo+Pg0KPg0KPiAtLQ0KPg0KPg0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAg ICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBFeHBl cnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkgVGVjaG5vbG9n aWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0KLS0gDQoNCg0K TG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1 YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9h QHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3 MzkgODEgMjEgNjQNCg== From nobody Thu May 14 13:00:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF51A90CA for ; Thu, 14 May 2015 13:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 UkSW6okTGe1T for ; Thu, 14 May 2015 13:00:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05A81A909A for ; Thu, 14 May 2015 13:00:00 -0700 (PDT) Received: from BLUPR05MB1985.namprd05.prod.outlook.com (25.162.224.27) by BLUPR05MB1986.namprd05.prod.outlook.com (25.162.224.28) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 19:59:59 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([25.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([25.162.224.27]) with mapi id 15.01.0160.009; Thu, 14 May 2015 19:59:59 +0000 From: Ronald Bonica To: "mpls@ietf.org" Thread-Topic: SDN/MPLS 2015 CFP Announcement Thread-Index: AdCOgINgcVyRORJRR4q/m/Img5bUQg== Date: Thu, 14 May 2015 19:59:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1986; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB1986; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1986; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2351001)(229853001)(2656002)(99286002)(2501003)(102836002)(15975445007)(33656002)(107886002)(5001960100002)(2900100001)(110136002)(15188555004)(46102003)(66066001)(50986999)(54356999)(74316001)(189998001)(92566002)(76576001)(122556002)(62966003)(77156002)(40100003)(19580395003)(87936001)(86362001)(19580405001)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1986; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 19:59:58.5488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1986 Archived-At: Subject: [mpls] SDN/MPLS 2015 CFP Announcement X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:00:02 -0000 Call for Presentation Abstract Proposals Now up at http://www.isocore.com/2= 015/cfp.htm Submissions Deadline: May 18 Isocore's 2015 International Conference, the 18th Annual event on new netwo= rking technologies will be held November 15-18, 2015, in Washington, DC. Th= is year, the overarching themes of the conference will be on Softwarization= (Integration of SDN and NFV), Programmatic Control, Security and Operation= al Experience of the Network and Services in Cloud, Data Centers and DevOps= environments. The conference Program Committee is soliciting presentation proposals seeki= ng original and unpublished work to continue the tradition initiated by thi= s conference in 1998 of covering cutting-edge topics. Presentations address= ing new technologies and operational experience are solicited from network = equipment vendors, service providers, the research community, government ag= encies, and enterprise users. In particular, submission in at least the fol= lowing topics areas are of interest * Cybersecurity, Security of the Cloud and Data Governance * Softwarization (Integration of SDN and NFV) of the Network and Services * Service Function Chaining * Mobile and Wireless Packet Infrastructure Please submit your abstracts to cfp2015@isocore.com Regards, Ron Bonica From nobody Fri May 15 01:49:10 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A4E1AC3F1 for ; Fri, 15 May 2015 01:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nj8_X5gQFbM5 for ; Fri, 15 May 2015 01:49:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD8B1A1A7F for ; Fri, 15 May 2015 01:49:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWB46538; Fri, 15 May 2015 08:49:05 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 09:49:05 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.219]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 15 May 2015 16:49:00 +0800 From: Mach Chen To: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AdCO6/v9z88T0XL8SeSU/qiik6Kicw== Date: Fri, 15 May 2015 08:49:00 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 08:49:09 -0000 Hi All, I reviewed draft-farrelll-mpls-opportunistic-encrypt-04.txt as the member o= f MPLS Review Team and have the following comments: is the document coherent? Yes.=20 is it useful (ie, is it likely to be actually useful in operational network= s)? Yes.=20 is the document technically sound?=20 Yes. is the document ready to be considered for WG adoption? Yes.=20 BTW, after reading the document, I have the following comments: 1. Section 1.1 "...Consideration of the impact of MPLS OS on MPLS Operations, Administration, and Management (OAM) and other MPLS management techniques also needs further exploration." OAM is a critical tool for MPLS network, some OAM functions (e.g., LSP Ping= , traceroute) that depend on special label (Router Alter label, GAL) and TT= L may not work due to the encryption. Especially the hop-by-hop encrypted s= cenario.=20 In addition, seems that the following description conflicts with some exist= ing definitions. For example: Section 3, the 3rd para: "The MEL MUST have the bottom of stack bit (the S bit) set and MUST be followed by a pseudowire control word [RFC4385]. The format of the control word is described in Section 3.2." But RFC5586 says GAL must be at the bottom of the stack. And for PW, the fa= t PW also requires to be put at the bottom of the stack. 2.=20 Section 3.1 "TC: SHOULD be copied from the TC of the first encrypted label." Seems it implies that there MUST be label(s) encrypted, does it and why?=20 Are there scenarios that only the MPLS payload encrypted and the label stac= k is left as cleartext? I personally think there should be. And if so, what= the value of TC should it be? There will be no "first encrypted label" the= n.=20 3. Section 3.1 "TTL: SHOULD be set to zero to prevent encrypted packets being accidentally forwarded beyond the point of intended decryption. Shouldn't the TTL be set to 1 instead? In my understanding, when received p= ackets with TTL=3D0, the packets will be dropped.=20 And when do traceroute, the TTL should be set to corresponding value for di= fferent hops.=20 4. Section 4.2.3 Regarding the Key Exchange Message TLV, where the Path Identifier(24-bit) a= nd LSP-ID(32-bit) are designed to carry the LSP-ID, why do they have differ= ent length? Seems that only RSVP-TE based and MPLS-TP LSPs have LSP-ID and the length i= s 16 bit, so what's the LSP-ID for other LSPs ? For example LDP, BGP based,= PW etc., where LSPs are normally expressed by FECs. IMHO, you may need mor= e flexible way to identify and LSP.=20 5. Do you consider the MPLS-in-GRE/UDP scenarios? And how does MPLS OS apply t= o those cases? Best regards, Mach From nobody Fri May 15 13:25:47 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366001A1BFC; Fri, 15 May 2015 13:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 X3YhmIla1QKh; Fri, 15 May 2015 13:25:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF821A0393; Fri, 15 May 2015 13:25:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 170C31E308; Fri, 15 May 2015 16:26:04 -0400 (EDT) Date: Fri, 15 May 2015 16:26:04 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20150515202604.GC25018@pfrc.org> References: <20150504195805.GB25036@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150504195805.GB25036@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:25:46 -0000 We've gotten good responses about IPR declarations. However, there have no comments about support for last call. :-) As this is likely an oversight, the last call will continue for another several days. Note that Santosh PK has submitted some comments that will need to be addressed prior to the document moving forward. -- Jeff On Mon, May 04, 2015 at 03:58:05PM -0400, Jeffrey Haas wrote: > The BFD mailing list has been quiet since shortly after IETF 92. We have a > number of documents that seem stable and ready to advance. > > This email begins a two week Working Group Last Call for > draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884. > > This last call will end on May 15. > > Simultaneously, the authors of this draft should state to the mailing list > whether there is any IPR associated with this draft or not. > > This WGLC is also being cc'd to mpls@ietf to permit additional commentary. > > -- Jeff and Nobo From nobody Sun May 17 09:09:06 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FED81A1A55 for ; Sun, 17 May 2015 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=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 7zulFVk9Z1wn for ; Sun, 17 May 2015 09:09:03 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 A6BFE1A0277 for ; Sun, 17 May 2015 09:09:03 -0700 (PDT) Received: by padbw4 with SMTP id bw4so113350774pad.0 for ; Sun, 17 May 2015 09:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=NMkKSmTG7AjkNugf8aMQt0nHbKXAuiNt6cVTsn6lNTk=; b=zCnVqY6gQUIEnI/tKsEYCg5rv0BCSHS6Ooxun4bqNrJFVQu5JWg7rLu8B5J6nMxPnW eq+JuCcxG6epUx8iV+dbiolBvq3sCU2K5mjrFMTm02d5BnnAaE79iYWln0hZKC3R+OhF 0hcg7Cy1QvDYKXop4x/IAO3UZgygPqK573wGaLBirZG+RSbeOWPJx2iVtNuMc+G3rscD S840oeuBMrMc1NDpE4pS47PIkGnM8p4rST33sTqp/wua3HzTUAuaItmL/mvBP+uz6LI6 9TMkuNo9mswloC0V59cBd9spvFkgSEBXPPQRemsKhwPWztvBBSwU1N7HUiCWv+mFM/q+ jcHw== X-Received: by 10.66.117.233 with SMTP id kh9mr37393150pab.103.1431878943146; Sun, 17 May 2015 09:09:03 -0700 (PDT) Received: from LIZHONGJ ([122.225.109.176]) by mx.google.com with ESMTPSA id a6sm7542204pas.28.2015.05.17.09.09.00 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 May 2015 09:09:01 -0700 (PDT) From: "Lizhong Jin" To: References: <55466B95.3090502@pi.nu> In-Reply-To: <55466B95.3090502@pi.nu> Date: Mon, 18 May 2015 00:08:50 +0800 Message-ID: <083701d090bb$c957c140$5c0743c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGz4G/Z8WDc12OyEErwtiokYHgKjp25pmdA Content-Language: zh-cn Archived-At: Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 16:09:05 -0000 Hi all, I reviewed draft-farrelll-mpls-opportunistic-encrypt-04 as the member of = MPLS Review Team. I am not an security expert, so I review the draft from the MPLS = feasibility point of view, and think the document is useful and technically sound. I have several = questions, and would=20 appreciate to resolve them before WG adoption. Section 2.1, the scale of configuration that is needed for a full set of = SAs between all=20 communicating parties [Lizhong] need to expand acronym "SA", security association? Section 3, Everything that follows the control word is the entire = original MPLS packet encrypted. [Lizhong] also for Figure1, in the PHP case, the original MPLS packet = will not have label, then if the=20 packet is also encrypted and encapsulated after control work, then how = to parse the packet=20 correctly? The control word will not tell the following payload is MPLS = or IP. Section 3, The payload is the data carried by the MPLS packet (such as = IP) and may be prefixed=20 by a control word. [Lizhong] if the control word is optional, then do we need any = negotiation mechanism to enable control word or not? When decryption at the egress LER, the TTL&TC processing of the first = decrypted label should be A bit different with previous mechanism. The TTL&TC value may need to = inherit from the label before MEL in uniform mode. Regards Lizhong > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 2015=E5=B9=B45=E6=9C=884=E6=97=A5 2:40 > To: David Allan I; Mach Chen; Lizhong Jin; Kamran Raza (skraza) > Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: MPLS-RT review of = draft-farrelll-mpls-opportunistic-encrypt-04.txt >=20 > Dave, Mach, Lizhong and Kamran, >=20 >=20 > You have be selected as MPLS-RT reviewers for > draft-farrelll-mpls-opportunistic-encrypt. >=20 > Note to authors: You have been CC'd on this email so that you can know = that > this review is going on. However, please do not review your own = document. >=20 > Note to the reviewers: I understand that this document is very much on = the > "security side of the house", however I will also reach out to the = Sec-Dir for a > more security biased review. > This should not stop you from commenting on security aspects of the = draft, but > if you feel like it I'm comfortable with a "normal MPLS-RT review", = responding > to questions below. >=20 > Reviews should comment on whether the document is coherent, is it = useful (ie, > is it likely to be actually useful in operational networks), and is = the document > technically sound? We are interested in knowing whether the document = is > ready to be considered for WG adoption (ie, it doesn't have to be = perfect at this > point, but should be a good start). >=20 > Reviews should be sent to the document authors, WG co-chairs and WG > secretary, and CC'd to the MPLS WG email list. If necessary, comments = may be > sent privately to only the WG chairs. >=20 > If you have technical comments you should try to be explicit about = what > *really* need to be resolved before adopting it as a working group = document, > and what can wait until the document is a working group document and = the > working group has the revision control. >=20 > Are you able to review this draft by May 17, 2015? Please respond in a = timely > fashion. >=20 >=20 > Thanks, Loa > (as MPLS WG chair) >=20 >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun May 17 15:00:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C012A1A8749 for ; Sun, 17 May 2015 15:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.9 X-Spam-Level: X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 fozxPjsm699t for ; Sun, 17 May 2015 15:00:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E352E1A873C for ; Sun, 17 May 2015 15:00:25 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4HM0KG4005228; Sun, 17 May 2015 23:00:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4HM0GuM005202 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 17 May 2015 23:00:19 +0100 From: "Adrian Farrel" To: "'Mach Chen'" , , Date: Sun, 17 May 2015 23:00:14 +0100 Message-ID: <031b01d090ec$dcfe0160$96fa0420$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCQ7NL1z5h+rMCfRh6yaHESNfVWmw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21552.003 X-TM-AS-Result: No--22.877-10.0-31-10 X-imss-scan-details: No--22.877-10.0-31-10 X-TMASE-MatchedRID: cxtZ8fwm3r+nykMun0J1wpmug812qIbzC/ExpXrHizyJ1jCZ8wjy4MRr vjvFKTaxYrZmh50a1CHyvsKnUzU2B7kYizK5Be96BEfU2vugRF20NJ9wxH7tk9ctGlxeXl/oZGL AK9L4bSaffj9wTvYihiX2Lj4KMf+RdYq+JDDD9d7uykw7cfAoIAXXmzqmsIi7DYbe/PyX8gQosW pV5FwqUG5D0decZpwcVPdUVnwGewfmdcm+4RXJ7RIXH1e5u9bqhQaFqMRElgkwyfWtyopBqEPIv IQWz+36Cf7UJDbAHEQTN6oavHfwOdPYURkTpZRiHcQQBuf4ZFsrHkgIan9a0V7nccmPwC9HvRPs lhzHR7yCXLBx7fPL22k5x2oaTnVUHE6p0UyT9/+O0rt0LpQGebmnDa2zGPi0NEJplIoT86y3087 cZr4hROb9i2g4j8KXaipoYZl80rkQb791g8/jtVDWj4oL4ikfx8yxPNOtpdq/7bplhbPCQsosUM RQ+zgHBj52yoTxy81/WxxIgeiTHuLPA7Lv6A7YnJ5tL+LbGOMhotH7bEpEMkklF5L0lQHc876az l5+m3vi8zVgXoAltlwtzewu2M63VkVZa47CjvDdB/CxWTRRuyUIayx+Skid Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 22:00:28 -0000 Hi Mach, Thanks for your time on this draft. > BTW, after reading the document, I have the following comments: > > 1. > Section 1.1 > "...Consideration of the impact of MPLS OS > on MPLS Operations, Administration, and Management (OAM) and other > MPLS management techniques also needs further exploration." > > OAM is a critical tool for MPLS network, some OAM functions (e.g., LSP Ping, > traceroute) that depend on special label (Router Alter label, GAL) and TTL may > not work due to the encryption. Especially the hop-by-hop encrypted scenario. I actually think you have this the wrong way around. In hop-by-hop encryption, the packet will be decrypted at each hop so the OAM packets will be visible and can be processed as normal. However, hop-by-hop encryption is probably not going to be the normal mode of operation. More likely to be an issue is how to handle OAM on the LSP that has end-to-end encryption but where the OAM is targeted at a transit node. That is the issue that needs further exploration. > In addition, seems that the following description conflicts with some existing > definitions. > For example: > Section 3, the 3rd para: > "The MEL MUST have the bottom of stack bit (the S bit) set and MUST be > followed by a pseudowire control word [RFC4385]. The format of the > control word is described in Section 3.2." > > But RFC5586 says GAL must be at the bottom of the stack. I disagree with your interpretation of RFC 5586. I read section 4.2... In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. Where the GAL is at the bottom of the label stack (i.e., S bit set to 1), then it MUST always be followed by an ACH. > And for PW, the fat PW also requires to be put at the bottom > of the stack. That's an interesting one. We'd need to check it out. But I think that in both cases we need to understand that in the OE case, the bottom of the label stack is reached when labels in the clear end and encrypted labels start. We need to be *very* careful that the encrypted gloop after the MEL is not treated as a real label. To ensure that we must have the S-bit set in the MEL. However, once the MEL has been stripped and the packet has been decrypted, it can continue on its way as a normal MPLS packet if there are more labels. Thus, in the cases you are worried about, the GAL and the fat PW indicator *are* at the bottom of the stack, it is just that that bottom is hidden in the encrypted packet and a false bottom is placed in the packet higher up the stack before the encryption. > 2. > Section 3.1 > "TC: SHOULD be copied from the TC of the first encrypted label." > Seems it implies that there MUST be label(s) encrypted, does it and why? > Are there scenarios that only the MPLS payload encrypted and the label stack is > left as cleartext? I personally think there should be. And if so, what the value of > TC should it be? There will be no "first encrypted label" then. Good catch. Easy fix. > 3. > Section 3.1 > "TTL: SHOULD be set to zero to prevent encrypted packets being > accidentally forwarded beyond the point of intended > decryption. > > Shouldn't the TTL be set to 1 instead? In my understanding, when received > packets with TTL=0, the packets will be dropped. Yes. > And when do traceroute, the TTL should be set to corresponding value for > different hops. I don't think that is relevant. The TTL in the label being used to route the packet will decrement accordingly. The MEL lies below that label. > 4. > Section 4.2.3 > Regarding the Key Exchange Message TLV, where the Path Identifier(24-bit) and > LSP-ID(32-bit) are designed to carry the LSP-ID, why do they have different > length? No reason apart from what fitted in the format. > Seems that only RSVP-TE based and MPLS-TP LSPs have LSP-ID and the length is > 16 bit, so what's the LSP-ID for other LSPs ? For example LDP, BGP based, PW > etc., where LSPs are normally expressed by FECs. IMHO, you may need more > flexible way to identify and LSP. Yes. see the note at the bottom of page 22. Suggestions welcome. > 5. > > Do you consider the MPLS-in-GRE/UDP scenarios? And how does MPLS OS apply > to those cases? If the MPLS is in GRE or UDP then there are two options... 1. Encrypt the MPLS before encapsulation. No change to this work is needed. 2. Encrypt the GRE or UDP. Not the business of this document. Cheers, Adrian From nobody Sun May 17 15:42:19 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304B41A8753 for ; Sun, 17 May 2015 15:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.3 X-Spam-Level: X-Spam-Status: No, score=-99.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 ORZ-4e-HwRS7 for ; Sun, 17 May 2015 15:42:16 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444B41A873C for ; Sun, 17 May 2015 15:42:16 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4HMgD39020062; Sun, 17 May 2015 23:42:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4HMgCI9020046 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 17 May 2015 23:42:13 +0100 From: "Adrian Farrel" To: "'Lizhong Jin'" , Date: Sun, 17 May 2015 23:42:11 +0100 Message-ID: <031c01d090f2$b71ab2d0$25501870$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCQ8rJ2/ENL4NQQRoKaVEyHabXILg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21552.003 X-TM-AS-Result: No--2.699-10.0-31-10 X-imss-scan-details: No--2.699-10.0-31-10 X-TMASE-MatchedRID: vEvJ7Rh1lGinykMun0J1wpmug812qIbzC/ExpXrHizzA8hb+ebEMqFcR Yuq/M76Qje4vFpejAr9TDZdDZw9adLgFJkVTA0wMiUPZPmKZOQkk80hXoYXyaym0Y+u6E3Opxjf J+i+nbHRa8w3RIYOge9BO96vKwo78aXd+Bn1zRvVIRA38P/dwbpJ4wTGO4igSkdZCiNvAqacMD2 NjwFULE8aaE5sooRwPNJtl6mAPadzMHUInqqZ02jMk1SdDZ/pu+qTrCpYSyMI3Z3efQH+wj9j4T nQlk8H8326DGPCby8H0L9bYoYsq8UmonX26bzgoEhGH3CRdKUXPTYo1NwkfyxUZTfM00s4+ywzs CceHAI8M7pinpXjLEJ7jtmKeI7PlpDiGN/c5Idgw34HzN2XP0bfoYZ/CMuhlmyiLZetSf8mZMPC nTMzfOiq2rl3dzGQ1EdzIL/th9fJG9YXZVQdBjVbY5UQYdnXeZf2DxiRFX4GZWqyX7J7IQOay6M qXIiotIwJf2ZogpQhspBS7fffAn6S2gDiKJ6A2wKaQwPOlN1anyLbqIYI358P9zZjybGuKTVn51 J26DC8gSRGZYS1q0EMMprcbiest Archived-At: Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 22:42:18 -0000 Hello Lizhong, Thanks for your time with this draft. > I have several questions, and would appreciate to resolve them > before WG adoption. Thanks for the questions: answers below. I hope these issues don't really constitute reasons to block adoption as = a WG draft. > Section 2.1, the scale of configuration that is needed for a full set = of SAs between > all communicating parties > [Lizhong] need to expand acronym "SA", security association? Yup, need to bring that up from section 2.4. > Section 3, Everything that follows the control word is the entire = original MPLS > packet encrypted. > [Lizhong] also for Figure1, in the PHP case, the original MPLS packet = will not have > label, then if the packet is also encrypted and encapsulated after = control work,=20 > then how to parse the packet correctly? The control word will not tell = the following > payload is MPLS or IP. Hmmm, you are talking, I suppose, about the hop-by-hop encryption mode = on a final hop of an LSP that is using PHP. In this case there is nothing to encrypt except the payload. Nevertheless, I am not sure I understand your question.=20 Consider what happens when the packet is not encrypted on the final hop = of an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y pops = the last remaining label from the packet and forwards it on the = designated interface to LSR Z. LSR Z has no control word or other means = to use to determine what the received packet is. It may sniff the first = nibble if it knows the packet is IPv4 or IPv6, or if it hopes to find a = PW control word. Or LSR Z may know something magic about the incoming = interface (for example that it is an MPLS interface and that the packet = will have more labels). Now if encryption is in use, then LSR Z has agreed to its use. That = means that LSR Z is expecting to label 15, the MEL, and a control word = at the top of the packet. So it will remove those three things, decrypt = the packet, and then treat the rest of the packet exactly as it would in = the case where encryption is not in use. We could clarify this by noting that the label stack shown on the left = hand side of Figure 1 is of arbitrary depth. That would include zero = labels in the PHP case. However, I think this is a bit obvious. > Section 3, The payload is the data carried by the MPLS packet (such as = IP) and > may be prefixed by a control word. > [Lizhong] if the control word is optional, then do we need any = negotiation > mechanism to enable control word or not? Nope. This is describing the pre-encryption payload. I.e., the payload = of a regular MPLS packet. The presence or absence of a control word is = irrelevant since it is treated as part of the payload. > When decryption at the egress LER, the TTL&TC processing of the first = decrypted > label should be a bit different with previous mechanism. The TTL&TC = value may > need to inherit from the label before MEL in uniform mode. Indeed. This is how tunnelling works. You think we should explain that? Cheers, Adrian From nobody Sun May 17 20:15:15 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8276A1A02BE for ; Sun, 17 May 2015 20:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=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 uF_3w-sBWsXz for ; Sun, 17 May 2015 20:15:10 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590DF1A028A for ; Sun, 17 May 2015 20:15:10 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so61800872wic.0 for ; Sun, 17 May 2015 20:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k3vu6OL9QNXO7w6KPNxlwky0m0JV1BoHot1j3PFmx2g=; b=gX6t4IiinbNmGWVkUAj5cbpIPPIiFeREc4H2uOp2toKJpEKpYh+yW4tToSoRQLzJx8 Bcvvovf4VKLog2SauILFRGqRGMile5VAwWkMAsq4M5qk+JSbTLM5h7nqmldfknneNwvT sqJEz/cDBas3SBQffDYb1slLO0ZyZMpqbDKVAljEvR/I/UB3LjAFkIJkSP0bAQz++AEH KKK6/64u0a77HYoWdqovR9NK9adLh7v5m2RCEN07ZTEYpThF3Rh8Q9+k4sUF2Oyf8pYm /mx0b7Kx8acqq+WwTDbbhtnGOalKqiBZYsPr5AIQTe8RIXRUtzbAS8Mwi1hS8DDAQ619 oHLQ== MIME-Version: 1.0 X-Received: by 10.194.157.225 with SMTP id wp1mr39371955wjb.32.1431918908981; Sun, 17 May 2015 20:15:08 -0700 (PDT) Received: by 10.27.128.196 with HTTP; Sun, 17 May 2015 20:15:08 -0700 (PDT) In-Reply-To: <031c01d090f2$b71ab2d0$25501870$@olddog.co.uk> References: <031c01d090f2$b71ab2d0$25501870$@olddog.co.uk> Date: Mon, 18 May 2015 11:15:08 +0800 Message-ID: From: Lizhong Jin To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=089e0163415eeac91b0516529973 Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 03:15:13 -0000 --089e0163415eeac91b0516529973 Content-Type: text/plain; charset=UTF-8 Hi Adrian, Thanks for the prompt reply. See inline below. Regards Lizhong On Mon, May 18, 2015 at 6:42 AM, Adrian Farrel wrote: > Hello Lizhong, > > Thanks for your time with this draft. > > > I have several questions, and would appreciate to resolve them > > before WG adoption. > > Thanks for the questions: answers below. > I hope these issues don't really constitute reasons to block adoption as a > WG draft. > [Lizhong] not blocking issue, only need clarifications. > > > Section 2.1, the scale of configuration that is needed for a full set of > SAs between > > all communicating parties > > [Lizhong] need to expand acronym "SA", security association? > > Yup, need to bring that up from section 2.4. > > > Section 3, Everything that follows the control word is the entire > original MPLS > > packet encrypted. > > [Lizhong] also for Figure1, in the PHP case, the original MPLS packet > will not have > > label, then if the packet is also encrypted and encapsulated after > control work, > > then how to parse the packet correctly? The control word will not tell > the following > > payload is MPLS or IP. > > Hmmm, you are talking, I suppose, about the hop-by-hop encryption mode on > a final hop of an LSP that is using PHP. > In this case there is nothing to encrypt except the payload. > Nevertheless, I am not sure I understand your question. > Consider what happens when the packet is not encrypted on the final hop of > an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y pops the > last remaining label from the packet and forwards it on the designated > interface to LSR Z. LSR Z has no control word or other means to use to > determine what the received packet is. It may sniff the first nibble if it > knows the packet is IPv4 or IPv6, or if it hopes to find a PW control word. > Or LSR Z may know something magic about the incoming interface (for example > that it is an MPLS interface and that the packet will have more labels). > Now if encryption is in use, then LSR Z has agreed to its use. That means > that LSR Z is expecting to label 15, the MEL, and a control word at the top > of the packet. So it will remove those three things, decrypt the packet, > and then treat the rest of the packet exactly as it would in the case where > encryption is not in use. > > We could clarify this by noting that the label stack shown on the left > hand side of Figure 1 is of arbitrary depth. That would include zero labels > in the PHP case. However, I think this is a bit obvious. > [Lizhong] Let my try to describe with an example. In Ethernet environment, LSR Z receives the packet, and parse the payload by checking EthType, with "0x80" as IPv4. When MEL is inserted, the EthType has to be changed to "MPLS" type (0x8847/8848), and lost the original payload type information. And the MEL and control word does not have capability to indicate the payload type for parsing. > > > Section 3, The payload is the data carried by the MPLS packet (such as > IP) and > > may be prefixed by a control word. > > [Lizhong] if the control word is optional, then do we need any > negotiation > > mechanism to enable control word or not? > > Nope. This is describing the pre-encryption payload. I.e., the payload of > a regular MPLS packet. The presence or absence of a control word is > irrelevant since it is treated as part of the payload. > [Lizhong] got it, I miss reading it. > > > When decryption at the egress LER, the TTL&TC processing of the first > decrypted > > label should be a bit different with previous mechanism. The TTL&TC > value may > > need to inherit from the label before MEL in uniform mode. > > Indeed. This is how tunnelling works. You think we should explain that? > [Lizhong] Yes, it is better to mention that, or have a reference in the draft. > Cheers, > Adrian > > --089e0163415eeac91b0516529973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,
Thanks for the prompt reply. See inline bel= ow.

Regards
Lizhong

On Mon, May 18, 2015 at 6:4= 2 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hello Lizhong,

Thanks for your time with this draft.

> I have several questions, and would appreciate to resolve them
> before WG adoption.

Thanks for the questions: answers below.
I hope these issues don't really constitute reasons to block adoption a= s a WG draft.
[Lizhong] not blocking issue, only need = clarifications.
=C2=A0

> Section 2.1, the scale of configuration that is needed for a full set = of SAs between
> all communicating parties
> [Lizhong] need to expand acronym "SA", security association?=

Yup, need to bring that up from section 2.4.

> Section 3, Everything that follows the control word is the entire orig= inal MPLS
> packet encrypted.
> [Lizhong] also for Figure1, in the PHP case, the original MPLS packet = will not have
> label, then if the packet is also encrypted and encapsulated after con= trol work,
> then how to parse the packet correctly? The control word will not tell= the following
> payload is MPLS or IP.

Hmmm, you are talking, I suppose, about the hop-by-hop encryption mo= de on a final hop of an LSP that is using PHP.
In this case there is nothing to encrypt except the payload.
Nevertheless, I am not sure I understand your question.
Consider what happens when the packet is not encrypted on the final hop of = an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y pops the las= t remaining label from the packet and forwards it on the designated interfa= ce to LSR Z. LSR Z has no control word or other means to use to determine w= hat the received packet is. It may sniff the first nibble if it knows the p= acket is IPv4 or IPv6, or if it hopes to find a PW control word. Or LSR Z m= ay know something magic about the incoming interface (for example that it i= s an MPLS interface and that the packet will have more labels).
Now if encryption is in use, then LSR Z has agreed to its use. That means t= hat LSR Z is expecting to label 15, the MEL, and a control word at the top = of the packet. So it will remove those three things, decrypt the packet, an= d then treat the rest of the packet exactly as it would in the case where e= ncryption is not in use.

We could clarify this by noting that the label stack shown on the left hand= side of Figure 1 is of arbitrary depth. That would include zero labels in = the PHP case. However, I think this is a bit obvious.
= [Lizhong] Let my try to describe with an example. In Ethernet environment, = LSR Z receives the packet, and parse the payload by checking EthType, with = "0x80" as IPv4. When MEL is inserted, the EthType has to be chang= ed to "MPLS" type (0x8847/8848), and lost the original payload ty= pe information. And the MEL and control word does not have capability to in= dicate the payload type for parsing.=C2=A0

=C2=A0<= /div>

> Section 3, The payload is the data carried by the MPLS packet (such as= IP) and
> may be prefixed by a control word.
> [Lizhong] if the control word is optional, then do we need any negotia= tion
> mechanism to enable control word or not?

Nope. This is describing the pre-encryption payload. I.e., the paylo= ad of a regular MPLS packet. The presence or absence of a control word is i= rrelevant since it is treated as part of the payload.
= [Lizhong] got it, I miss reading it.
=C2=A0

> When decryption at the egress LER, the TTL&TC processing of the fi= rst decrypted
> label should be a bit different with previous mechanism. The TT= L&TC value may
> need to inherit from the label before MEL in uniform = mode.

Indeed. This is how tunnelling works. You think we should explain th= at?
[Lizhong] Yes, it is better to mention that, or ha= ve a reference in the draft.


Cheers,
Adrian


--089e0163415eeac91b0516529973-- From nobody Sun May 17 20:31:57 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D7E1A0390 for ; Sun, 17 May 2015 20:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uM_6gw3jAIIk for ; Sun, 17 May 2015 20:31:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46F81A032D for ; Sun, 17 May 2015 20:31:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSQ24366; Mon, 18 May 2015 03:31:52 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 04:31:51 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.243]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Mon, 18 May 2015 11:31:45 +0800 From: Mach Chen To: "adrian@olddog.co.uk" , "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AdCQ7NL1z5h+rMCfRh6yaHESNfVWmwAJHA2A Date: Mon, 18 May 2015 03:31:45 +0000 Message-ID: References: <031b01d090ec$dcfe0160$96fa0420$@olddog.co.uk> In-Reply-To: <031b01d090ec$dcfe0160$96fa0420$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 03:31:56 -0000 Hi Adrian, Thanks for your prompt response! See my reply inline... > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Monday, May 18, 2015 6:00 AM > To: Mach Chen; draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org; > mpls-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] MPLS-RT review on > draft-farrelll-mpls-opportunistic-encrypt-04.txt >=20 > Hi Mach, >=20 > Thanks for your time on this draft. >=20 > > BTW, after reading the document, I have the following comments: > > > > 1. > > Section 1.1 > > "...Consideration of the impact of MPLS OS > > on MPLS Operations, Administration, and Management (OAM) and other > > MPLS management techniques also needs further exploration." > > > > OAM is a critical tool for MPLS network, some OAM functions (e.g., LSP > > Ping, > > traceroute) that depend on special label (Router Alter label, GAL) and > > TTL may not work due to the encryption. Especially the hop-by-hop encry= pted > scenario. >=20 > I actually think you have this the wrong way around. > In hop-by-hop encryption, the packet will be decrypted at each hop so the= OAM > packets will be visible and can be processed as normal. However, hop-by-h= op > encryption is probably not going to be the normal mode of operation. Rethink about this, indeed, hop-by-hop is fine.=20 >=20 > More likely to be an issue is how to handle OAM on the LSP that has end-t= o-end > encryption but where the OAM is targeted at a transit node. That is the i= ssue > that needs further exploration. Yes, traceroute is such a typical scenario. For end-to-end encryption, the = transit nodes should not (and for OS purpose, it MUST not) know how to decr= ypt the packets, then traceroute will fail.=20 >=20 > > In addition, seems that the following description conflicts with some > > existing definitions. > > For example: > > Section 3, the 3rd para: > > "The MEL MUST have the bottom of stack bit (the S bit) set and MUST be > > followed by a pseudowire control word [RFC4385]. The format of the > > control word is described in Section 3.2." > > > > But RFC5586 says GAL must be at the bottom of the stack. >=20 > I disagree with your interpretation of RFC 5586. I read section 4.2... >=20 > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be > used with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). However, in other MPLS environments, this > document places no restrictions on where the GAL may appear within > the label stack or its use with PWs. Where the GAL is at the bottom > of the label stack (i.e., S bit set to 1), then it MUST always be > followed by an ACH. At least for MPLS-TP LSP, it is the case, unless the GAL is encrypted. >=20 > > And for PW, the fat PW also requires to be put at the bottom of the > > stack. >=20 > That's an interesting one. We'd need to check it out. > But I think that in both cases we need to understand that in the OE case,= the > bottom of the label stack is reached when labels in the clear end and enc= rypted > labels start. We need to be *very* careful that the encrypted gloop after= the > MEL is not treated as a real label. To ensure that we must have the S-bit= set in > the MEL. However, once the MEL has been stripped and the packet has been > decrypted, it can continue on its way as a normal MPLS packet if there ar= e > more labels. Thus, in the cases you are worried about, the GAL and the fa= t PW > indicator *are* at the bottom of the stack, it is just that that bottom i= s hidden > in the encrypted packet and a false bottom is placed in the packet higher= up the > stack before the encryption. Yes, as above, then the GAL MUST be encrypted and should not be co-existenc= e in the stack. >=20 > > 2. > > Section 3.1 > > "TC: SHOULD be copied from the TC of the first encrypted label." > > Seems it implies that there MUST be label(s) encrypted, does it and why= ? > > Are there scenarios that only the MPLS payload encrypted and the label > > stack > is > > left as cleartext? I personally think there should be. And if so, what > > the > value of > > TC should it be? There will be no "first encrypted label" then. >=20 > Good catch. > Easy fix. >=20 > > 3. > > Section 3.1 > > "TTL: SHOULD be set to zero to prevent encrypted packets being > > accidentally forwarded beyond the point of intended > > decryption. > > > > Shouldn't the TTL be set to 1 instead? In my understanding, when > > received packets with TTL=3D0, the packets will be dropped. >=20 > Yes. >=20 > > And when do traceroute, the TTL should be set to corresponding value > > for different hops. >=20 > I don't think that is relevant. The TTL in the label being used to route = the packet > will decrement accordingly. The MEL lies below that label. >=20 > > 4. > > Section 4.2.3 > > Regarding the Key Exchange Message TLV, where the Path > > Identifier(24-bit) and > > LSP-ID(32-bit) are designed to carry the LSP-ID, why do they have > > different length? >=20 > No reason apart from what fitted in the format. >=20 > > Seems that only RSVP-TE based and MPLS-TP LSPs have LSP-ID and the > > length is > > 16 bit, so what's the LSP-ID for other LSPs ? For example LDP, BGP > > based, PW etc., where LSPs are normally expressed by FECs. IMHO, you > > may need more flexible way to identify and LSP. >=20 > Yes. see the note at the bottom of page 22. Suggestions welcome. I also think 4379 like expression is needed. >=20 > > 5. > > > > Do you consider the MPLS-in-GRE/UDP scenarios? And how does MPLS OS > > apply to those cases? >=20 > If the MPLS is in GRE or UDP then there are two options... > 1. Encrypt the MPLS before encapsulation. No change to this work is neede= d. > 2. Encrypt the GRE or UDP. Not the business of this document. OK, maybe it's useful to add some text to the document to clarify this. Best regards, Mach >=20 > Cheers, > Adrian From nobody Mon May 18 01:57:23 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C70E1A1B0B for ; Mon, 18 May 2015 01:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 Emo4evI-oGMQ for ; Mon, 18 May 2015 01:57:20 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0711A007E for ; Mon, 18 May 2015 01:57:20 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4I8vHvf024191; Mon, 18 May 2015 09:57:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4I8vCMV024063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 May 2015 09:57:15 +0100 From: "Adrian Farrel" To: "'Lizhong Jin'" References: <031c01d090f2$b71ab2d0$25501870$@olddog.co.uk> In-Reply-To: Date: Mon, 18 May 2015 09:57:10 +0100 Message-ID: <038a01d09148$a2f87890$e8e969b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLtMjKmdsdmJhBs/CHK4l2DStnr9gJhehHrmzUS0oA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21552.006 X-TM-AS-Result: No--6.127-10.0-31-10 X-imss-scan-details: No--6.127-10.0-31-10 X-TMASE-MatchedRID: 8+bhjh9TQnE4HKI/yaqRmx3EEAbn+GRbGSqdEmeD/nV/tE9YIUrwYmH9 qmSCMo1DglmCfhOu3g7I1TUbyXhF1HhOmBpkfkUrbMGKOuLn5FUJDfFL7Mvp7dqCxkzSpW/XosP l77f7gdzNAIQVxCmqmGYX2K+F1a0hxaWErlRokDyTEgTE0DYkgNcuriW22Uf/uX6NXIvOYLtMOy 6GSjkBVo6N2tH+yqIRAaBq8YFGlhAlPCAsfAiuNN/wYmMFcJSI5TbwqVVpF+MREeTKxBqIeaYAH z7/p72b4EyJi38jHZoE40h/ri/5Sj3XUxeO5E+LYD9XTRdaMO1cSMp/1+Epp2sSgW01iDQLvPg6 UssVFP8IS5UXqe5IMV+24nCsUSFNt7DW3B48kkHdB/CxWTRRuwihQpoXbuXFT6LBGWscvRiRKcr 802/NVa7Fk6xwyDFN+N2v6VEahYoWKI4kP3UgRMCAPy/fTtWKFDl/hR7C9wps2cTgeXjWii3UKa d/I8O4CQKeQDeH+fUPvTV19UCLO5Iv06+1Rxr97r4PjzaceGueqD9WtJkSIw== Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 08:57:22 -0000 Hi again, >>>> Section 3, Everything that follows the control word is the entire=20 >>>> original MPLS packet encrypted. >>> >>> [Lizhong] also for Figure1, in the PHP case, the original MPLS = packet will=20 >>> not have label, then if the packet is also encrypted and = encapsulated=20 >>> after control work, then how to parse the packet correctly? The = control >>> word will not tell the following payload is MPLS or IP. >> >> Hmmm, you are talking, I suppose, about the hop-by-hop encryption = mode >> on a final hop of an LSP that is using PHP. >> In this case there is nothing to encrypt except the payload. >> Nevertheless, I am not sure I understand your question. >> Consider what happens when the packet is not encrypted on the final = hop >> of an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y = pops the last >> remaining label from the packet and forwards it on the designated = interface >> to LSR Z. LSR Z has no control word or other means to use to = determine >> what the received packet is. It may sniff the first nibble if it = knows the >> packet is IPv4 or IPv6, or if it hopes to find a PW control word. Or = LSR Z may >> know something magic about the incoming interface (for example that = it is >> an MPLS interface and that the packet will have more labels). >> Now if encryption is in use, then LSR Z has agreed to its use. That = means >> that LSR Z is expecting to label 15, the MEL, and a control word at = the top >> of the packet. So it will remove those three things, decrypt the = packet, and >> then treat the rest of the packet exactly as it would in the case = where >> encryption is not in use. >> >> We could clarify this by noting that the label stack shown on the = left hand >> side of Figure 1 is of arbitrary depth. That would include zero = labels in the >> PHP case. However, I think this is a bit obvious. > > [Lizhong] Let my try to describe with an example. In Ethernet = environment, > LSR Z receives the packet, and parse the payload by checking EthType, = with > "0x80" as IPv4. When MEL is inserted, the EthType has to be changed to > "MPLS" type (0x8847/8848), and lost the original payload type = information. > And the MEL and control word does not have capability to indicate the > payload type for parsing.=20 You're right. With PHP in my example, LSR Y (that strips the label) = determines what the packet type is, and uses that to set the Ethertype. = Using encryption, it would be LSR Z that had to do this. But it would be = the same function. An alternative here would be to run encryption only as far as the = penultimate hop, but that leaves the last hop exposed. So, to me it seems that if you want to run end-to-end encryption, you = probably want to run it without PHP. >>> When decryption at the egress LER, the TTL&TC processing of the = first >>> decrypted label should be a bit different with previous mechanism.=20 >>> The TTL&TC value may need to inherit from the label before MEL in >>> uniform mode. >> >> Indeed. This is how tunnelling works. You think we should explain = that? > > [Lizhong] Yes, it is better to mention that, or have a reference in = the draft. OK. Will do. Cheers, Adrian From nobody Mon May 18 02:36:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4911A8845 for ; Mon, 18 May 2015 02:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 RJJl4MMVtGjQ for ; Mon, 18 May 2015 02:36:21 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA651A1A13 for ; Mon, 18 May 2015 02:36:21 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4I9aFgI022325; Mon, 18 May 2015 10:36:15 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4I9aBLn022236 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 May 2015 10:36:12 +0100 From: "Adrian Farrel" To: "'Mach Chen'" , , References: <031b01d090ec$dcfe0160$96fa0420$@olddog.co.uk> In-Reply-To: Date: Mon, 18 May 2015 10:36:09 +0100 Message-ID: <039d01d0914e$14723510$3d569f30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6POlqeEnH3sXcTrZdPo7/Ux2uswGcoMlqnCEzXPA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21552.006 X-TM-AS-Result: No--19.530-10.0-31-10 X-imss-scan-details: No--19.530-10.0-31-10 X-TMASE-MatchedRID: QfHZjzml1E8n2WEbWzq9rYzb2GR6Ttd3YpovC7zX5q9F06jtyKwzBjd1 jBj8QIzho4gustUfstKo0qxfxFzkl3UAZ5iYnrhrY6Gjtu6/t30fOdo4H355iGSWOq+2g0h2678 QLKEvGo6UK/DNbr8qaWxUIVDD49AfwqXcPu8a4bJgP1dNF1ow7X+ogtHzaKWZtSlhqC3qPOiQXY sxaMfidI1xT55RLs5wG8qjWzujJzEdj9vNGYhpkcAmcZEx8XHJGSqdEmeD/nW638ZUY6gSd1l7f U/4au864vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjkGUtrowrXLg= Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 09:36:22 -0000 > > More likely to be an issue is how to handle OAM on the LSP that has > > end-to-end encryption but where the OAM is targeted at a transit > > node. That is the issue that needs further exploration. > > Yes, traceroute is such a typical scenario. For end-to-end encryption, the transit > nodes should not (and for OS purpose, it MUST not) know how to decrypt the > packets, then traceroute will fail. Yup. The thing I'd like to look at is whether it would be OK to run the OAM (specifically intermediate-node action OAM) without encryption. But I think there are some issues with ECMP. > > > 4. > > > Section 4.2.3 > > > Regarding the Key Exchange Message TLV, where the Path > > > Identifier(24-bit) and > > > LSP-ID(32-bit) are designed to carry the LSP-ID, why do they have > > > different length? > > > > No reason apart from what fitted in the format. > > > > > Seems that only RSVP-TE based and MPLS-TP LSPs have LSP-ID and the > > > length is > > > 16 bit, so what's the LSP-ID for other LSPs ? For example LDP, BGP > > > based, PW etc., where LSPs are normally expressed by FECs. IMHO, you > > > may need more flexible way to identify and LSP. > > > > Yes. see the note at the bottom of page 22. Suggestions welcome. > > I also think 4379 like expression is needed. Yes, that can probably be the way forward. > > > 5. > > > > > > Do you consider the MPLS-in-GRE/UDP scenarios? And how does MPLS OS > > > apply to those cases? > > > > If the MPLS is in GRE or UDP then there are two options... > > 1. Encrypt the MPLS before encapsulation. No change to this work is needed. > > 2. Encrypt the GRE or UDP. Not the business of this document. > > OK, maybe it's useful to add some text to the document to clarify this. Sure. Adrian From nobody Mon May 18 02:49:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF3E1A885E for ; Mon, 18 May 2015 02:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8m4O2gXzflUc for ; Mon, 18 May 2015 02:49:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D971A8859 for ; Mon, 18 May 2015 02:49:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWF10719; Mon, 18 May 2015 09:49:26 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 10:49:23 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.243]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Mon, 18 May 2015 17:49:19 +0800 From: Mach Chen To: "adrian@olddog.co.uk" , "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AdCQ7NL1z5h+rMCfRh6yaHESNfVWmwAJHA2A///zgYD//3eMoA== Date: Mon, 18 May 2015 09:49:19 +0000 Message-ID: References: <031b01d090ec$dcfe0160$96fa0420$@olddog.co.uk> <039d01d0914e$14723510$3d569f30$@olddog.co.uk> In-Reply-To: <039d01d0914e$14723510$3d569f30$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 09:49:30 -0000 Hi Adrian, > > > More likely to be an issue is how to handle OAM on the LSP that has > > > end-to-end encryption but where the OAM is targeted at a transit > > > node. That is the issue that needs further exploration. > > > > Yes, traceroute is such a typical scenario. For end-to-end encryption, > > the > transit > > nodes should not (and for OS purpose, it MUST not) know how to decrypt > > the packets, then traceroute will fail. >=20 > Yup. > The thing I'd like to look at is whether it would be OK to run the OAM > (specifically intermediate-node action OAM) without encryption.=20 Seems that this is the only feasible way to go.=20 >But I think there are some issues with ECMP. Indeed, you have to introduce EL then. >=20 Best regards, Mach From nobody Mon May 18 03:04:15 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7851A8853 for ; Mon, 18 May 2015 03:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=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 ERrd57zKe-ot for ; Mon, 18 May 2015 03:04:11 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B571A8877 for ; Mon, 18 May 2015 03:04:05 -0700 (PDT) Received: by wgjc11 with SMTP id c11so20338615wgj.0 for ; Mon, 18 May 2015 03:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uTTAQi7kT2eIAxA/Pq+zQxKyjhiuvOsdvHPvoiyUxuk=; b=UxFGUf4g3G2yg+GAou5IVQ0+7eFiOMirldgzBe0zniTH682p+GVRoohEXG14ASSUoE ePKIIlbwB+lgLPqaQbyi6wPD0V08wkpL/CGju4xIqVGT7cWfNGzTdiJwg5jNNW5bZ1e6 x5mssfNBO2nRj7lGmh3MBSo54avxYKPyBY/PFIiXrkKKQce9XhYMBK9ZKrmIKXNzEVIR VwzlBiwUIzbQDP8WCIOHWH0afqMU5uhKVndB7psQrp9Y3W8uF6FIUuvok/yJt7D1jhr0 WdQJ29zBf3r/wVp+liiExADknVAZXUZmkRY/Q8ryPtzsRYabH+La0yOXdm3mUyHyx7ur Iq5w== MIME-Version: 1.0 X-Received: by 10.194.123.4 with SMTP id lw4mr33290160wjb.94.1431943444320; Mon, 18 May 2015 03:04:04 -0700 (PDT) Received: by 10.27.128.196 with HTTP; Mon, 18 May 2015 03:04:04 -0700 (PDT) In-Reply-To: <038a01d09148$a2f87890$e8e969b0$@olddog.co.uk> References: <031c01d090f2$b71ab2d0$25501870$@olddog.co.uk> <038a01d09148$a2f87890$e8e969b0$@olddog.co.uk> Date: Mon, 18 May 2015 18:04:04 +0800 Message-ID: From: Lizhong Jin To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=089e01227ee05665160516585088 Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 10:04:14 -0000 --089e01227ee05665160516585088 Content-Type: text/plain; charset=UTF-8 Hi Adrian, We are aligned now. If I compare the MEL+ControlWord with ESP/AH in IPSec, there is "Next Header" in ESP/AH to indicate the encrypted payload type. For current mechanism, the MEL should not be inserted/applied in PHP case. Lizhong On Mon, May 18, 2015 at 4:57 PM, Adrian Farrel wrote: > Hi again, > > >>>> Section 3, Everything that follows the control word is the entire > >>>> original MPLS packet encrypted. > >>> > >>> [Lizhong] also for Figure1, in the PHP case, the original MPLS packet > will > >>> not have label, then if the packet is also encrypted and encapsulated > >>> after control work, then how to parse the packet correctly? The control > >>> word will not tell the following payload is MPLS or IP. > >> > >> Hmmm, you are talking, I suppose, about the hop-by-hop encryption mode > >> on a final hop of an LSP that is using PHP. > >> In this case there is nothing to encrypt except the payload. > >> Nevertheless, I am not sure I understand your question. > >> Consider what happens when the packet is not encrypted on the final hop > >> of an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y pops > the last > >> remaining label from the packet and forwards it on the designated > interface > >> to LSR Z. LSR Z has no control word or other means to use to determine > >> what the received packet is. It may sniff the first nibble if it knows > the > >> packet is IPv4 or IPv6, or if it hopes to find a PW control word. Or > LSR Z may > >> know something magic about the incoming interface (for example that it > is > >> an MPLS interface and that the packet will have more labels). > >> Now if encryption is in use, then LSR Z has agreed to its use. That > means > >> that LSR Z is expecting to label 15, the MEL, and a control word at the > top > >> of the packet. So it will remove those three things, decrypt the > packet, and > >> then treat the rest of the packet exactly as it would in the case where > >> encryption is not in use. > >> > >> We could clarify this by noting that the label stack shown on the left > hand > >> side of Figure 1 is of arbitrary depth. That would include zero labels > in the > >> PHP case. However, I think this is a bit obvious. > > > > [Lizhong] Let my try to describe with an example. In Ethernet > environment, > > LSR Z receives the packet, and parse the payload by checking EthType, > with > > "0x80" as IPv4. When MEL is inserted, the EthType has to be changed to > > "MPLS" type (0x8847/8848), and lost the original payload type > information. > > And the MEL and control word does not have capability to indicate the > > payload type for parsing. > > You're right. With PHP in my example, LSR Y (that strips the label) > determines what the packet type is, and uses that to set the Ethertype. > Using encryption, it would be LSR Z that had to do this. But it would be > the same function. > > An alternative here would be to run encryption only as far as the > penultimate hop, but that leaves the last hop exposed. > > So, to me it seems that if you want to run end-to-end encryption, you > probably want to run it without PHP. > > >>> When decryption at the egress LER, the TTL&TC processing of the first > >>> decrypted label should be a bit different with previous mechanism. > >>> The TTL&TC value may need to inherit from the label before MEL in > >>> uniform mode. > >> > >> Indeed. This is how tunnelling works. You think we should explain that? > > > > [Lizhong] Yes, it is better to mention that, or have a reference in the > draft. > > OK. Will do. > > Cheers, > Adrian > > --089e01227ee05665160516585088 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,
We are aligned now. If I compare the MEL+Co= ntrolWord with ESP/AH in IPSec, there is "Next Header" in ESP/AH = to indicate the encrypted payload type. For current mechanism, the MEL shou= ld not be inserted/applied in PHP case.

Lizhong


On Mo= n, May 18, 2015 at 4:57 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi again,

>>>> Section 3, Everything that follows the control word is the= entire
>>>> original MPLS packet encrypted.
>>>
>>> [Lizhong] also for Figure1, in the PHP case, the original MPLS= packet will
>>> not have label, then if the packet is also encrypted and encap= sulated
>>> after control work, then how to parse the packet correctly? Th= e control
>>> word will not tell the following payload is MPLS or IP.
>>
>> Hmmm, you are talking, I suppose, about the hop-by-hop encryption = mode
>> on a final hop of an LSP that is using PHP.
>> In this case there is nothing to encrypt except the payload.
>> Nevertheless, I am not sure I understand your question.
>> Consider what happens when the packet is not encrypted on the fina= l hop
>> of an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y = pops the last
>> remaining label from the packet and forwards it on the designated = interface
>> to LSR Z. LSR Z has no control word or other means to use to deter= mine
>> what the received packet is. It may sniff the first nibble if it k= nows the
>> packet is IPv4 or IPv6, or if it hopes to find a PW control word. = Or LSR Z may
>> know something magic about the incoming interface (for example tha= t it is
>> an MPLS interface and that the packet will have more labels).
>> Now if encryption is in use, then LSR Z has agreed to its use. Tha= t means
>> that LSR Z is expecting to label 15, the MEL, and a control word a= t the top
>> of the packet. So it will remove those three things, decrypt the p= acket, and
>> then treat the rest of the packet exactly as it would in the case = where
>> encryption is not in use.
>>
>> We could clarify this by noting that the label stack shown on the = left hand
>> side of Figure 1 is of arbitrary depth. That would include zero la= bels in the
>> PHP case. However, I think this is a bit obvious.
>
> [Lizhong] Let my try to describe with an example. In Ethernet environm= ent,
> LSR Z receives the packet, and parse the payload by checking EthType, = with
> "0x80" as IPv4. When MEL is inserted, the EthType has to be = changed to
> "MPLS" type (0x8847/8848), and lost the original payload typ= e information.
> And the MEL and control word does not have capability to indicate the<= br> > payload type for parsing.

You're right. With PHP in my example, LSR Y (that strips th= e label) determines what the packet type is, and uses that to set the Ether= type. Using encryption, it would be LSR Z that had to do this. But it would= be the same function.

An alternative here would be to run encryption only as far as the penultima= te hop, but that leaves the last hop exposed.

So, to me it seems that if you want to run end-to-end encryption, you proba= bly want to run it without PHP.

>>> When decryption at the egress LER, the TTL&TC processing o= f the first
>>> decrypted label should be a bit different with previous mechan= ism.
>>> The TTL&TC value may need to inherit from the label before= MEL in
>>> uniform mode.
>>
>> Indeed. This is how tunnelling works. You think we should explain = that?
>
> [Lizhong] Yes, it is better to mention that, or have a reference in th= e draft.

OK. Will do.

Cheers,
Adrian


--089e01227ee05665160516585088-- From nobody Mon May 18 06:53:15 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030B01A89C6; Mon, 18 May 2015 06:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 XLp1JW4va0ZR; Mon, 18 May 2015 06:53:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6041A8737; Mon, 18 May 2015 06:53:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150518135311.24179.1817.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 06:53:11 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-bonica-mpls-self-ping-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 13:53:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LSP Self-Ping Authors : Ravi Torvi Ron Bonica Ina Minei Michael Conn Dante Pacella Luis Tomotaki Mark Wygant Filename : draft-bonica-mpls-self-ping-05.txt Pages : 11 Date : 2015-05-18 Abstract: When certain RSVP-TE optimizations are implemented, ingress LSRs can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through an LSP as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This memo describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is an extremely light-weight mechanism. It does not consume control plane resources on transit or egress LSRs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-ping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-bonica-mpls-self-ping-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-bonica-mpls-self-ping-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 Mon May 18 09:06:38 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7651ACC8C; Mon, 18 May 2015 09:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 YwpSM7VO7FfA; Mon, 18 May 2015 09:06:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF6C1AC3F2; Mon, 18 May 2015 09:06:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150518160634.28589.17837.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 09:06:34 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-bonica-mpls-self-ping-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:06:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LSP Self-Ping Authors : Ravi Torvi Ron Bonica Ina Minei Michael Conn Dante Pacella Luis Tomotaki Mark Wygant Filename : draft-bonica-mpls-self-ping-06.txt Pages : 11 Date : 2015-05-18 Abstract: When certain RSVP-TE optimizations are implemented, ingress LSRs can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through an LSP as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This memo describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is an extremely light-weight mechanism. It does not consume control plane resources on transit or egress LSRs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-ping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-bonica-mpls-self-ping-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-bonica-mpls-self-ping-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 18 14:20:59 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAB81ACD13; Mon, 18 May 2015 14:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 HHjQzkvfIOMb; Mon, 18 May 2015 14:20:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 085B11ACD10; Mon, 18 May 2015 14:20:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67723180092; Mon, 18 May 2015 14:19:18 -0700 (PDT) To: Alexander.Vainshtein@ecitele.com, matthew.bocci@alcatel-lucent.com, martin.vigoureux@alcatel-lucent.com, stbryant@cisco.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150518211918.67723180092@rfc-editor.org> Date: Mon, 18 May 2015 14:19:18 -0700 (PDT) Archived-At: Cc: mpls@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Errata Rejected] RFC5586 (4364) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:20:58 -0000 The following errata report has been rejected for RFC5586, "MPLS Generic Associated Channel". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364 -------------------------------------- Status: Rejected Type: Technical Reported by: Alexander ("Sasha") Vainshtein Date Reported: 2015-05-12 Rejected by: Deborah Brungard (IESG) Section: 4.2.1 Original Text ------------- The Time-To-Live (TTL) field of the LSE that contains the GAL follows the definition and processing rules specified in [RFC3443]. Corrected Text -------------- The value of the Time-To-Live (TTL) field of the LSE that contains the GAL follows is irrelevant as long as it exceeds 1. (Setting this value to 0 or 1 SHOULD be avoided because it could result in trapping the OAM packets in with wrong reason: "TTL expiration" instead of "GAL encountered"). Notes ----- The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet. As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable. --VERIFIER NOTES-- This proposes a change to the RFC which needs to be agreed via working group consensus. -------------------------------------- RFC5586 (draft-ietf-mpls-tp-gach-gal-06) -------------------------------------- Title : MPLS Generic Associated Channel Publication Date : June 2009 Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon May 18 20:07:51 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9291B2DC1 for ; Mon, 18 May 2015 20:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0CfebZu4zT7t for ; Mon, 18 May 2015 20:07:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757731B2DC9 for ; Mon, 18 May 2015 20:07:43 -0700 (PDT) Received: from CO2PR0501MB918.namprd05.prod.outlook.com (10.141.247.21) by CO2PR0501MB1046.namprd05.prod.outlook.com (25.160.7.145) with Microsoft SMTP Server (TLS) id 15.1.160.19; Tue, 19 May 2015 03:07:23 +0000 Received: from CO2PR0501MB919.namprd05.prod.outlook.com (10.141.247.22) by CO2PR0501MB918.namprd05.prod.outlook.com (10.141.247.21) with Microsoft SMTP Server (TLS) id 15.1.154.19; Tue, 19 May 2015 03:07:21 +0000 Received: from CO2PR0501MB919.namprd05.prod.outlook.com ([10.141.247.22]) by CO2PR0501MB919.namprd05.prod.outlook.com ([10.141.247.22]) with mapi id 15.01.0136.026; Tue, 19 May 2015 03:07:21 +0000 From: Markus Jork To: "draft-mirsky-mpls-residence-time@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Thread-Index: AQHQhky5/TZVw2OytkinhxfixmtGu52Cp6zw Date: Tue, 19 May 2015 03:07:21 +0000 Message-ID: References: <55473BCB.70709@pi.nu> In-Reply-To: <55473BCB.70709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mjork@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB918; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB1046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO2PR0501MB918; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB918; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(33656002)(87936001)(106356001)(105586002)(101416001)(92566002)(46102003)(106116001)(86362001)(74316001)(5001770100001)(230783001)(2656002)(189998001)(5001830100001)(5001960100002)(5001860100001)(64706001)(54356999)(5001920100001)(76176999)(50986999)(66066001)(77096005)(77156002)(62966003)(4001540100001)(68736005)(97736004)(99286002)(81156007)(19580395003)(2950100001)(76576001)(2900100001)(102836002)(2501003)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB918; H:CO2PR0501MB919.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 03:07:21.3331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB918 X-OriginatorOrg: juniper.net Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 03:07:49 -0000 SSB3YXMgYXNrZWQgdG8gcmV2aWV3IGRyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lLTA2 LnR4dCBhcyBwYXJ0IG9mIHRoZSByZXZpZXcgdGVhbSBwcm9jZXNzLg0KDQpUaGUgZG9jdW1lbnQg cHJvdmlkZXMganVzdGlmaWNhdGlvbiBmb3Igd2h5IHJlc2lkZW5jZSB0aW1lIG1lYXN1cmVtZW50 IGZvciBNUExTIExTUHMgbWF5IGJlIHVzZWZ1bCBhbmQgY29oZXJlbnRseSBkZXNjcmliZXMgdGhl IHByb2NlZHVyZSBmb3IgcGVyZm9ybWluZyBpdC4gSG93ZXZlciwgSSBjb3VsZCBub3QgdW5kZXJz dGFuZCB0aGUgMi1zdGVwIHByb2Nlc3MgZnJvbSByZWFkaW5nIHRoaXMgZG9jdW1lbnQuDQoNClRo ZSBwcm9wb3NlZCByc3ZwIGV4dGVuc2lvbnMgbG9vayB0ZWNobmljYWxseSBzb3VuZC4gVGhvdWdo IEkgZG8gcXVlc3Rpb24gdGhlIGV4dHJhIGNvbXBsZXhpdHkgaW50cm9kdWNlZCBmb3Iga2VlcGlu ZyB0cmFjayBvZiB0aGUgUlRNIGNhcGFibGUgTFNScyAodXNpbmcgdGhlIFJUTV9TRVQgb2JqZWN0 KS4gV2hpbGUgSSBnZW5lcmFsbHkgdW5kZXJzdGFuZCB0aGUgdmFsdWUgaW4gc3VwcG9ydGluZyBp bmNyZW1lbnRhbCBkZXBsb3ltZW50IG9mIG5ldyBmZWF0dXJlcywgSSBkbyB3b25kZXIgaG93IG11 Y2ggdmFsdWUgdGhlcmUgaXMgaW4gZG9pbmcgcGFydGlhbCByZXNpZGVuY2UgdGltZSBtZWFzdXJl bWVudHMgZm9yIHJhbmRvbSBzdWItc2VjdGlvbnMgb2YgYW4gTFNQPyBBcmUgdGhlIGluY29tcGxl dGUgbWVhc3VyZW1lbnRzIGRvbmUgaW4gc3VjaCBhIHNjZW5hcmlvIHJlYWxseSB3b3J0aCB0aGUg YWRkZWQgcHJvdG9jb2wgY29tcGxleGl0eT8NCg0KVGhlIGRvY3VtZW50IHRhbGtzIGFib3V0IHRo ZSBkaWZmaWN1bHRpZXMgb2YgYXBwbHlpbmcgdGhlIG1lYXN1cmVtZW50IHByb2NlZHVyZSB0byBM RFAgbmV0d29ya3MgZHVlIHRvIEVDTVAuIE1heWJlIGl0IHNob3VsZCBhbHNvIGRpc2N1c3MgcG90 ZW50aWFsIGRpZmZpY3VsdGllcyB3aXRoIHJzdnAgd2hlbiB0aGVyZSBpcyBsaW5rIGFnZ3JlZ2F0 aW9uL2J1bmRsaW5nIHdoaWNoIGNvdWxkIGxlYWQgdG8gbG9hZC1iYWxhbmNpbmcgb3ZlciBtdWx0 aXBsZSBlZ3Jlc3MgaW50ZXJmYWNlcz8NCg0KSSBjYW4ndCByZWFsbHkgY29tbWVudCBvbiB0aGUg dXNlZnVsbmVzcyBvZiB0aGUgZG9jdW1lbnQgYXMgSSdtIG5vdCBmYW1pbGlhciB3aXRoIHRoZSB0 aW1lIHN5bmNocm9uaXphdGlvbiBwcm90b2NvbHMgYW5kIHVzZSBjYXNlcy4NClVuZGVyIHRoZSBh c3N1bXB0aW9uIHRoYXQgcGFydGlhbCByZXNpZGVuY2UgdGltZSBtZWFzdXJlbWVudHMgZm9yIGFu IExTUCBhcmUgdXNlZnVsLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgV0cgYWRv cHRpb24uDQoNCi1NYXJrdXMNCg== From nobody Wed May 20 02:55:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31431B35BC for ; Wed, 20 May 2015 02:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E7r1NrOrNGde for ; Wed, 20 May 2015 02:55:43 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1281B35B3 for ; Wed, 20 May 2015 02:55:43 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D914D18013E6; Wed, 20 May 2015 11:55:41 +0200 (CEST) Message-ID: <555C5A1D.7020709@pi.nu> Date: Wed, 20 May 2015 11:55:41 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 09:55:45 -0000 Working Group, This is to start a two week poll on adopting draft-bonica-mpls-self- ping-06 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is one IPR disclosures directly against this document. All the authors has stated on the working group mailing that they are unaware of any undisclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends June 5, 2015. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu May 21 12:13:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88001A88D0; Thu, 21 May 2015 12:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 jACzdQNNcyDf; Thu, 21 May 2015 12:12:56 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA301A87C7; Thu, 21 May 2015 12:12:56 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so15699323ieb.0; Thu, 21 May 2015 12:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lcc7o4aXAZgFAkRJitDK10Bvu4P3v8cH+NvUYGHzdqw=; b=zbRCKOUW9vCBX3l2B78WCNe50xHK/ir3NBdB1V2k/7smbr7Zxvz+7K4VUxGR28/P4R 4MVKenscq2ZH6rDZE1whEfeR6A+5CaUoR05aq5DVQa1RCC7nZzvH1/ig5/xVXbU5AmCO Rzn4jmGTT4o0cgneBfNIW7slwqLRtlrL8O70SAdNOpf6757uWB1aqQSNA8sXEIeeBJcN XTAsKaxp5gd8/HJ7E3SihN3PLdjbuN1GFRs24eXVOJm2MMUrEiSzhIif9/JqlyRC2oIO EmmAdQ9hFeKiiOVptw7+emU+58L4g+2Rf81CCJuBiSojbHF/7GbcJSt4YxX3FTJtwlJW ix3g== X-Received: by 10.50.43.227 with SMTP id z3mr336386igl.12.1432235575649; Thu, 21 May 2015 12:12:55 -0700 (PDT) Received: from [172.16.51.165] ([172.16.51.165]) by mx.google.com with ESMTPSA id k16sm1967680igf.19.2015.05.21.12.12.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 12:12:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: IETF In-Reply-To: <20150504195805.GB25036@pfrc.org> Date: Thu, 21 May 2015 12:12:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: <1881995B-EBF8-4F7B-8B80-4D4B04C78F60@gmail.com> References: <20150504195805.GB25036@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.2098) Archived-At: Cc: mpls@ietf.org, rtg-bfd@ietf.org Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:12:58 -0000 Sorry for the delayed response. I am not aware of any IPR related to this document. Support the last call of this draft. -sam > On May 4, 2015, at 12:58 PM, Jeffrey Haas wrote: > > The BFD mailing list has been quiet since shortly after IETF 92. We have a > number of documents that seem stable and ready to advance. > > This email begins a two week Working Group Last Call for > draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884. > > This last call will end on May 15. > > Simultaneously, the authors of this draft should state to the mailing list > whether there is any IPR associated with this draft or not. > > This WGLC is also being cc'd to mpls@ietf to permit additional commentary. > > -- Jeff and Nobo > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri May 22 10:34:06 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2A1A8707 for ; Fri, 22 May 2015 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_PASS=-0.001] autolearn=ham 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 4tc8jlOkyW7n for ; Fri, 22 May 2015 10:34:03 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFCE1A702F for ; Fri, 22 May 2015 10:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1432316043; x=1463852043; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8a0EjY00UKH4LQ8e+m748Svv1lgI6pdyLUgHjS9r9/A=; b=aA0NkrHXoJo+h8DVZne8JXk/bnHf9gBJT4hB6kl9z8dCrcOtPRzcZoR0 /k4rfm//+0XR0Fp50J7tCACIPDR5zknuPk3E4KinKD1S+9fh/t/BGoE2K jgwPeCquUFOp5wC0kw0JauewU4wzaj6VUL41B7ZB0oJQ+cjuq4hsaRbNP A=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 22 May 2015 17:34:02 +0000 From: "Conn, Michael" X-IronPort-AV: E=Sophos;i="5.13,477,1427760000"; d="scan'208";a="21590346" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 22 May 2015 17:34:01 +0000 Received: from FHDP1LUMXC7V43.us.one.verizon.com ([166.68.125.38]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 22 May 2015 13:34:01 -0400 To: "mpls@ietf.org" Date: Fri, 22 May 2015 13:34:00 -0400 Thread-Topic: Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AdCS4yzUKVW5jYo4TNG2v+QF7ALdwgB0gdIw Message-ID: <2B7669201D58CD4C8A2150DB12B129CF1690A46C60@FHDP1LUMXC7V43.us.one.verizon.com> References: <555C5A1D.7020709@pi.nu> In-Reply-To: <555C5A1D.7020709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-bonica-mpls-self-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:34:05 -0000 U3VwcG9ydA0KDQpNaWNoYWVsIEUgQ29ubg0KTWFuYWdlciBOZXR3b3JrIFBsYW5uaW5nDQpPZmZp Y2UgOTcyIDcyOSA2NDY5DQrCoA0KVGhlcmUgYXJlIHR3byB3YXlzIHRvIGRlYWwgd2l0aCBhIHBy b2JsZW06DQpZb3UgY2FuIGFjY2VwdCBpdCBhbmQgbGVhcm4gdG8gbGl2ZSB3aXRoIGl0IG9yDQp5 b3UgY2FuIGZpeCBpdCBhbmQgbGVhcm4gdG8gbGl2ZSB3aXRob3V0IGl0Lg0KwqANCldoaWNoIHdp bGwgeW91IGNob29zZT8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvYSBB bmRlcnNzb24gW21haWx0bzpsb2FAcGkubnVdIA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjAsIDIw MTUgNDo1NiBBTQ0KVG86IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWJvbmljYS1tcGxzLXNlbGYtcGlu Z0B0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFBv bGwgdG8gc2VlIGlmIHdlIGhhdmUgY29uc2Vuc3VzIGFkb3B0aW5nIGRyYWZ0LWJvbmljYS1tcGxz LXNlbGYtcGluZyBhcyBhbiBNUExTIHdnIGRvY3VtZW50DQoNCldvcmtpbmcgR3JvdXAsDQoNClRo aXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIGFkb3B0aW5nIGRyYWZ0LWJvbmljYS1t cGxzLXNlbGYtDQpwaW5nLTA2IGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0K UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1w bHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2 ZSBhIHRlY2huaWNhbCBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVz cGVjaWFsbHkgaWYgeW91IHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRv cHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNClRoZXJlIGlzIG9uZSBJUFIgZGlz Y2xvc3VyZXMgZGlyZWN0bHkgYWdhaW5zdCB0aGlzIGRvY3VtZW50LiBBbGwgdGhlIGF1dGhvcnMg aGFzIHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIHRoYXQgdGhleSBhcmUgdW5h d2FyZSBvZiBhbnkgdW5kaXNjbG9zZWQgSVBScyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQoNCkhv d2V2ZXIgaWYgeW91IGFyZSBvbiB0aGUgdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QgYW5kIGF3YXJlIG9mIElQUiB0aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdCwgdGhlIHRpbWUg dG8gZGlzY2xvc2UgdGhpcyBpcyBub3cuDQoNClRoaXMgcG9sbCBlbmRzIEp1bmUgNSwgMjAxNS4N Cg0KL0xvYQ0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVt YWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAg ICAgICAgICAgICAgICAgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50 KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Fri May 22 10:36:28 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1377A1A874B for ; Fri, 22 May 2015 10:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 o76xowUkiDBd for ; Fri, 22 May 2015 10:36:22 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3E91A7D81 for ; Fri, 22 May 2015 10:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1432316182; x=1463852182; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OzCQDsN6nicXAJGpJP+QY7XXQdMraiNQklKXeS09d/I=; b=qhVpGR8beBZ45rxGEwtHWg+O3DxYtkow1ZIGWjEAwGA+AHspVl1A+2dl 0cShwLZ5XEVNnZ1MIPFvtYMk2ePWRQ12U/7Im+0QadsODHMUjQEPYuEk3 WG6n7AzeiY4gTllIMSNL5k8V4bfW8ckp1xXbMNsWuEjjXeRvvYWrw9Zo8 o=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 22 May 2015 17:36:21 +0000 From: "Tomotaki, Luis M" To: "Conn, Michael" , "mpls@ietf.org" X-IronPort-AV: E=Sophos;i="5.13,477,1427760000"; d="scan'208";a="21591011" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 22 May 2015 17:36:21 +0000 Received: from FHDP1LUMXC7V91.us.one.verizon.com ([166.68.240.155]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Fri, 22 May 2015 13:36:21 -0400 Date: Fri, 22 May 2015 13:36:19 -0400 Thread-Topic: Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AdCS4yzUKVW5jYo4TNG2v+QF7ALdwgB0gdIwAAAiy4A= Message-ID: <467340A77F13C944919805BFF3B8ACFC3006EAC36D@FHDP1LUMXC7V91.us.one.verizon.com> References: <555C5A1D.7020709@pi.nu> <2B7669201D58CD4C8A2150DB12B129CF1690A46C60@FHDP1LUMXC7V43.us.one.verizon.com> In-Reply-To: <2B7669201D58CD4C8A2150DB12B129CF1690A46C60@FHDP1LUMXC7V43.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-bonica-mpls-self-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:36:27 -0000 U3VwcG9ydA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ29ubiwgTWljaGFl bCBbbWFpbHRvOm1pY2hhZWwuZS5jb25uQHZlcml6b24uY29tXSANClNlbnQ6IEZyaWRheSwgTWF5 IDIyLCAyMDE1IDEyOjM0IFBNDQpUbzogbXBsc0BpZXRmLm9yZw0KQ2M6IGRyYWZ0LWJvbmljYS1t cGxzLXNlbGYtcGluZ0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFBvbGwgdG8gc2VlIGlm IHdlIGhhdmUgY29uc2Vuc3VzIGFkb3B0aW5nIGRyYWZ0LWJvbmljYS1tcGxzLXNlbGYtcGluZyBh cyBhbiBNUExTIHdnIGRvY3VtZW50DQoNClN1cHBvcnQNCg0KTWljaGFlbCBFIENvbm4NCk1hbmFn ZXIgTmV0d29yayBQbGFubmluZw0KT2ZmaWNlIDk3MiA3MjkgNjQ2OQ0KwqANClRoZXJlIGFyZSB0 d28gd2F5cyB0byBkZWFsIHdpdGggYSBwcm9ibGVtOg0KWW91IGNhbiBhY2NlcHQgaXQgYW5kIGxl YXJuIHRvIGxpdmUgd2l0aCBpdCBvciB5b3UgY2FuIGZpeCBpdCBhbmQgbGVhcm4gdG8gbGl2ZSB3 aXRob3V0IGl0Lg0KwqANCldoaWNoIHdpbGwgeW91IGNob29zZT8NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnVdDQpTZW50 OiBXZWRuZXNkYXksIE1heSAyMCwgMjAxNSA0OjU2IEFNDQpUbzogbXBsc0BpZXRmLm9yZzsgZHJh ZnQtYm9uaWNhLW1wbHMtc2VsZi1waW5nQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZw0KU3ViamVjdDogUG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5zdXMgYWRv cHRpbmcgZHJhZnQtYm9uaWNhLW1wbHMtc2VsZi1waW5nIGFzIGFuIE1QTFMgd2cgZG9jdW1lbnQN Cg0KV29ya2luZyBHcm91cCwNCg0KVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24g YWRvcHRpbmcgZHJhZnQtYm9uaWNhLW1wbHMtc2VsZi0NCnBpbmctMDYgYXMgYW4gTVBMUyB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0 L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAobXBs c0BpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsIG1vdGl2YXRpb24gZm9yIHlvdXIg c3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdCB0aGUgZG9j dW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4N Cg0KVGhlcmUgaXMgb25lIElQUiBkaXNjbG9zdXJlcyBkaXJlY3RseSBhZ2FpbnN0IHRoaXMgZG9j dW1lbnQuIEFsbCB0aGUgYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwIG1h aWxpbmcgdGhhdCB0aGV5IGFyZSB1bmF3YXJlIG9mIGFueSB1bmRpc2Nsb3NlZCBJUFJzIGFnYWlu c3QgdGhpcyBkb2N1bWVudC4NCg0KSG93ZXZlciBpZiB5b3UgYXJlIG9uIHRoZSB0aGUgbXBscyB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBhbmQgYXdhcmUgb2YgSVBSIHRoYXQgcmVsYXRlcyB0 byB0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZSB0aGlzIGlzIG5vdy4NCg0KVGhpcyBw b2xsIGVuZHMgSnVuZSA1LCAyMDE1Lg0KDQovTG9hDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9y IE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1YXdlaSBU ZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K From nobody Fri May 22 21:36:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED19D1A9062 for ; Fri, 22 May 2015 21:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 PQOVQg7hbzlG for ; Fri, 22 May 2015 21:36:25 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B950B1A9061 for ; Fri, 22 May 2015 21:36:24 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4N4aLTa024422; Sat, 23 May 2015 05:36:21 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4N4aKbK024407 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 23 May 2015 05:36:21 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , , , References: <555C5A1D.7020709@pi.nu> In-Reply-To: <555C5A1D.7020709@pi.nu> Date: Sat, 23 May 2015 05:36:19 +0100 Message-ID: <030c01d09512$03e93730$0bbba590$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGPBSUHLT6Yhr1Sj3be+DuaUdYTOJ4MFrjQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21564.002 X-TM-AS-Result: No--11.879-10.0-31-10 X-imss-scan-details: No--11.879-10.0-31-10 X-TMASE-MatchedRID: QW5G6BKkLTq2uGZ0VrPO/SuRmcDMF+7viEoqWVVgjSu638ZUY6gSd1n2 Ud+yOflTo1rqzSpfPGf4FCQu3njb1EBA3sXWvnpKQz/LkQyz8ma36GGfwjLoZdp1biJhIyNROvP q8HDlJICvOAhGSZyMlUsvpJ9XUFGNBQnatCb2G2WepOo7UqIl+UCrr/LkAQ46ieLg/9VIOEZ+DN kCAl6R49HvjCIO82W+rJbC9TPJpY42ACKRV745AXFpe+85TnNu+KgiyLtJrSCyd65qZFFPkzpbf dTAcNXm4vM1YF6AJbZcLc3sLtjOt1ZFWWuOwo7w3QfwsVk0UbtuRXh7bFKB7l7fWez7l+JJrKwG D7BM1LYWSJ5xkbBVypW3YcuJUfMeCStjCuOR/hg= Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 04:36:29 -0000 Hi Loa, I think this is a useful tool and the document is stable enough to be within the working group. The explanation of why the function is needed (which really clarifies how it is used) would be enhanced by reference to RFC 6383 which describes the problems associated with RSVP-TE signaling and LSP establishment. Cheers, Adrian > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 20 May 2015 10:56 > To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; mpls- > chairs@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self- > ping as an MPLS wg document > > Working Group, > > This is to start a two week poll on adopting draft-bonica-mpls-self- > ping-06 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is one IPR disclosures directly against this document. All the > authors has stated on the working group mailing that they are unaware of > any undisclosed IPRs against this document. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends June 5, 2015. > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun May 24 14:38:35 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1D41AD2EE for ; Sun, 24 May 2015 14:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 ObYYZkz08Eel for ; Sun, 24 May 2015 14:38:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913561AD2DF for ; Sun, 24 May 2015 14:38:03 -0700 (PDT) Received: from BLUPR05MB1985.namprd05.prod.outlook.com (25.162.224.27) by BLUPR05MB1985.namprd05.prod.outlook.com (25.162.224.27) with Microsoft SMTP Server (TLS) id 15.1.172.22; Sun, 24 May 2015 21:38:01 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([25.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([25.162.224.27]) with mapi id 15.01.0172.012; Sun, 24 May 2015 21:38:01 +0000 From: Ronald Bonica To: "adrian@olddog.co.uk" , 'Loa Andersson' , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQGPBSUHLT6Yhr1Sj3be+DuaUdYTOJ4MFrjQgAKykVA= Date: Sun, 24 May 2015 21:38:00 +0000 Message-ID: References: <555C5A1D.7020709@pi.nu> <030c01d09512$03e93730$0bbba590$@olddog.co.uk> In-Reply-To: <030c01d09512$03e93730$0bbba590$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1985; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:BLUPR05MB1985; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1985; x-forefront-prvs: 058637CA05 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(252514010)(52604005)(13464003)(51704005)(37854004)(5001770100001)(2656002)(54356999)(19580395003)(122556002)(50986999)(87936001)(66066001)(19580405001)(46102003)(106116001)(81156007)(4001540100001)(76176999)(106356001)(92566002)(97736004)(105586002)(99286002)(101416001)(40100003)(230783001)(33656002)(2501003)(77156002)(62966003)(68736005)(2900100001)(2950100001)(2201001)(189998001)(5001960100002)(15975445007)(64706001)(107886002)(102836002)(74316001)(86362001)(76576001)(5001830100001)(5001860100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1985; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2015 21:38:00.2487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1985 Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 21:38:27 -0000 Adrian, Thanks for calling my attention to RFC 6383! I will reference it in the ne= xt revision of the draft. Ron > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, May 23, 2015 12:36 AM > To: 'Loa Andersson'; mpls@ietf.org; draft-bonica-mpls-self- > ping@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: RE: [mpls] Poll to see if we have consensus adopting draft-bonic= a- > mpls-self-ping as an MPLS wg document >=20 > Hi Loa, >=20 > I think this is a useful tool and the document is stable enough to be wit= hin > the working group. >=20 > The explanation of why the function is needed (which really clarifies how= it is > used) would be enhanced by reference to RFC 6383 which describes the > problems associated with RSVP-TE signaling and LSP establishment. >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: 20 May 2015 10:56 > > To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; mpls- > > chairs@tools.ietf.org > > Subject: [mpls] Poll to see if we have consensus adopting > draft-bonica-mpls-self- > > ping as an MPLS wg document > > > > Working Group, > > > > This is to start a two week poll on adopting draft-bonica-mpls-self- > > ping-06 as an MPLS working group document. > > > > Please send your comments (support/not support) to the mpls working > > group mailing list (mpls@ietf.org). Please give a technical motivation > > for your support/not support, especially if you think that the > > document should not be adopted as a working group document. > > > > There is one IPR disclosures directly against this document. All the > > authors has stated on the working group mailing that they are unaware > > of any undisclosed IPRs against this document. > > > > However if you are on the the mpls working group mailing list and > > aware of IPR that relates to this draft, the time to disclose this is > > now. > > > > This poll ends June 5, 2015. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun May 24 18:05:51 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D321A879D for ; Sun, 24 May 2015 18:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 F4WHrkDbaxPF for ; Sun, 24 May 2015 18:05:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A612C1A87AC for ; Sun, 24 May 2015 18:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6702; q=dns/txt; s=iport; t=1432515946; x=1433725546; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vD29zupFhxuwMB+j1AqK7z0NE1FIxsPykZgBzn/nzOw=; b=BUPTpOmthnTPIYzoRXRgg98cBiZkVaYMN8Wf+gWGVbNHznvmAtqnzIl6 Klkc4p2SrWjzFrcpNn/8BMePc5N24CScH9wIMs+MMQ5/iL+vJcjWBv0bq rDdxAxJlvFl3sHMMMGHAILKt8L/CUyNY/Z2ChhCMpcuhkasVrhwrAvuja 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BzBQBqdGJV/4kNJK1cgxBUXsJDgj4BCYRpgQ4CgSlMAQEBAQEBgQuEIwEBBAEBAWgDCw4CAgEIOwQHGwwLFBECBA4FiCwN0msBAQEBAQEBAQEBAQEBAQEBAQEBAQETBASLNoQiEQElKAQHgxeBFgWQTII8iw+BKYNxjjyDWSNhgSkcFYE9b4EMgTsBAQE X-IronPort-AV: E=Sophos;i="5.13,488,1427760000"; d="scan'208,217";a="419187665" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP; 25 May 2015 01:05:45 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4P15if9027322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 May 2015 01:05:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Sun, 24 May 2015 20:05:44 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuMs1UydnVSTWUqL7mKuJxzJ252L6BP/ Date: Mon, 25 May 2015 01:05:43 +0000 Message-ID: <60B6FBD5-9354-413B-AC95-2C03407192CD@cisco.com> References: <555C5A1D.7020709@pi.nu> In-Reply-To: <555C5A1D.7020709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_60B6FBD59354413BAC952C03407192CDciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 01:05:49 -0000 --_000_60B6FBD59354413BAC952C03407192CDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Loa, I believe this draft greatly improved based on the MPLS-RT review, and in p= articular Ron has been extremely responsive to and inclusive of feedback. I support adoption of this document, and it is useful in its current scope. I do have a small additional piece of feedback for the author's considerati= on: currently the doc says something like: " For example, if a downstream LSR installs a forwarding state that causes an LSP to terminate at the wrong node, LSP Self-ping will not detect an error." Could we add a similar applicability hat if an LSP is broken mid stream suc= h that the packet is sent unlabeled, then it won't detect an error? Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 20, 2015, at 05:55, Loa Andersson > wrot= e: Working Group, This is to start a two week poll on adopting draft-bonica-mpls-self- ping-06 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a tec= hnical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is one IPR disclosures directly against this document. All the authors has stated on the working group mailing that they are unaware of any undisclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends June 5, 2015. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60B6FBD59354413BAC952C03407192CDciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Loa,

I believe this draft greatly improved based on the MPLS-RT review, and= in particular Ron has been extremely responsive to and inclusive of feedba= ck. 

I support adoption of this document, and it is useful in its current s= cope. 

I do have a small additional piece of feedback for the author's consid= eration: currently the doc says something like:

" For e= xample, if a downstream LSR installs a forwarding state that
   causes an=
 LSP to terminate at the wrong node, LSP Self-ping will not 
   = ;detect an error."

Could we add a similar applicability hat if an LSP is broken mid strea= m such that the packet is sent unlabeled, then it won't detect an error?

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On May 20, 2015, at 05:55, Loa Andersson <l= oa@pi.nu> wrote:

Working Group,

This is to start a two week poll on adopting draft-bonica-mpls-self-<= /span>
ping-06 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org). Please give a technical
motivation for your support/not support, especially if you think that=
the document should not be adopted as a working group document.

There is one IPR disclosures directly against this document. All the<= /span>
authors has stated on the working group mailing that they are unaware= of
any undisclosed IPRs against this document.

However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose<= br> this is now.

This poll ends June 5, 2015.

/Loa
--


Loa Andersson          &= nbsp;           &nbs= p; email: loa@mail01.huawei.com
Senior MPLS Expert         &n= bsp;            = ;    loa@pi.nu<= br> Huawei Technologies (consultant)     phone: += 46 739 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ie= tf.org/mailman/listinfo/mpls
--_000_60B6FBD59354413BAC952C03407192CDciscocom_-- From nobody Sun May 24 22:56:44 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C701B2A6E for ; Sun, 24 May 2015 22:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 bCJFOvQVfY2O for ; Sun, 24 May 2015 22:56:39 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114D51B2A6C for ; Sun, 24 May 2015 22:56:39 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so31930008wic.1 for ; Sun, 24 May 2015 22:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N96Frr/TH0V7lHBg4WICteaHlR/qv21z6216GZvpkbQ=; b=O8xDMRI4bkWRczbL3C85QJIk/U4PyIThHueL+dVSXxHuYnOsAMZMALehqKYZW8vXjp GIDti6oq+Jf8BGKeICnL1sq3vlskAwMph0QI5OTgMwVAhrfbO4dZE+BD4UUXaGPpQaEV IpLCgJVSEuI5bYAFcbQjEumaKQUE63M1eZV+WIn4oY0LWShc5E5P+FphvykW4DXa0Uxi bRyV8CASf2fLyX/zDc1qid0k1sPj8Ej2aRAjBYcfgY4PPD3YpVuv4klgKIDai5HzXp8T 3j6TgrwGuZNn2ze/PmE07M8Sw4z28UrF20cb8g5HSqoFtdDCpqYfrRictdUZZRhs51Gp 1zHQ== X-Received: by 10.180.212.81 with SMTP id ni17mr28472813wic.87.1432533397756; Sun, 24 May 2015 22:56:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.65.135 with HTTP; Sun, 24 May 2015 22:56:17 -0700 (PDT) In-Reply-To: <555C5A1D.7020709@pi.nu> References: <555C5A1D.7020709@pi.nu> From: "Andrew G. Malis" Date: Mon, 25 May 2015 01:56:17 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c3498c4d5e820516e1ac59 Archived-At: Cc: "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 05:56:42 -0000 --001a11c3498c4d5e820516e1ac59 Content-Type: text/plain; charset=UTF-8 I agree with previous comments that this is a useful draft and should be adopted by the WG. If this was written in response to an observed problem in the field, that would be useful to note in Section 1. Assuming that this is the case, it would also be useful to note in an "implementation experience" section if there is an implementation of this draft and it corrects the problem. Cheers, Andy On Wed, May 20, 2015 at 5:55 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting draft-bonica-mpls-self- > ping-06 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is one IPR disclosures directly against this document. All the > authors has stated on the working group mailing that they are unaware of > any undisclosed IPRs against this document. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends June 5, 2015. > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c3498c4d5e820516e1ac59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with previous comments that this is a useful draft= and should be adopted by the WG. If this was written in response to an obs= erved problem in the field, that would be useful to note in Section 1. Assu= ming that this is the case, it would also be useful to note in an "imp= lementation experience" section if there is an implementation of this = draft and it corrects the problem.

Cheers,
And= y

On W= ed, May 20, 2015 at 5:55 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting draft-bonica-mpls-self-
ping-06 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There is one IPR disclosures directly against this document. All the
authors has stated on the working group mailing that they are unaware of any undisclosed IPRs against this document.

However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

This poll ends June 5, 2015.=

/Loa
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=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 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a11c3498c4d5e820516e1ac59-- From nobody Mon May 25 06:32:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457001A8A8C; Mon, 25 May 2015 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 QnX6gm86502s; Mon, 25 May 2015 06:32:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ABE1A8A7E; Mon, 25 May 2015 06:32:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150525133242.29318.55634.idtracker@ietfa.amsl.com> Date: Mon, 25 May 2015 06:32:42 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 13:32:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Relayed Echo Reply mechanism for LSP Ping Authors : Jian Luo Lizhong Jin Thomas Nadeau George Swallow Filename : draft-ietf-mpls-lsp-ping-relay-reply-09.txt Pages : 16 Date : 2015-05-25 Abstract: In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label Switching Router (LSR) to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-relay-reply-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 25 22:11:26 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412BC1A6FCB for ; Mon, 25 May 2015 22:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 tRaFU7t2h5o1 for ; Mon, 25 May 2015 22:11:20 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0656.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::656]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C181A6FBB for ; Mon, 25 May 2015 22:11:19 -0700 (PDT) Received: from DB5PR03MB0999.eurprd03.prod.outlook.com (25.162.154.17) by DB5PR03MB0999.eurprd03.prod.outlook.com (25.162.154.17) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 05:11:00 +0000 Received: from DB5PR03MB0999.eurprd03.prod.outlook.com ([25.162.154.17]) by DB5PR03MB0999.eurprd03.prod.outlook.com ([25.162.154.17]) with mapi id 15.01.0172.012; Tue, 26 May 2015 05:11:00 +0000 From: Yaakov Stein To: "mpls@ietf.org" Thread-Topic: review of draft-mirsky-mpls-residence-time Thread-Index: AdCXce5XYGawVXbQSuScrPNidlsKQA== Date: Tue, 26 May 2015 05:11:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yaakov_s@rad.com; x-originating-ip: [192.116.177.138] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR03MB0999; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB5PR03MB0999; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB0999; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(37854004)(54356999)(110136002)(5001960100002)(107886002)(15975445007)(50986999)(74316001)(189998001)(62966003)(450100001)(77156002)(16236675004)(46102003)(64706001)(2900100001)(66066001)(5001830100001)(68736005)(87936001)(5001860100001)(102836002)(86362001)(2656002)(4001540100001)(2351001)(229853001)(105586002)(230783001)(106356001)(19300405004)(122556002)(92566002)(101416001)(19625215002)(81156007)(33656002)(97736004)(40100003)(76576001)(19580395003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB0999; H:DB5PR03MB0999.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rad.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DB5PR03MB0999B4968F075828150C99FCE5CC0DB5PR03MB0999eurp_" MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 05:11:00.4874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB0999 Archived-At: Subject: [mpls] review of draft-mirsky-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 05:11:25 -0000 --_000_DB5PR03MB0999B4968F075828150C99FCE5CC0DB5PR03MB0999eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loa asked me to comment on this draft before its acceptance as a MPLS WG dr= aft. As far as I understand, the purpose of this draft is to provide a form of w= hat is called "on-path timing support" in the TICTOC WG. The specific kind of on-path support is accumulation of residence times in = LSRs which a time-sensitive flow traverses. As such it is essentially the same as what is called "transparent clocking"= (TC) in IEEE 1588, and the draft indeed re-uses TC technologies. However this draft attempts to remedy a problem with TC as presently implem= ented - its layer violation. This violation occurs since physical layer timing information is used to mo= dify a field of a higher layer protocol. The present draft remedies this by forcing hop-by-hop behavior by TTL field= manipulation, but at the price of having to transport timing flows in the associated chan= nel, previously limited to OAM and control/management plane uses. As such the draft elegantly solves a theoretical problem. I am less sure that it solves a real-world problem, for the following reaso= ns : 1. First is the fact that there is a simpler alternative for on-path suppor= t of 1588 over MPLS that has already passed WG LC in TICTOC. The existing TICTOC draft was purposely constrained (following advice of reviewers who are MPLS experts) to not touch the MPLS forwarding plane, while this draft defines GACh TLVs = and sub-TLVs. The present draft is admittedly much wider in applicability, but no use oth= er than 1588 on-path support is described in the draft. 2. One conceivable use would be for highly accurate one-way delay estimatio= n without synchronized clocks (and I am not sure when this use is really needed). Of course the present method only accounts for residence time in LSRs, not = for propagation latencies on links (which 1588 can handle as well). The methodology to overcome this limitation would assumably be to rely on a= co-routed round-trip, to us this draft to cancel residence times, and then to measure the remaining round-trip time and divide by two. However, existing algorithms do a pretty good job at cancelling residence t= imes except when the flow traverses a large number of network elements which are= heavily loaded with plesiochronously related interfering flows. Do the authors have another use case in mind ? 3. The primary documented application for 1588 in telecom networks is cellu= lar backhaul. This application already has a plethora of solutions, based on GPS, 1588 ov= er Ethernet with boundary clocks (BC), distributed grand masters, etc. etc.= etc. Note that BC as widely deployed is already hop-by-hop, and in that way simi= lar to this draft. Is yet another solution really needed ? 4. Related to the previous questions is the issue of implementation in alre= ady existing networks. This solution requires hardware upgrades at least for the accurate time-sta= mping and possibly for the accumulation and field modification (although the latter may software upgrades, especially if 2-step correction= is utilized). If we need to upgrade hardware, why not deploy BCs ? A few years back I would have said that TC could be implemented in miniatur= ized devices where BC could not, but advances in miniaturization of OCXOs have severely reduced this advanta= ge to cases where atomic-clock hold-over is required. 5. If another solution for this specific application is needed, is it neede= d for MPLS ? Cellular backhaul over carrier Ethernet is widely deployed, is cellular bac= khaul over MPLS sufficiently widespread to merit this extension ? 6. MPLS does not define its own physical layer (which Ethernet does - the l= ayer called ETY in the ITU). As such it is not clear that MPLS is the right place to solve the timing di= stribution problem. MPLS necessarily runs over some physical layer which may already have on-pa= th support, or may more economically support it. All of the authors work for vendors - have these vendors implemented this o= r do they plan implementing ? If the answer is a resounding yes, then I assume that we will hear rebuttal= s to most of the above remarks. Regarding the content of the draft, I have a major issue with the use of th= e term "Scratch Pad" for the correction field (and BTW, it is sometimes called "Scratch Pad" and sometimes "ScratchPad" a= nd sometimes "scratch pad"). This field is not some opaque meta-data transported by this newly defined h= eader, it is the very crux of the solution and requires manipulation to work. Calling it a "scratch pad" (with any of the spellings) is tantamount to cal= ling an MPLS label an "arbitrary bit-field". Both terms may be technically correct, but hide the meaning of the field an= d increase the load on reader in understanding the technology. As an aside, the aforementioned TICTOC WG draft originally contained extens= ions to OSPF, RSVP-TE, etc. It was decided to separate the control extensions from the forwarding plane= draft, and to pursue each in the most appropriate WG. It might be a good idea to do the same here. One of the facts of life with on-path support of timing distribution is tha= t it is often only partial. What happens to this solution when there is only partial support? I can imagine unrecognized GACh packets being booted to CPU in such cases, = severely impacting uncompensated residence time. Y(J)S --_000_DB5PR03MB0999B4968F075828150C99FCE5CC0DB5PR03MB0999eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Loa asked me to comment on this draft before its acc= eptance as a MPLS WG draft.

 

As far as I understand, the purpose of this draft is= to provide a form of what is called “on-path timing support” i= n the TICTOC WG.

The specific kind of on-path support is accumulation= of residence times in LSRs which a time-sensitive flow traverses.

As such it is essentially the same as what is called= “transparent clocking” (TC) in IEEE 1588, and the draft indeed= re-uses TC technologies.

 

However this draft attempts to remedy a problem with= TC as presently implemented – its layer violation.

This violation occurs since physical layer timing in= formation is used to modify a field of a higher layer protocol.

The present draft remedies this by forcing hop-by-ho= p behavior by TTL field manipulation,

but at the price of having to transport timing flows= in the associated channel,

previously limited to OAM and control/management pla= ne uses.

 

As such the draft elegantly solves a theoretical pro= blem.

 

I am less sure that it solves a real-world problem, = for the following reasons :

 

1. First is the fact that there is a simpler alterna= tive for on-path support of 1588 over MPLS that has already passed WG LC in= TICTOC.

The existing TICTOC draft was purposely constrained =

(following advice of reviewers who are MPLS experts)=

to not touch the MPLS forwarding plane, while this d= raft defines GACh TLVs and sub-TLVs.

The present draft is admittedly much wider in applic= ability, but no use other than 1588 on-path support is described in the dra= ft.

 

2. One conceivable use would be for highly accurate = one-way delay estimation without synchronized clocks

(and I am not sure when this use is really needed). =

Of course the present method only accounts for resid= ence time in LSRs, not for propagation latencies on links (which 1588 can h= andle as well).

The methodology to overcome this limitation would as= sumably be to rely on a co-routed round-trip, to us this draft to cancel re= sidence times,

and then to measure the remaining round-trip time an= d divide by two.

However, existing algorithms do a pretty good job at= cancelling residence times

except when the flow traverses a large number of net= work elements which are heavily loaded with plesiochronously related interf= ering flows.

Do the authors have another use case in mind ?<= /o:p>

 

3. The primary documented application for 1588 in te= lecom networks is cellular backhaul.

This application already has a plethora of solutions= , based on GPS, 1588 over Ethernet with boundary clocks (BC), distributed g= rand masters, etc. etc. etc.

Note that BC as widely deployed is already hop-by-ho= p, and in that way similar to this draft.

Is yet another solution really needed ? <= /p>

 

4. Related to the previous questions is the issue of= implementation in already existing networks.

This solution requires hardware upgrades at least fo= r the accurate time-stamping and possibly for the accumulation and field mo= dification

(although the latter may software upgrades, especial= ly if 2-step correction is utilized).

If we need to upgrade hardware, why not deploy BCs ?=

A few years back I would have said that TC could be = implemented in miniaturized devices where BC could not,

but advances in miniaturization of OCXOs have severe= ly reduced this advantage to cases where atomic-clock hold-over is required= .

 

5. If another solution for this specific application= is needed, is it needed for MPLS ?

Cellular backhaul over carrier Ethernet is widely de= ployed, is cellular backhaul over MPLS sufficiently widespread to merit thi= s extension ?

 

6. MPLS does not define its own physical layer (whic= h Ethernet does – the layer called ETY in the ITU).

As such it is not clear that MPLS is the right place= to solve the timing distribution problem.

MPLS necessarily runs over some physical layer which= may already have on-path support, or may more economically support it.

 

All of the authors work for vendors – have the= se vendors implemented this or do they plan implementing ?

If the answer is a resounding yes, then I assume tha= t we will hear rebuttals to most of the above remarks.

 

Regarding the content of the draft, I have a major i= ssue with the use of the term “Scratch Pad” for the correction = field

(and BTW, it is sometimes called “Scratch Pad&= #8221; and sometimes “ScratchPad” and sometimes “scratch = pad”).

This field is not some opaque meta-data transported = by this newly defined header,

it is the very crux of the solution and requires man= ipulation to work.

Calling it a “scratch pad” (with any of = the spellings) is tantamount to calling an MPLS label an “arbitrary b= it-field”.

Both terms may be technically correct, but hide the = meaning of the field and increase the load on reader in understanding the t= echnology.

 

As an aside, the aforementioned TICTOC WG draft orig= inally contained extensions to OSPF, RSVP-TE, etc.

It was decided to separate the control extensions fr= om the forwarding plane draft, and to pursue each in the most appropriate W= G.

It might be a good idea to do the same here.

 

One of the facts of life with on-path support of tim= ing distribution is that it is often only partial.

What happens to this solution when there is only par= tial support?

I can imagine unrecognized GACh packets being booted= to CPU in such cases, severely impacting uncompensated residence time.

 

Y(J)S

 

--_000_DB5PR03MB0999B4968F075828150C99FCE5CC0DB5PR03MB0999eurp_-- From nobody Mon May 25 23:06:32 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429B81A88B3 for ; Mon, 25 May 2015 23:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MxG1GyNROpUI for ; Mon, 25 May 2015 23:06:28 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1361D1A88B1 for ; Mon, 25 May 2015 23:06:26 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (25.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 06:06:06 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0172.012; Tue, 26 May 2015 06:06:06 +0000 From: Alexander Vainshtein To: Yaakov Stein , "mpls@ietf.org" Thread-Topic: [mpls] review of draft-mirsky-mpls-residence-time Thread-Index: AQHQl3oNpYbslVqzzkqNvhquyBxTfA== Date: Tue, 26 May 2015 06:06:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Infraware POLARIS Mobile Mailer v2.5 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [109.253.145.242] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(199003)(51694002)(479174004)(189002)(19580405001)(33656002)(50986999)(86362001)(19580395003)(2656002)(87936001)(19625215002)(101416001)(64706001)(66066001)(74316001)(105586002)(50226001)(102836002)(97736004)(4001540100001)(5001770100001)(81156007)(2900100001)(106356001)(46102003)(106116001)(40100003)(122556002)(62966003)(77156002)(189998001)(5001860100001)(76576001)(107886002)(68736005)(5001960100002)(2501003)(92566002)(5001830100001)(230783001)(16236675004)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DB3PR03MB07808A9BB6A19F122046D5CB9DCC0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 06:06:06.1017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778 Archived-At: Subject: Re: [mpls] review of draft-mirsky-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 06:06:31 -0000 --_000_DB3PR03MB07808A9BB6A19F122046D5CB9DCC0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFha292LA0KDQpMb3RzIG9mIHRoYW5rcyBmb3IgYSB2ZXJ5IGRldGFpbGVkIHJldmlldy4NCg0K SSBkZWZlciB0byBvdGhlciBjby1hdXRob3JzIHRvIGRlc2NyaWJlIHRoZSByZWxldmFudCB1c2Ug Y2FzZXMgaW4gbW9yZSBkZXRhaWwuDQoNCg0KDQpJIGp1c3Qgd2FudGVkIHRvIGNvbW1lbnQgb24g dHdvIHBvaW50czoNCg0KMS4gVGhlIGRyYWZ0IGRvZXMgbm90IHVzZSBHQUNoIFRMVnMgKHRoYXQg aGF2ZSBiZWVuIGRlcHJlY2F0ZWQgQlRXKS4NCg0KMi4gQSBsZWdhY3kgZGV2aWNlIHRoYXQgZG9l cyBub3QgaGF2ZSBSVE0gY2FwYWJpbGl0aWVzIHdpbGwgbmV2ZXIgaW5zcGVjdCB0aGUgR0FML0dB Q2ggY29uc3RydWN0IHVzZWQgaW4gdGhlIGRyYWZ0LCBiZWNhdXNlIHN1Y2ggaW5zcGVjdGlvbiBj YW4gb25seSBoYXBwZW4gZWl0aGVyIGF0IHRoZSBMU1AgdGFpbC1lbmQgbm9kZSBvciBhdCBhbiBS VE0tIGNhcGFibGUgbm9kZSB0aGF0IHRyYXBzIHRoZSBSVE0gcGFja2V0IGR1ZSB0byBUVEwgZXhw aXJhdGlvbi4NCg0KVGhpcyBsYXN0IHBvaW50IGlzIElNSE8gYSBtYWpvciBkaWZmZXJlbnRpYXRv ciBiZXR3ZWVuIHRoaXMgZHJhZnQgYW5kIG9uZSBoYW5kbGVkIGJ5IHRoZSBUSUNUT0MgV0c6DQoN Ci0gdGhpcyBkcmFmdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIE1QTFMgRFAgYXMgZGVmaW5lZCBpbiBS RkMgMzAzMSBhbmQgUkZDIDM0NDMNCg0KLSB0aGUgVElDVE9DIGRyYWZ0IChhdCBsZWFzdCB0byB0 aGUgYmVzdCBvZiBteSByZWNvbGxlY3Rpb24pIGFzc2lnbmVkIHNwZWNpYWwgaGFuZGxpbmcgdG8g bGFiZWxzIHVzZWQgYnkgdGhlIExTUHMgY2FycnlpbmcgUFRQIHBhY2tldHMgdGhhdCB3YXMgbm90 IGRlZmluZWQgYXMgYSAibGFiZWwgYWN0aW9uIiBpbiBSRkMgMzAzMSAobmVpdGhlciBQb3AsIG5v ciBTd2FwIG5vciBQdXNoKS4NCg0KDQoNClJlZ2FyZHMsDQoNClNhc2hhDQoNCg0KDQoNCg0KVGh1 bWIgdHlwZWQgb24gbXkgTEcsDQpTYXNoYQ0KDQotLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LS0NCkZyb206IFlhYWtvdiBTdGVpbg0KRGF0ZTogMjYvMDUvMjAxNSAwODoxMQ0KVG86IG1wbHNA aWV0Zi5vcmc7DQpTdWJqZWN0OlttcGxzXSByZXZpZXcgb2YgZHJhZnQtbWlyc2t5LW1wbHMtcmVz aWRlbmNlLXRpbWUNCg0KTG9hIGFza2VkIG1lIHRvIGNvbW1lbnQgb24gdGhpcyBkcmFmdCBiZWZv cmUgaXRzIGFjY2VwdGFuY2UgYXMgYSBNUExTIFdHIGRyYWZ0Lg0KDQpBcyBmYXIgYXMgSSB1bmRl cnN0YW5kLCB0aGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIHRvIHByb3ZpZGUgYSBmb3JtIG9m IHdoYXQgaXMgY2FsbGVkIOKAnG9uLXBhdGggdGltaW5nIHN1cHBvcnTigJ0gaW4gdGhlIFRJQ1RP QyBXRy4NClRoZSBzcGVjaWZpYyBraW5kIG9mIG9uLXBhdGggc3VwcG9ydCBpcyBhY2N1bXVsYXRp b24gb2YgcmVzaWRlbmNlIHRpbWVzIGluIExTUnMgd2hpY2ggYSB0aW1lLXNlbnNpdGl2ZSBmbG93 IHRyYXZlcnNlcy4NCkFzIHN1Y2ggaXQgaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgYXMgd2hhdCBp cyBjYWxsZWQg4oCcdHJhbnNwYXJlbnQgY2xvY2tpbmfigJ0gKFRDKSBpbiBJRUVFIDE1ODgsIGFu ZCB0aGUgZHJhZnQgaW5kZWVkIHJlLXVzZXMgVEMgdGVjaG5vbG9naWVzLg0KDQpIb3dldmVyIHRo aXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmVtZWR5IGEgcHJvYmxlbSB3aXRoIFRDIGFzIHByZXNlbnRs eSBpbXBsZW1lbnRlZCDigJMgaXRzIGxheWVyIHZpb2xhdGlvbi4NClRoaXMgdmlvbGF0aW9uIG9j Y3VycyBzaW5jZSBwaHlzaWNhbCBsYXllciB0aW1pbmcgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBt b2RpZnkgYSBmaWVsZCBvZiBhIGhpZ2hlciBsYXllciBwcm90b2NvbC4NClRoZSBwcmVzZW50IGRy YWZ0IHJlbWVkaWVzIHRoaXMgYnkgZm9yY2luZyBob3AtYnktaG9wIGJlaGF2aW9yIGJ5IFRUTCBm aWVsZCBtYW5pcHVsYXRpb24sDQpidXQgYXQgdGhlIHByaWNlIG9mIGhhdmluZyB0byB0cmFuc3Bv cnQgdGltaW5nIGZsb3dzIGluIHRoZSBhc3NvY2lhdGVkIGNoYW5uZWwsDQpwcmV2aW91c2x5IGxp bWl0ZWQgdG8gT0FNIGFuZCBjb250cm9sL21hbmFnZW1lbnQgcGxhbmUgdXNlcy4NCg0KQXMgc3Vj aCB0aGUgZHJhZnQgZWxlZ2FudGx5IHNvbHZlcyBhIHRoZW9yZXRpY2FsIHByb2JsZW0uDQoNCkkg YW0gbGVzcyBzdXJlIHRoYXQgaXQgc29sdmVzIGEgcmVhbC13b3JsZCBwcm9ibGVtLCBmb3IgdGhl IGZvbGxvd2luZyByZWFzb25zIDoNCg0KMS4gRmlyc3QgaXMgdGhlIGZhY3QgdGhhdCB0aGVyZSBp cyBhIHNpbXBsZXIgYWx0ZXJuYXRpdmUgZm9yIG9uLXBhdGggc3VwcG9ydCBvZiAxNTg4IG92ZXIg TVBMUyB0aGF0IGhhcyBhbHJlYWR5IHBhc3NlZCBXRyBMQyBpbiBUSUNUT0MuDQpUaGUgZXhpc3Rp bmcgVElDVE9DIGRyYWZ0IHdhcyBwdXJwb3NlbHkgY29uc3RyYWluZWQNCihmb2xsb3dpbmcgYWR2 aWNlIG9mIHJldmlld2VycyB3aG8gYXJlIE1QTFMgZXhwZXJ0cykNCnRvIG5vdCB0b3VjaCB0aGUg TVBMUyBmb3J3YXJkaW5nIHBsYW5lLCB3aGlsZSB0aGlzIGRyYWZ0IGRlZmluZXMgR0FDaCBUTFZz IGFuZCBzdWItVExWcy4NClRoZSBwcmVzZW50IGRyYWZ0IGlzIGFkbWl0dGVkbHkgbXVjaCB3aWRl ciBpbiBhcHBsaWNhYmlsaXR5LCBidXQgbm8gdXNlIG90aGVyIHRoYW4gMTU4OCBvbi1wYXRoIHN1 cHBvcnQgaXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4NCg0KMi4gT25lIGNvbmNlaXZhYmxlIHVz ZSB3b3VsZCBiZSBmb3IgaGlnaGx5IGFjY3VyYXRlIG9uZS13YXkgZGVsYXkgZXN0aW1hdGlvbiB3 aXRob3V0IHN5bmNocm9uaXplZCBjbG9ja3MNCihhbmQgSSBhbSBub3Qgc3VyZSB3aGVuIHRoaXMg dXNlIGlzIHJlYWxseSBuZWVkZWQpLg0KT2YgY291cnNlIHRoZSBwcmVzZW50IG1ldGhvZCBvbmx5 IGFjY291bnRzIGZvciByZXNpZGVuY2UgdGltZSBpbiBMU1JzLCBub3QgZm9yIHByb3BhZ2F0aW9u IGxhdGVuY2llcyBvbiBsaW5rcyAod2hpY2ggMTU4OCBjYW4gaGFuZGxlIGFzIHdlbGwpLg0KVGhl IG1ldGhvZG9sb2d5IHRvIG92ZXJjb21lIHRoaXMgbGltaXRhdGlvbiB3b3VsZCBhc3N1bWFibHkg YmUgdG8gcmVseSBvbiBhIGNvLXJvdXRlZCByb3VuZC10cmlwLCB0byB1cyB0aGlzIGRyYWZ0IHRv IGNhbmNlbCByZXNpZGVuY2UgdGltZXMsDQphbmQgdGhlbiB0byBtZWFzdXJlIHRoZSByZW1haW5p bmcgcm91bmQtdHJpcCB0aW1lIGFuZCBkaXZpZGUgYnkgdHdvLg0KSG93ZXZlciwgZXhpc3Rpbmcg YWxnb3JpdGhtcyBkbyBhIHByZXR0eSBnb29kIGpvYiBhdCBjYW5jZWxsaW5nIHJlc2lkZW5jZSB0 aW1lcw0KZXhjZXB0IHdoZW4gdGhlIGZsb3cgdHJhdmVyc2VzIGEgbGFyZ2UgbnVtYmVyIG9mIG5l dHdvcmsgZWxlbWVudHMgd2hpY2ggYXJlIGhlYXZpbHkgbG9hZGVkIHdpdGggcGxlc2lvY2hyb25v dXNseSByZWxhdGVkIGludGVyZmVyaW5nIGZsb3dzLg0KRG8gdGhlIGF1dGhvcnMgaGF2ZSBhbm90 aGVyIHVzZSBjYXNlIGluIG1pbmQgPw0KDQozLiBUaGUgcHJpbWFyeSBkb2N1bWVudGVkIGFwcGxp Y2F0aW9uIGZvciAxNTg4IGluIHRlbGVjb20gbmV0d29ya3MgaXMgY2VsbHVsYXIgYmFja2hhdWwu DQpUaGlzIGFwcGxpY2F0aW9uIGFscmVhZHkgaGFzIGEgcGxldGhvcmEgb2Ygc29sdXRpb25zLCBi YXNlZCBvbiBHUFMsIDE1ODggb3ZlciBFdGhlcm5ldCB3aXRoIGJvdW5kYXJ5IGNsb2NrcyAoQkMp LCBkaXN0cmlidXRlZCBncmFuZCBtYXN0ZXJzLCBldGMuIGV0Yy4gZXRjLg0KTm90ZSB0aGF0IEJD IGFzIHdpZGVseSBkZXBsb3llZCBpcyBhbHJlYWR5IGhvcC1ieS1ob3AsIGFuZCBpbiB0aGF0IHdh eSBzaW1pbGFyIHRvIHRoaXMgZHJhZnQuDQpJcyB5ZXQgYW5vdGhlciBzb2x1dGlvbiByZWFsbHkg bmVlZGVkID8NCg0KNC4gUmVsYXRlZCB0byB0aGUgcHJldmlvdXMgcXVlc3Rpb25zIGlzIHRoZSBp c3N1ZSBvZiBpbXBsZW1lbnRhdGlvbiBpbiBhbHJlYWR5IGV4aXN0aW5nIG5ldHdvcmtzLg0KVGhp cyBzb2x1dGlvbiByZXF1aXJlcyBoYXJkd2FyZSB1cGdyYWRlcyBhdCBsZWFzdCBmb3IgdGhlIGFj Y3VyYXRlIHRpbWUtc3RhbXBpbmcgYW5kIHBvc3NpYmx5IGZvciB0aGUgYWNjdW11bGF0aW9uIGFu ZCBmaWVsZCBtb2RpZmljYXRpb24NCihhbHRob3VnaCB0aGUgbGF0dGVyIG1heSBzb2Z0d2FyZSB1 cGdyYWRlcywgZXNwZWNpYWxseSBpZiAyLXN0ZXAgY29ycmVjdGlvbiBpcyB1dGlsaXplZCkuDQpJ ZiB3ZSBuZWVkIHRvIHVwZ3JhZGUgaGFyZHdhcmUsIHdoeSBub3QgZGVwbG95IEJDcyA/DQpBIGZl dyB5ZWFycyBiYWNrIEkgd291bGQgaGF2ZSBzYWlkIHRoYXQgVEMgY291bGQgYmUgaW1wbGVtZW50 ZWQgaW4gbWluaWF0dXJpemVkIGRldmljZXMgd2hlcmUgQkMgY291bGQgbm90LA0KYnV0IGFkdmFu Y2VzIGluIG1pbmlhdHVyaXphdGlvbiBvZiBPQ1hPcyBoYXZlIHNldmVyZWx5IHJlZHVjZWQgdGhp cyBhZHZhbnRhZ2UgdG8gY2FzZXMgd2hlcmUgYXRvbWljLWNsb2NrIGhvbGQtb3ZlciBpcyByZXF1 aXJlZC4NCg0KNS4gSWYgYW5vdGhlciBzb2x1dGlvbiBmb3IgdGhpcyBzcGVjaWZpYyBhcHBsaWNh dGlvbiBpcyBuZWVkZWQsIGlzIGl0IG5lZWRlZCBmb3IgTVBMUyA/DQpDZWxsdWxhciBiYWNraGF1 bCBvdmVyIGNhcnJpZXIgRXRoZXJuZXQgaXMgd2lkZWx5IGRlcGxveWVkLCBpcyBjZWxsdWxhciBi YWNraGF1bCBvdmVyIE1QTFMgc3VmZmljaWVudGx5IHdpZGVzcHJlYWQgdG8gbWVyaXQgdGhpcyBl eHRlbnNpb24gPw0KDQo2LiBNUExTIGRvZXMgbm90IGRlZmluZSBpdHMgb3duIHBoeXNpY2FsIGxh eWVyICh3aGljaCBFdGhlcm5ldCBkb2VzIOKAkyB0aGUgbGF5ZXIgY2FsbGVkIEVUWSBpbiB0aGUg SVRVKS4NCkFzIHN1Y2ggaXQgaXMgbm90IGNsZWFyIHRoYXQgTVBMUyBpcyB0aGUgcmlnaHQgcGxh Y2UgdG8gc29sdmUgdGhlIHRpbWluZyBkaXN0cmlidXRpb24gcHJvYmxlbS4NCk1QTFMgbmVjZXNz YXJpbHkgcnVucyBvdmVyIHNvbWUgcGh5c2ljYWwgbGF5ZXIgd2hpY2ggbWF5IGFscmVhZHkgaGF2 ZSBvbi1wYXRoIHN1cHBvcnQsIG9yIG1heSBtb3JlIGVjb25vbWljYWxseSBzdXBwb3J0IGl0Lg0K DQpBbGwgb2YgdGhlIGF1dGhvcnMgd29yayBmb3IgdmVuZG9ycyDigJMgaGF2ZSB0aGVzZSB2ZW5k b3JzIGltcGxlbWVudGVkIHRoaXMgb3IgZG8gdGhleSBwbGFuIGltcGxlbWVudGluZyA/DQpJZiB0 aGUgYW5zd2VyIGlzIGEgcmVzb3VuZGluZyB5ZXMsIHRoZW4gSSBhc3N1bWUgdGhhdCB3ZSB3aWxs IGhlYXIgcmVidXR0YWxzIHRvIG1vc3Qgb2YgdGhlIGFib3ZlIHJlbWFya3MuDQoNClJlZ2FyZGlu ZyB0aGUgY29udGVudCBvZiB0aGUgZHJhZnQsIEkgaGF2ZSBhIG1ham9yIGlzc3VlIHdpdGggdGhl IHVzZSBvZiB0aGUgdGVybSDigJxTY3JhdGNoIFBhZOKAnSBmb3IgdGhlIGNvcnJlY3Rpb24gZmll bGQNCihhbmQgQlRXLCBpdCBpcyBzb21ldGltZXMgY2FsbGVkIOKAnFNjcmF0Y2ggUGFk4oCdIGFu ZCBzb21ldGltZXMg4oCcU2NyYXRjaFBhZOKAnSBhbmQgc29tZXRpbWVzIOKAnHNjcmF0Y2ggcGFk 4oCdKS4NClRoaXMgZmllbGQgaXMgbm90IHNvbWUgb3BhcXVlIG1ldGEtZGF0YSB0cmFuc3BvcnRl ZCBieSB0aGlzIG5ld2x5IGRlZmluZWQgaGVhZGVyLA0KaXQgaXMgdGhlIHZlcnkgY3J1eCBvZiB0 aGUgc29sdXRpb24gYW5kIHJlcXVpcmVzIG1hbmlwdWxhdGlvbiB0byB3b3JrLg0KQ2FsbGluZyBp dCBhIOKAnHNjcmF0Y2ggcGFk4oCdICh3aXRoIGFueSBvZiB0aGUgc3BlbGxpbmdzKSBpcyB0YW50 YW1vdW50IHRvIGNhbGxpbmcgYW4gTVBMUyBsYWJlbCBhbiDigJxhcmJpdHJhcnkgYml0LWZpZWxk 4oCdLg0KQm90aCB0ZXJtcyBtYXkgYmUgdGVjaG5pY2FsbHkgY29ycmVjdCwgYnV0IGhpZGUgdGhl IG1lYW5pbmcgb2YgdGhlIGZpZWxkIGFuZCBpbmNyZWFzZSB0aGUgbG9hZCBvbiByZWFkZXIgaW4g dW5kZXJzdGFuZGluZyB0aGUgdGVjaG5vbG9neS4NCg0KQXMgYW4gYXNpZGUsIHRoZSBhZm9yZW1l bnRpb25lZCBUSUNUT0MgV0cgZHJhZnQgb3JpZ2luYWxseSBjb250YWluZWQgZXh0ZW5zaW9ucyB0 byBPU1BGLCBSU1ZQLVRFLCBldGMuDQpJdCB3YXMgZGVjaWRlZCB0byBzZXBhcmF0ZSB0aGUgY29u dHJvbCBleHRlbnNpb25zIGZyb20gdGhlIGZvcndhcmRpbmcgcGxhbmUgZHJhZnQsIGFuZCB0byBw dXJzdWUgZWFjaCBpbiB0aGUgbW9zdCBhcHByb3ByaWF0ZSBXRy4NCkl0IG1pZ2h0IGJlIGEgZ29v ZCBpZGVhIHRvIGRvIHRoZSBzYW1lIGhlcmUuDQoNCk9uZSBvZiB0aGUgZmFjdHMgb2YgbGlmZSB3 aXRoIG9uLXBhdGggc3VwcG9ydCBvZiB0aW1pbmcgZGlzdHJpYnV0aW9uIGlzIHRoYXQgaXQgaXMg b2Z0ZW4gb25seSBwYXJ0aWFsLg0KV2hhdCBoYXBwZW5zIHRvIHRoaXMgc29sdXRpb24gd2hlbiB0 aGVyZSBpcyBvbmx5IHBhcnRpYWwgc3VwcG9ydD8NCkkgY2FuIGltYWdpbmUgdW5yZWNvZ25pemVk IEdBQ2ggcGFja2V0cyBiZWluZyBib290ZWQgdG8gQ1BVIGluIHN1Y2ggY2FzZXMsIHNldmVyZWx5 IGltcGFjdGluZyB1bmNvbXBlbnNhdGVkIHJlc2lkZW5jZSB0aW1lLg0KDQpZKEopUw0KDQo= --_000_DB3PR03MB07808A9BB6A19F122046D5CB9DCC0DB3PR03MB0780eurp_ Content-Type: text/html; charset="utf-8" Content-ID: <35C75EC4F3D2194CAF126CBC05E294C8@ECI365.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZn0NCi0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7 Ij4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+WWFha292LDwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+TG90cyBvZiB0aGFua3Mg Zm9yIGEgdmVyeSBkZXRhaWxlZCByZXZpZXcuPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDtt YXJnaW4tYm90dG9tOjA7Ij5JIGRlZmVyIHRvIG90aGVyIGNvLWF1dGhvcnMgdG8gZGVzY3JpYmUg dGhlIHJlbGV2YW50IHVzZSBjYXNlcyBpbiBtb3JlIGRldGFpbC48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t dG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+SSBqdXN0IHdhbnRlZCB0byBjb21tZW50IG9uIHR3byBw b2ludHM6PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij4xLiBU aGUgZHJhZnQgZG9lcyBub3QgdXNlIEdBQ2ggVExWcyAodGhhdCBoYXZlIGJlZW4gZGVwcmVjYXRl ZCBCVFcpLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+Mi4g QSBsZWdhY3kgZGV2aWNlIHRoYXQgZG9lcyBub3QgaGF2ZSBSVE0gY2FwYWJpbGl0aWVzIHdpbGwg bmV2ZXIgaW5zcGVjdCB0aGUgR0FML0dBQ2ggY29uc3RydWN0IHVzZWQgaW4gdGhlIGRyYWZ0LCBi ZWNhdXNlIHN1Y2ggaW5zcGVjdGlvbiBjYW4gb25seSBoYXBwZW4gZWl0aGVyIGF0IHRoZSBMU1Ag dGFpbC1lbmQgbm9kZSBvciBhdCBhbiBSVE0tIGNhcGFibGUgbm9kZSB0aGF0DQogdHJhcHMgdGhl IFJUTSBwYWNrZXQgZHVlIHRvIFRUTCBleHBpcmF0aW9uLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t dG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+VGhpcyBsYXN0IHBvaW50IGlzIElNSE8gYSBtYWpvciBk aWZmZXJlbnRpYXRvciBiZXR3ZWVuIHRoaXMgZHJhZnQgYW5kIG9uZSBoYW5kbGVkIGJ5IHRoZSBU SUNUT0MgV0c6PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij4t IHRoaXMgZHJhZnQgZG9lcyBub3QgY2hhbmdlIHRoZSBNUExTIERQIGFzIGRlZmluZWQgaW4gUkZD IDMwMzEgYW5kIFJGQyAzNDQzPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90 dG9tOjA7Ij4tIHRoZSBUSUNUT0MgZHJhZnQgKGF0IGxlYXN0IHRvIHRoZSBiZXN0IG9mIG15IHJl Y29sbGVjdGlvbikgYXNzaWduZWQgc3BlY2lhbCBoYW5kbGluZyB0byBsYWJlbHMgdXNlZCBieSB0 aGUgTFNQcyBjYXJyeWluZyBQVFAgcGFja2V0cyB0aGF0IHdhcyBub3QgZGVmaW5lZCBhcyBhICZx dW90O2xhYmVsIGFjdGlvbiZxdW90OyBpbiBSRkMgMzAzMSAobmVpdGhlciBQb3AsIG5vciBTd2Fw IG5vciBQdXNoKS48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsi PiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+UmVn YXJkcyw8L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPlNhc2hh PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij4mbmJzcDs8L3A+ DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwvcD4NCjxk ZXYzX2pqeT5UaHVtYiB0eXBlZCBvbiBteSBMRyw8YnI+DQpTYXNoYTwvZGV2M19qank+PGJyPg0K PGJyPg0KLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tPGJyPg0KPGI+RnJvbTombmJzcDs8 L2I+WWFha292IFN0ZWluPHlhYWtvdl9zQHJhZC5jb20+PGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+ MjYvMDUvMjAxNSAwODoxMTxicj4NCjxiPlRvOiZuYnNwOzwvYj5tcGxzQGlldGYub3JnOzxicj4N CjxiPlN1YmplY3Q6PC9iPlttcGxzXSByZXZpZXcgb2YgZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRl bmNlLXRpbWU8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+TG9hIGFza2VkIG1lIHRvIGNvbW1lbnQgb24gdGhpcyBkcmFmdCBiZWZvcmUg aXRzIGFjY2VwdGFuY2UgYXMgYSBNUExTIFdHIGRyYWZ0LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGZhciBhcyBJIHVuZGVyc3Rh bmQsIHRoZSBwdXJwb3NlIG9mIHRoaXMgZHJhZnQgaXMgdG8gcHJvdmlkZSBhIGZvcm0gb2Ygd2hh dCBpcyBjYWxsZWQg4oCcb24tcGF0aCB0aW1pbmcgc3VwcG9ydOKAnSBpbiB0aGUgVElDVE9DIFdH Lg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNwZWNpZmljIGtpbmQgb2Ygb24tcGF0 aCBzdXBwb3J0IGlzIGFjY3VtdWxhdGlvbiBvZiByZXNpZGVuY2UgdGltZXMgaW4gTFNScyB3aGlj aCBhIHRpbWUtc2Vuc2l0aXZlIGZsb3cgdHJhdmVyc2VzLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFzIHN1Y2ggaXQgaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgYXMgd2hhdCBpcyBjYWxsZWQg 4oCcdHJhbnNwYXJlbnQgY2xvY2tpbmfigJ0gKFRDKSBpbiBJRUVFIDE1ODgsIGFuZCB0aGUgZHJh ZnQgaW5kZWVkIHJlLXVzZXMgVEMgdGVjaG5vbG9naWVzLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciB0aGlzIGRyYWZ0 IGF0dGVtcHRzIHRvIHJlbWVkeSBhIHByb2JsZW0gd2l0aCBUQyBhcyBwcmVzZW50bHkgaW1wbGVt ZW50ZWQg4oCTIGl0cyBsYXllciB2aW9sYXRpb24uDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIHZpb2xhdGlvbiBvY2N1cnMgc2luY2UgcGh5c2ljYWwgbGF5ZXIgdGltaW5nIGluZm9y bWF0aW9uIGlzIHVzZWQgdG8gbW9kaWZ5IGEgZmllbGQgb2YgYSBoaWdoZXIgbGF5ZXIgcHJvdG9j b2wuDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJlc2VudCBkcmFmdCByZW1lZGll cyB0aGlzIGJ5IGZvcmNpbmcgaG9wLWJ5LWhvcCBiZWhhdmlvciBieSBUVEwgZmllbGQgbWFuaXB1 bGF0aW9uLA0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YnV0IGF0IHRoZSBwcmljZSBvZiBo YXZpbmcgdG8gdHJhbnNwb3J0IHRpbWluZyBmbG93cyBpbiB0aGUgYXNzb2NpYXRlZCBjaGFubmVs LA0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHJldmlvdXNseSBsaW1pdGVkIHRvIE9BTSBh bmQgY29udHJvbC9tYW5hZ2VtZW50IHBsYW5lIHVzZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc3VjaCB0aGUgZHJhZnQgZWxl Z2FudGx5IHNvbHZlcyBhIHRoZW9yZXRpY2FsIHByb2JsZW0uIDwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbGVzcyBzdXJlIHRo YXQgaXQgc29sdmVzIGEgcmVhbC13b3JsZCBwcm9ibGVtLCBmb3IgdGhlIGZvbGxvd2luZyByZWFz b25zIDo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xLiBGaXJzdCBpcyB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgc2ltcGxlciBhbHRl cm5hdGl2ZSBmb3Igb24tcGF0aCBzdXBwb3J0IG9mIDE1ODggb3ZlciBNUExTIHRoYXQgaGFzIGFs cmVhZHkgcGFzc2VkIFdHIExDIGluIFRJQ1RPQy4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBleGlzdGluZyBUSUNUT0MgZHJhZnQgd2FzIHB1cnBvc2VseSBjb25zdHJhaW5lZCA8L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oZm9sbG93aW5nIGFkdmljZSBvZiByZXZpZXdlcnMgd2hv IGFyZSBNUExTIGV4cGVydHMpIDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIG5vdCB0b3Vj aCB0aGUgTVBMUyBmb3J3YXJkaW5nIHBsYW5lLCB3aGlsZSB0aGlzIGRyYWZ0IGRlZmluZXMgR0FD aCBUTFZzIGFuZCBzdWItVExWcy4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcmVz ZW50IGRyYWZ0IGlzIGFkbWl0dGVkbHkgbXVjaCB3aWRlciBpbiBhcHBsaWNhYmlsaXR5LCBidXQg bm8gdXNlIG90aGVyIHRoYW4gMTU4OCBvbi1wYXRoIHN1cHBvcnQgaXMgZGVzY3JpYmVkIGluIHRo ZSBkcmFmdC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4yLiBPbmUgY29uY2VpdmFibGUgdXNlIHdvdWxkIGJlIGZvciBoaWdobHkgYWNj dXJhdGUgb25lLXdheSBkZWxheSBlc3RpbWF0aW9uIHdpdGhvdXQgc3luY2hyb25pemVkIGNsb2Nr cw0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGFuZCBJIGFtIG5vdCBzdXJlIHdoZW4gdGhp cyB1c2UgaXMgcmVhbGx5IG5lZWRlZCkuIDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9mIGNv dXJzZSB0aGUgcHJlc2VudCBtZXRob2Qgb25seSBhY2NvdW50cyBmb3IgcmVzaWRlbmNlIHRpbWUg aW4gTFNScywgbm90IGZvciBwcm9wYWdhdGlvbiBsYXRlbmNpZXMgb24gbGlua3MgKHdoaWNoIDE1 ODggY2FuIGhhbmRsZSBhcyB3ZWxsKS4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBt ZXRob2RvbG9neSB0byBvdmVyY29tZSB0aGlzIGxpbWl0YXRpb24gd291bGQgYXNzdW1hYmx5IGJl IHRvIHJlbHkgb24gYSBjby1yb3V0ZWQgcm91bmQtdHJpcCwgdG8gdXMgdGhpcyBkcmFmdCB0byBj YW5jZWwgcmVzaWRlbmNlIHRpbWVzLA0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRo ZW4gdG8gbWVhc3VyZSB0aGUgcmVtYWluaW5nIHJvdW5kLXRyaXAgdGltZSBhbmQgZGl2aWRlIGJ5 IHR3by4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGV4aXN0aW5nIGFsZ29y aXRobXMgZG8gYSBwcmV0dHkgZ29vZCBqb2IgYXQgY2FuY2VsbGluZyByZXNpZGVuY2UgdGltZXMN CjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4Y2VwdCB3aGVuIHRoZSBmbG93IHRyYXZlcnNl cyBhIGxhcmdlIG51bWJlciBvZiBuZXR3b3JrIGVsZW1lbnRzIHdoaWNoIGFyZSBoZWF2aWx5IGxv YWRlZCB3aXRoIHBsZXNpb2Nocm9ub3VzbHkgcmVsYXRlZCBpbnRlcmZlcmluZyBmbG93cy48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB0aGUgYXV0aG9ycyBoYXZlIGFub3RoZXIgdXNlIGNh c2UgaW4gbWluZCA/PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+My4gVGhlIHByaW1hcnkgZG9jdW1lbnRlZCBhcHBsaWNhdGlvbiBmb3Ig MTU4OCBpbiB0ZWxlY29tIG5ldHdvcmtzIGlzIGNlbGx1bGFyIGJhY2toYXVsLg0KPC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBhcHBsaWNhdGlvbiBhbHJlYWR5IGhhcyBhIHBsZXRob3Jh IG9mIHNvbHV0aW9ucywgYmFzZWQgb24gR1BTLCAxNTg4IG92ZXIgRXRoZXJuZXQgd2l0aCBib3Vu ZGFyeSBjbG9ja3MgKEJDKSwgZGlzdHJpYnV0ZWQgZ3JhbmQgbWFzdGVycywgZXRjLiBldGMuIGV0 Yy48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlIHRoYXQgQkMgYXMgd2lkZWx5IGRlcGxv eWVkIGlzIGFscmVhZHkgaG9wLWJ5LWhvcCwgYW5kIGluIHRoYXQgd2F5IHNpbWlsYXIgdG8gdGhp cyBkcmFmdC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB5ZXQgYW5vdGhlciBzb2x1dGlv biByZWFsbHkgbmVlZGVkID8gPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4gUmVsYXRlZCB0byB0aGUgcHJldmlvdXMgcXVlc3Rpb25z IGlzIHRoZSBpc3N1ZSBvZiBpbXBsZW1lbnRhdGlvbiBpbiBhbHJlYWR5IGV4aXN0aW5nIG5ldHdv cmtzLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzb2x1dGlvbiByZXF1aXJlcyBo YXJkd2FyZSB1cGdyYWRlcyBhdCBsZWFzdCBmb3IgdGhlIGFjY3VyYXRlIHRpbWUtc3RhbXBpbmcg YW5kIHBvc3NpYmx5IGZvciB0aGUgYWNjdW11bGF0aW9uIGFuZCBmaWVsZCBtb2RpZmljYXRpb24N CjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihhbHRob3VnaCB0aGUgbGF0dGVyIG1heSBzb2Z0 d2FyZSB1cGdyYWRlcywgZXNwZWNpYWxseSBpZiAyLXN0ZXAgY29ycmVjdGlvbiBpcyB1dGlsaXpl ZCkuDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBuZWVkIHRvIHVwZ3JhZGUgaGFy ZHdhcmUsIHdoeSBub3QgZGVwbG95IEJDcyA/IDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEg ZmV3IHllYXJzIGJhY2sgSSB3b3VsZCBoYXZlIHNhaWQgdGhhdCBUQyBjb3VsZCBiZSBpbXBsZW1l bnRlZCBpbiBtaW5pYXR1cml6ZWQgZGV2aWNlcyB3aGVyZSBCQyBjb3VsZCBub3QsDQo8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgYWR2YW5jZXMgaW4gbWluaWF0dXJpemF0aW9uIG9mIE9D WE9zIGhhdmUgc2V2ZXJlbHkgcmVkdWNlZCB0aGlzIGFkdmFudGFnZSB0byBjYXNlcyB3aGVyZSBh dG9taWMtY2xvY2sgaG9sZC1vdmVyIGlzIHJlcXVpcmVkLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUuIElmIGFub3RoZXIgc29sdXRp b24gZm9yIHRoaXMgc3BlY2lmaWMgYXBwbGljYXRpb24gaXMgbmVlZGVkLCBpcyBpdCBuZWVkZWQg Zm9yIE1QTFMgPw0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2VsbHVsYXIgYmFja2hhdWwg b3ZlciBjYXJyaWVyIEV0aGVybmV0IGlzIHdpZGVseSBkZXBsb3llZCwgaXMgY2VsbHVsYXIgYmFj a2hhdWwgb3ZlciBNUExTIHN1ZmZpY2llbnRseSB3aWRlc3ByZWFkIHRvIG1lcml0IHRoaXMgZXh0 ZW5zaW9uID88L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj42LiBNUExTIGRvZXMgbm90IGRlZmluZSBpdHMgb3duIHBoeXNpY2FsIGxheWVy ICh3aGljaCBFdGhlcm5ldCBkb2VzIOKAkyB0aGUgbGF5ZXIgY2FsbGVkIEVUWSBpbiB0aGUgSVRV KS4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHN1Y2ggaXQgaXMgbm90IGNsZWFyIHRo YXQgTVBMUyBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gc29sdmUgdGhlIHRpbWluZyBkaXN0cmlidXRp b24gcHJvYmxlbS4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1QTFMgbmVjZXNzYXJpbHkg cnVucyBvdmVyIHNvbWUgcGh5c2ljYWwgbGF5ZXIgd2hpY2ggbWF5IGFscmVhZHkgaGF2ZSBvbi1w YXRoIHN1cHBvcnQsIG9yIG1heSBtb3JlIGVjb25vbWljYWxseSBzdXBwb3J0IGl0LjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCBv ZiB0aGUgYXV0aG9ycyB3b3JrIGZvciB2ZW5kb3JzIOKAkyBoYXZlIHRoZXNlIHZlbmRvcnMgaW1w bGVtZW50ZWQgdGhpcyBvciBkbyB0aGV5IHBsYW4gaW1wbGVtZW50aW5nID8NCjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHRoZSBhbnN3ZXIgaXMgYSByZXNvdW5kaW5nIHllcywgdGhlbiBJ IGFzc3VtZSB0aGF0IHdlIHdpbGwgaGVhciByZWJ1dHRhbHMgdG8gbW9zdCBvZiB0aGUgYWJvdmUg cmVtYXJrcy48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SZWdhcmRpbmcgdGhlIGNvbnRlbnQgb2YgdGhlIGRyYWZ0LCBJIGhhdmUgYSBt YWpvciBpc3N1ZSB3aXRoIHRoZSB1c2Ugb2YgdGhlIHRlcm0g4oCcU2NyYXRjaCBQYWTigJ0gZm9y IHRoZSBjb3JyZWN0aW9uIGZpZWxkDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYW5kIEJU VywgaXQgaXMgc29tZXRpbWVzIGNhbGxlZCDigJxTY3JhdGNoIFBhZOKAnSBhbmQgc29tZXRpbWVz IOKAnFNjcmF0Y2hQYWTigJ0gYW5kIHNvbWV0aW1lcyDigJxzY3JhdGNoIHBhZOKAnSkuDQo8L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGZpZWxkIGlzIG5vdCBzb21lIG9wYXF1ZSBtZXRh LWRhdGEgdHJhbnNwb3J0ZWQgYnkgdGhpcyBuZXdseSBkZWZpbmVkIGhlYWRlciwNCjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPml0IGlzIHRoZSB2ZXJ5IGNydXggb2YgdGhlIHNvbHV0aW9uIGFu ZCByZXF1aXJlcyBtYW5pcHVsYXRpb24gdG8gd29yay4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNhbGxpbmcgaXQgYSDigJxzY3JhdGNoIHBhZOKAnSAod2l0aCBhbnkgb2YgdGhlIHNwZWxs aW5ncykgaXMgdGFudGFtb3VudCB0byBjYWxsaW5nIGFuIE1QTFMgbGFiZWwgYW4g4oCcYXJiaXRy YXJ5IGJpdC1maWVsZOKAnS4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJvdGggdGVybXMg bWF5IGJlIHRlY2huaWNhbGx5IGNvcnJlY3QsIGJ1dCBoaWRlIHRoZSBtZWFuaW5nIG9mIHRoZSBm aWVsZCBhbmQgaW5jcmVhc2UgdGhlIGxvYWQgb24gcmVhZGVyIGluIHVuZGVyc3RhbmRpbmcgdGhl IHRlY2hub2xvZ3kuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgYW4gYXNpZGUsIHRoZSBhZm9yZW1lbnRpb25lZCBUSUNUT0MgV0cg ZHJhZnQgb3JpZ2luYWxseSBjb250YWluZWQgZXh0ZW5zaW9ucyB0byBPU1BGLCBSU1ZQLVRFLCBl dGMuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd2FzIGRlY2lkZWQgdG8gc2VwYXJhdGUg dGhlIGNvbnRyb2wgZXh0ZW5zaW9ucyBmcm9tIHRoZSBmb3J3YXJkaW5nIHBsYW5lIGRyYWZ0LCBh bmQgdG8gcHVyc3VlIGVhY2ggaW4gdGhlIG1vc3QgYXBwcm9wcmlhdGUgV0cuPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgbWlnaHQgYmUgYSBnb29kIGlkZWEgdG8gZG8gdGhlIHNhbWUgaGVy ZS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbmUgb2YgdGhlIGZhY3RzIG9mIGxpZmUgd2l0aCBvbi1wYXRoIHN1cHBvcnQgb2YgdGlt aW5nIGRpc3RyaWJ1dGlvbiBpcyB0aGF0IGl0IGlzIG9mdGVuIG9ubHkgcGFydGlhbC48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGhhcHBlbnMgdG8gdGhpcyBzb2x1dGlvbiB3aGVuIHRo ZXJlIGlzIG9ubHkgcGFydGlhbCBzdXBwb3J0Pw0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBjYW4gaW1hZ2luZSB1bnJlY29nbml6ZWQgR0FDaCBwYWNrZXRzIGJlaW5nIGJvb3RlZCB0byBD UFUgaW4gc3VjaCBjYXNlcywgc2V2ZXJlbHkgaW1wYWN0aW5nIHVuY29tcGVuc2F0ZWQgcmVzaWRl bmNlIHRpbWUuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WShKKVM8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8 L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB3PR03MB07808A9BB6A19F122046D5CB9DCC0DB3PR03MB0780eurp_-- From nobody Tue May 26 02:05:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5CF1A1F16; Tue, 26 May 2015 02:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4Yb-hh2U8e2j; Tue, 26 May 2015 02:05:41 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8C61A1EF2; Tue, 26 May 2015 02:05:40 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9C4A3180133E; Tue, 26 May 2015 11:05:38 +0200 (CEST) Message-ID: <5564375E.9060306@pi.nu> Date: Tue, 26 May 2015 11:05:34 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <554CAAE8.9090800@pi.nu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls-chairs@tools.ietf.org, 'secdir' , Charlie Kaufman Subject: [mpls] FYI - [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 09:05:44 -0000 Charlie, We normally send this type of reviews to the working group also, so I do that now. Working Group, When we started the MPLS-RT review of draft-farrelll-mpls-opportunistic- encrypt we also asked the sec-dir for an early review of the document. Please find the review from Charlie included. /Loa mpls wg co-chair On 2015-05-26 01:34, Charlie Kaufman wrote: > Loa-- > I hope this is an appropriate distribution list. If not please > forward as necessary. > > All-- > Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a > protocol for doing opportunistic encryption of MPLS connections. It permits > encryption at any of two scopes: between adjacent Label Switching Routers > (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an > LSP. Opportunistic encryption in this case means that there is no mechanism > specified for authenticating the endpoints of the encrypted channel. The two > endpoints do an anonymous Diffie-Hellman exchange and use the resulting key > to encrypt the connection. The protocol is not protected from a > man-in-the-middle attack (though some mechanisms for detecting such an > attack after the fact are suggested and a keying infrastructure could be > added later). > > The encryption aspects of the protocol seem well thought out and > appropriate. The question at hand is whether to adopt this document as a > working group document and it easily meets that bar (at least from a > security standpoint). I have a number of questions about operational aspects > of the protocol (perhaps due to my limited understanding of MPLS) and I have > some suggestions for enhancements that will probably be necessary eventually > and might be easier to make before there is widespread deployment: > > There is an issue that came up in the design of IKEv2 that may be an issue > here as well. I don't know whether MPLS connections are bi-directional or > whether separate connections need to be established in the two directions. > If they are bi-directional, then there are race conditions that can occur if > both ends attempt to initialize a connection simultaneously and there must > be some tie-breaking mechanism to assure that exactly one of the connection > attempts succeeds. If they are uni-directional, and if the connection is > always initialized by the sending end, then this is not a problem (though it > is replaced with the problem that messages of this protocol sent in the > reverse direction cannot be tunneled over the MPLS connection). (This > document seems to imply that MPLS connections can be either uni-directional > or bi-directional, but I don't understand MPLS well enough to have > understood it). Even if the connections are bi-directional, it will make > your life simpler if you use different symmetric keys in the two directions. > This can be done easily by getting two independent keys from the key > expansion process. > > A second issue relates to algorithm negotiation. While the protocol allows > for any of the crypto algorithms to be replaced, and the algorithms are > indicated on the wire, it does not appear to allow for a smooth upgrade > where the two ends are updated independently and everything must continue to > work when only one end has been updated. To accomplish that, there should be > an algorithm negotiation (as takes place in IKE and TLS) where one end > presents a list of algorithms is can support and the other end chooses the > algorithms it prefers. A simpler variation would be for a responder to be > able to reject the algorithms assumed by the initiator and send back a list > of algorithms it will accept. Note: it's possible that MPLS already operates > with the restriction that the two ends of a connection must be consistent > and operations will halt if the two ends are updated non-simultaneously. If > that's true, then adding crypto doesn't make the situation any worse and it > would be acceptable to continue to operate that way. > > A possible problem with Key Identifiers: the Key Identifier is only 4 bits > long, which should be sufficient because at most two keys should be active > at any given time. The Key Identifier, however, is chosen effectively > randomly, which means that one time in 16 it will be the same as the Key > Identifier it is replacing. While the protocol could be modified to do > something special in that last (like adding one to the Key Identifier if it > matches the previous value or redoing the key negotiation in that case), it > would probably be better to get the Key-ID from the key expansion when there > is no previous connection and add one (mod 16) when rekeying. > > There is mention of the possibility of reusing g^i and g^r between > connections. Some crypto purists would object to that, but I wouldn't. If > you want to allow implementations that option, however, you should also > include in the exchange nonce values Ni and Nr that are not reused between > connections rather than depending on unique values for the other parameters > to prevent reuse of keys. > > In section 3.5 (MTU considerations), I suspect you may be underestimating > the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad > bytes to make the encrypted payload size a multiple of 16 bytes. There are > algorithm variants that do not add any padding, but they are somewhat > controversial and difficult to implement in hardware. Further, the total > overhead will be dependent of the crypto algorithm chosen, and the text > should indicate that so that readers don't assume that there is some maximum > number of bytes that can be wired into protocols that run above this. > > I would suggest that most or all of sections 5 and 7 should be moved to > Security Considerations. Failing that, the Security Considerations section > should reference them. > > Typos: > > P4: "and if may be advisable" -> "and it may be advisable" > P4: "an alternative key derivation functions" -> "alternative key derivation > functions" > P5: "key definition function" -> "key derivation function" > P5: "attck vecotrs" -> "attack vectors" > P5: "descirption" -> "description" > P19: "opostie" -> "opposite" > > > > > --Charlie > > -----Original Message----- > From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, May 08, 2015 5:24 AM > To: secdir; draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt > > Security Directorate, > > Apologies if I'm sending this too wide! > > The MPLS wg has a review team. The task of the review team is to support the > wg chair, in particular when we are considering a wg adoption poll. > > Before starting a wg adoption poll we run all documents through the MPLS-RT > review (you can find a typical invite to such a review below). > > Just now we have draft-farrelll-mpls-opportunistic-encrypt in MPLS-RT > review. We have enough reviewers accepting to do the review, but all of them > have flagged that they are not entirely comfortable reviwing the document > from a security perspective. Stephen have very graciously offered to help if > there are question. > > I still would like to ask if it possible to find an expert reviewer in the > security directorate. Questions asked are the same as you find in the invite > below. > > Please contact me if you are willing to review the document for us. > > /Loa > mpls wg co-chair > > -----------example of mpls-rt review invite ----------------------- > > Dave, Mach, Lizhong and Kamran, > > > You have be selected as MPLS-RT reviewers for > draft-farrelll-mpls-opportunistic-encrypt. > > Note to authors: You have been CC'd on this email so that you can know that > this review is going on. However, please do not review your own document. > > Note to the reviewers: I understand that this document is very much on the > "security side of the house", however I will also reach out to the Sec-Dir > for a more security biased review. > This should not stop you from commenting on security aspects of the draft, > but if you feel like it I'm comfortable with a "normal MPLS-RT review", > responding to questions below. > > Reviews should comment on whether the document is coherent, is it useful > (ie, is it likely to be actually useful in operational networks), and is the > document technically sound? We are interested in knowing whether the > document is ready to be considered for WG adoption (ie, it doesn't have to > be perfect at this point, but should be a good start). > > Reviews should be sent to the document authors, WG co-chairs and WG > secretary, and CC'd to the MPLS WG email list. If necessary, comments may be > sent privately to only the WG chairs. > > If you have technical comments you should try to be explicit about what > *really* need to be resolved before adopting it as a working group document, > and what can wait until the document is a working group document and the > working group has the revision control. > > Are you able to review this draft by May 17, 2015? Please respond in a > timely fashion. > > > Thanks, Loa > (as MPLS WG chair) > > > /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue May 26 06:26:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D941B2C29 for ; Tue, 26 May 2015 06:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iHbTmHWuRMFD for ; Tue, 26 May 2015 06:25:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820881B2E35 for ; Tue, 26 May 2015 06:25:01 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (25.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (25.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 13:24:59 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([25.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([25.163.120.18]) with mapi id 15.01.0172.012; Tue, 26 May 2015 13:25:00 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQlMGW1RF3EXF02Em/R2DXr+pbkJ2ORRXg Date: Tue, 26 May 2015 13:24:58 +0000 Message-ID: References: <555C5A1D.7020709@pi.nu> <2B7669201D58CD4C8A2150DB12B129CF1690A46C60@FHDP1LUMXC7V43.us.one.verizon.com> <467340A77F13C944919805BFF3B8ACFC3006EAC36D@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: <467340A77F13C944919805BFF3B8ACFC3006EAC36D@FHDP1LUMXC7V91.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(68736005)(87936001)(102836002)(86362001)(2656002)(2501003)(2950100001)(2900100001)(4001540100001)(81156007)(76576001)(110136002)(5001960100002)(97736004)(189998001)(5001830100001)(5001860100001)(2351001)(92566002)(106116001)(122556002)(40100003)(588024002)(62966003)(77156002)(66066001)(99286002)(64706001)(106356001)(33656002)(46102003)(558084003)(230783001)(105586002)(74316001)(50986999)(54356999)(76176999)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 13:24:58.8484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 Archived-At: Cc: "draft-bonica-mpls-self-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 13:25:58 -0000 U3VwcG9ydC4NCg0KSmVmZnJleSBaaGFuZw0K From nobody Tue May 26 06:45:14 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E941B2E3F for ; Tue, 26 May 2015 06:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ftXIg_59EKMm for ; Tue, 26 May 2015 06:45:11 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.100]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CEF1B2E3D for ; Tue, 26 May 2015 06:45:10 -0700 (PDT) Received: from [216.82.253.163] by server-4.bemta-7.messagelabs.com id BB/6B-03604-5E874655; Tue, 26 May 2015 13:45:09 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-8.tower-166.messagelabs.com!1432647909!21774511!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20206 invoked from network); 26 May 2015 13:45:09 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-8.tower-166.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 May 2015 13:45:09 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 2BEE21DEB0; Tue, 26 May 2015 13:45:09 +0000 (GMT) Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by USIDCWVEHT02.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Tue, 26 May 2015 07:45:08 -0600 From: "Osborne, Eric" To: Lucy yong , "draft-mirsky-mpls-residence-time@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Thread-Index: AQHQhky7J1BgNHb+6kGzNmhgHoqlC51vhCDwgB7f3NA= Date: Tue, 26 May 2015 13:45:08 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD1A30535E@USIDCWVEMBX03.corp.global.level3.com> References: <55473BCB.70709@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.141.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 13:45:13 -0000 I finally had some time to read this draft as well. I agree with Lucy's ge= neral comments - this doc seems to achieve the goal it sets out. Is it use= ful? Not to me. It seems like it's maybe for mobile networks? I'm not an= expert in the matter of timing so this review assumes that the actual timi= ng procedures work. My comments below are about how RTM fits into the larg= er picture. General question: does RTM work over LAGs? They're a flavor of ECMP in som= e respects. If not, that needs to be spelled out somewhere. It might be worth spending a few lines in the introduction talking about wh= o might want to use this and what sort of restrictions it places on a netwo= rk design. Specific comments: Section 4 talks about LDP and ECMP and the problems it causes. It suggests= that one solution is to disable ECMP used for RTM LSPs. This seems like i= t would only make the problem worse; the more you separate the OAM path fro= m the actual data path, the less useful your measurements are. You may be = far better off just saying "don't do RTM with MP2P LSPs". Section 4.1, "LSAs sent from an interface". This doesn't line up with how = link-state protocols work. There should be no property of an LSA dependant= upon the interface that it's sent out (OK, modulo type 9 opaques and stuff= ). I think this really wants to say "LSAs sent from a router which describ= e a particular interface". =20 Section 4.5 could use a review from an ISIS expert. I scanned the GENINFO = TLV and it's not clear to me how RTM will associate a capability with a spe= cific interface between peers. What if I have several interfaces between A= -B and only some of them support RTM? I'm not saying this isn't covered, b= ut that it's not clear to me as a casual reader of Section 4.5 and GENINFO. Section 4.6, "egress LSR's egress interface". So if I have A---B---C---D---E---F a TE LSP B->E and IP nodes A and F, is section 4.6 really referring to the = E->F interface? What if I have a TE LSP A->F? Where's the 'egress LSR's egress interface'? What if I have a TE LSP A->C, C->E and E->F? Or LDP A->C, TE C->E, LDP E->= F? eric > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lucy yong > Sent: Wednesday, May 06, 2015 6:39 PM > To: draft-mirsky-mpls-residence-time@tools.ietf.org; mpls- > chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time- > 06.txt >=20 > Hi All, >=20 > I reviewed draft-mirsky-mpls-residence-time as the member of MPLS > Review Team and have the following comments: >=20 > is the document coherent? >=20 > Yes. It specifies how MPLS supports residence time measurement. >=20 > is it useful (ie, is it likely to be actually useful in operational netwo= rks)? >=20 > The document claims that such measurement can improve the accuracy of > clock synchronization across the network. I am not an operator and author > and not sure how useful this feature provides compared to the complexity > adding to. >=20 > is the document technically sound? > Yes. The draft provides a detail solution in control plane and data plane= to > achieve this purpose. >=20 > is the document ready to be considered for WG adoption? > Yes. The document states the problem clearly and provides a solution to > address this problem. >=20 > IMHO: after adopting it as the WG draft, the WG should further evaluate = if > control plane and data plane solution can be simplified. The areas may be > considered: > 1) Do we have to use IGP to announce node RTM capability? Can RSVP-TE > resolve the issue by itself? > 2) Will possible to enhance RRO to serve RSO purpose instead of carrying > both RRO and RSO in the message? > 3) Since this feature is designed for the LSP that is used for clock > synchronization, such LSPs are not majority, so it should be option in LS= P > setup. Make that very clear. > 4) two-step clock mode is quite complex. The description in Section 7 is = not > clear to me why this mode is necessary. >=20 > Regards, > Lucy >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue May 26 07:05:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0321B2EB5 for ; Tue, 26 May 2015 07:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rADeT4kHb3MQ for ; Tue, 26 May 2015 07:05:36 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87601B2EBC for ; Tue, 26 May 2015 07:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1432649136; x=1464185136; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RNSC3jUXOdm86XSf5XTwyJye0xySfRk++bexbSUKxHM=; b=fsTBQbP+vDNUhBdDvZHQQ7rnQMuAPFv7srKz1H65ihzDzpYNWTOadBG1 S5xyBLjvbCsCc46RBAReTJKaxSt/Awp+RwftEOqSOMlAvhWpiY4lfOhld 1G6HJt2fcFDEXda0OumMXOcAdr27N0GPId0JFJGgx1AmGOtHtyFVjTyqo c=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 26 May 2015 14:05:33 +0000 From: "Wygant, Mark" X-IronPort-AV: E=Sophos;i="5.13,498,1427760000"; d="scan'208";a="22261742" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 26 May 2015 14:05:33 +0000 Received: from FHDP1LUMXC7V42.us.one.verizon.com ([166.68.125.37]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Tue, 26 May 2015 10:05:33 -0400 To: Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Date: Tue, 26 May 2015 10:05:31 -0400 Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AdCS4ynzMphzv6vvRPKjbWboCZeSlgE2OsjA Message-ID: References: <555C5A1D.7020709@pi.nu> In-Reply-To: <555C5A1D.7020709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 14:05:40 -0000 Support. Mark Wygant Verizon Network Infrastructure Planning -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, May 20, 2015 4:56 AM To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; mpls-chairs@= tools.ietf.org Subject: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls= -self-ping as an MPLS wg document Working Group, This is to start a two week poll on adopting draft-bonica-mpls-self- ping-06 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There is one IPR disclosures directly against this document. All the author= s has stated on the working group mailing that they are unaware of any undi= sclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends June 5, 2015. /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue May 26 09:44:06 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C041A92BC for ; Tue, 26 May 2015 09:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-fhIeobasQv for ; Tue, 26 May 2015 09:44:03 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEE81A8A58 for ; Tue, 26 May 2015 09:44:02 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4QGhxFg022778; Tue, 26 May 2015 17:43:59 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4QGhqxL022700 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 26 May 2015 17:43:56 +0100 From: "Adrian Farrel" To: Date: Tue, 26 May 2015 17:43:50 +0100 Message-ID: <014501d097d3$2886a230$7993e690$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX0x/jsrMyNeBHQwaIxqAAuJBdzw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21572.001 X-TM-AS-Result: No--8.034-10.0-31-10 X-imss-scan-details: No--8.034-10.0-31-10 X-TMASE-MatchedRID: oxmVnmmssegUPclK4KPc4O8JHZsLQ3dUROshHNu2/QbadW4iYSMjUTrz 6vBw5SSAYKXU5x6vEGO7PTrrB/SScupla2Pf53gCHDC6a94U1AAt0t+aIVLt+5IuII6CcB9zvAC bPSJBQvVTQqkQQwuzhHLEXBbQP/X3HHJU/MR+nmH+OTCJja0mcvioIsi7Sa0gsneuamRRT5MlS2 /Vh4mBk9GQ9WjHMDp+i04MTR5lCKac95xD+Eo4wIDqq/69HfgsA7f8DkoYc/+bKItl61J/ybLn+ 0Vm71Lc3t//bkkogL4LbigRnpKlKZvjAepGmdoORnHlk9s6yGbG+8ObTk9D4QqSX3dz86emLGq7 AHLyteYjcxtjMwHleSUoHbzWqHX6XGulfAOPFxSLpI9YerHXKuxhnOjoI4Es5D9smqVBD9yilnn VDECPd/H7AvsTxZMb7DafdH0+BI7qCyYebl7X7A== Archived-At: Cc: 'Loa Andersson' Subject: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:44:05 -0000 Hi, Sasha, Loa, and I put together a short draft to clarify behavior wrt the = TTL and TC fields of the label stack entry that contains the GAL. Nothing dramatic, just tightening things up for a few issues reported to = us from implementation/interop/field. Review and comments actively sought. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 26 May 2015 17:37 > To: Loa Andersson; Alexander Vainshtein; Adrian Farrel; Adrian Farrel; = Sasha > Vainshtein; Loa Andersson > Subject: New Version Notification for = draft-vainshtein-mpls-gal-tc-ttl-handling- > 00.txt >=20 >=20 > A new version of I-D, draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-vainshtein-mpls-gal-tc-ttl-handling > Revision: 00 > Title: Handling the TC and TTL fields in a Label Stack Entry when the > Generic Associated Channel Label is Present > Document date: 2015-05-26 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-vainshtein-mpls-gal-tc-ttl- > handling-00.txt > Status: = https://datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl- > handling/ > Htmlized: = https://tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling- > 00 >=20 >=20 > Abstract: > This document clarifies handling of the Traffic Class (TC) and = Time- > to-Live (TTL) fields of a Label Stack Entry that contains the = Generic > Associated Channel (G-ACh) Label (GAL). These clarifications are > intended to aid interoperability of implementations. >=20 > Original handling was defined in RFC 5586, and this document = updates > that RFC. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Wed May 27 00:22:32 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7191A8870 for ; Wed, 27 May 2015 00:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 l-60HzJyuU81 for ; Wed, 27 May 2015 00:22:29 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28991A87DB for ; Wed, 27 May 2015 00:22:28 -0700 (PDT) Received: by wizk4 with SMTP id k4so101056965wiz.1 for ; Wed, 27 May 2015 00:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MVmcCtgMXkx8GxQv6gaWOTMUcpCFoLZnNw1YF0G5a/k=; b=xynQtB99U8C23BhUegrPJCp2KOWZLeWfPgN/fu0C/KOccql6Jb+aL9yHiiYRTCxLoV Ml07aaLWnQW2hshdRJdWCGA9XY8EZQm90jCGQh7P/CRRarHDTrnDLS7BOFQB0W74AzdE PzrQ9KOfz1vtFKANFs2iCJC6F3G6LfZUvveDNOO8MFIQxor07KcutjJkDnx+FbwfkEcy h/jBMtL3TDoLisVMEb5c0led3s7XJGzSs+oA9gxMqu6OP414C9Fd7Pj2+/udNFl7dbGI YCFx8N09br388d500INOm8IcLWV6Ib9uWt4wG7kkVCCsmcNLJtjL8GlHCWsj6KxPMeVz sAvA== X-Received: by 10.194.11.73 with SMTP id o9mr57503311wjb.116.1432711347545; Wed, 27 May 2015 00:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.65.135 with HTTP; Wed, 27 May 2015 00:22:07 -0700 (PDT) In-Reply-To: <014501d097d3$2886a230$7993e690$@olddog.co.uk> References: <014501d097d3$2886a230$7993e690$@olddog.co.uk> From: "Andrew G. Malis" Date: Wed, 27 May 2015 03:22:07 -0400 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=047d7b4507e0efaee305170b1adb Archived-At: Cc: "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 07:22:31 -0000 --047d7b4507e0efaee305170b1adb Content-Type: text/plain; charset=UTF-8 I just read it - a very useful draft indeed. Thanks, Andy On Tue, May 26, 2015 at 12:43 PM, Adrian Farrel wrote: > Hi, > > Sasha, Loa, and I put together a short draft to clarify behavior wrt the > TTL and TC fields of the label stack entry that contains the GAL. > > Nothing dramatic, just tightening things up for a few issues reported to > us from implementation/interop/field. > > Review and comments actively sought. > > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 26 May 2015 17:37 > > To: Loa Andersson; Alexander Vainshtein; Adrian Farrel; Adrian Farrel; > Sasha > > Vainshtein; Loa Andersson > > Subject: New Version Notification for > draft-vainshtein-mpls-gal-tc-ttl-handling- > > 00.txt > > > > > > A new version of I-D, draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Name: draft-vainshtein-mpls-gal-tc-ttl-handling > > Revision: 00 > > Title: Handling the TC and TTL fields in a Label Stack > Entry when the > > Generic Associated Channel Label is Present > > Document date: 2015-05-26 > > Group: Individual Submission > > Pages: 6 > > URL: > https://www.ietf.org/internet-drafts/draft-vainshtein-mpls-gal-tc-ttl- > > handling-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl- > > handling/ > > Htmlized: > https://tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling- > > 00 > > > > > > Abstract: > > This document clarifies handling of the Traffic Class (TC) and Time- > > to-Live (TTL) fields of a Label Stack Entry that contains the Generic > > Associated Channel (G-ACh) Label (GAL). These clarifications are > > intended to aid interoperability of implementations. > > > > Original handling was defined in RFC 5586, and this document updates > > that RFC. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7b4507e0efaee305170b1adb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just read it - a very useful draft indeed.

Thanks,
Andy


On Tue, May 26, 2015 at 12:43 PM, Adr= ian Farrel <adrian@olddog.co.uk> wrote:
Hi,

Sasha, Loa, and I put together a short draft to clarify behavior wrt the TT= L and TC fields of the label stack entry that contains the GAL.

Nothing dramatic, just tightening things up for a few issues reported to us= from implementation/interop/field.

Review and comments actively sought.

Adrian

> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: 26 May 2015 17:37
> To: Loa Andersson; Alexander Vainshtein; Adrian Farrel; Adrian Farrel;= Sasha
> Vainshtein; Loa Andersson
> Subject: New Version Notification for draft-vainshtein-mpls-gal-tc-ttl= -handling-
> 00.txt
>
>
> A new version of I-D, draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt=
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-vainshtein-mpls-gal-tc-tt= l-handling
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Handling= the TC and TTL fields in a Label Stack Entry when the
> Generic Associated Channel Label is Present
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2015-05-26
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-vainshtein-mpls-gal-tc-ttl-
> handling-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl-
> handling/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling-
> 00
>
>
> Abstract:
>=C2=A0 =C2=A0 This document clarifies handling of the Traffic Class (TC= ) and Time-
>=C2=A0 =C2=A0 to-Live (TTL) fields of a Label Stack Entry that contains= the Generic
>=C2=A0 =C2=A0 Associated Channel (G-ACh) Label (GAL).=C2=A0 These clari= fications are
>=C2=A0 =C2=A0 intended to aid interoperability of implementations.
>
>=C2=A0 =C2=A0 Original handling was defined in RFC 5586, and this docum= ent updates
>=C2=A0 =C2=A0 that RFC.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7b4507e0efaee305170b1adb-- From nobody Wed May 27 02:20:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA931A90EE for ; Wed, 27 May 2015 02:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xhrWbI4_OOK4 for ; Wed, 27 May 2015 02:20:38 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306901A90EB for ; Wed, 27 May 2015 02:20:38 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F3BC118016BD; Wed, 27 May 2015 11:20:35 +0200 (CEST) Message-ID: <55658C63.5020209@pi.nu> Date: Wed, 27 May 2015 11:20:35 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" , "BRUNGARD, DEBORAH A" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 09:20:39 -0000 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-lsp-ping-relay-reply. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are two IPR disclosures against this document. All the authors and contributors have stated on the working group mailing list that they are not aware of any other IPRs that relates to this draft. This working group last call ends June 10, 2015. A little bit of background. We requested publication for this draft earlier, but very late in the process it was discovered that the document needed more work - and it was returned to the working group. Document has been updated, and you can find a diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-lsp-ping-relay-reply-05&url2=draft-ietf-mpls-lsp-ping-relay-reply-09 A discussion on the updates can be found at: http://www.ietf.org/proceedings/92/slides/slides-92-mpls-8.pdf /Loa for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 27 02:30:52 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDE91A9112 for ; Wed, 27 May 2015 02:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 0VSQpN9c1p0G for ; Wed, 27 May 2015 02:30:48 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856621A90F4 for ; Wed, 27 May 2015 02:30:48 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0FEA918016BD; Wed, 27 May 2015 11:30:47 +0200 (CEST) Message-ID: <55658EC6.3070207@pi.nu> Date: Wed, 27 May 2015 11:30:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" , "BRUNGARD, DEBORAH A" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Implementation poll on draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 09:30:51 -0000 Working Group, We just started the wglc on draft-ietf-mpls-lsp-ping-relay-reply. Once the wglc is done and the document updated accordingly. We will prepare a Publication Request and among other things the Shepherd Write Up will be updated. One question we have to answer in the Shepherd Write Up is about existing implementations or intentions to implement. This is to start the Implementation Poll. If you have or are aware of existing implementations of or intentions to implement draft-ietf-mpls-lsp-ping-relay-reply please send this information to the working group mailing list or directly to the working group chairs. Note: We have requested this information earlier, but since there has been much water under the bridges there might be new implementations or intents to implement. We have chosen to run the implementation poll once more. However, if you responded to the earlier implementation poll, you don't need to respond again. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 27 06:33:16 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B2C1AD2D9 for ; Wed, 27 May 2015 06:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 WZP7XSjlzk25 for ; Wed, 27 May 2015 06:33:09 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08441AD36A for ; Wed, 27 May 2015 06:31:41 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id t4RDUWnH020487; Wed, 27 May 2015 09:31:40 -0400 Received: from vawvcgsie2k1302.ciena.com (LIN1-118-36-36.ciena.com [63.118.36.36]) by mx0a-00103a01.pphosted.com with ESMTP id 1umun22srk-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 27 May 2015 09:31:39 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 27 May 2015 09:31:38 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Wed, 27 May 2015 09:31:37 -0400 From: "Shah, Himanshu" To: "Andrew G. Malis" , Adrian Farrel Date: Wed, 27 May 2015 09:31:36 -0400 Thread-Topic: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt Thread-Index: AdCYTfKBtxd5Q8w6TLeO/vQrQSEgRQAMwo5w Message-ID: <40746B2300A8FC4AB04EE722A593182B8C5A1374@ONWVEXCHMB04.ciena.com> References: <014501d097d3$2886a230$7993e690$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-21572.007 x-tm-as-result: No--54.526800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182B8C5A1374ONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-27_05:2015-05-26,2015-05-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505270174 Archived-At: Cc: "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 13:33:12 -0000 --_000_40746B2300A8FC4AB04EE722A593182B8C5A1374ONWVEXCHMB04cie_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtZSBoZXJlLg0KL2hpbWFuc2h1DQoNCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IFdlZG5lc2RheSwg TWF5IDI3LCAyMDE1IDM6MjIgQU0NClRvOiBBZHJpYW4gRmFycmVsDQpDYzogbXBsc0BpZXRmLm9y ZzsgTG9hIEFuZGVyc3Nvbg0KU3ViamVjdDogUmU6IFttcGxzXSBOZXcgSS1EIGRyYWZ0LXZhaW5z aHRlaW4tbXBscy1nYWwtdGMtdHRsLWhhbmRsaW5nLTAwLnR4dA0KDQpJIGp1c3QgcmVhZCBpdCAt IGEgdmVyeSB1c2VmdWwgZHJhZnQgaW5kZWVkLg0KDQpUaGFua3MsDQpBbmR5DQoNCg0KT24gVHVl LCBNYXkgMjYsIDIwMTUgYXQgMTI6NDMgUE0sIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cu Y28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+PiB3cm90ZToNCkhpLA0KDQpTYXNoYSwg TG9hLCBhbmQgSSBwdXQgdG9nZXRoZXIgYSBzaG9ydCBkcmFmdCB0byBjbGFyaWZ5IGJlaGF2aW9y IHdydCB0aGUgVFRMIGFuZCBUQyBmaWVsZHMgb2YgdGhlIGxhYmVsIHN0YWNrIGVudHJ5IHRoYXQg Y29udGFpbnMgdGhlIEdBTC4NCg0KTm90aGluZyBkcmFtYXRpYywganVzdCB0aWdodGVuaW5nIHRo aW5ncyB1cCBmb3IgYSBmZXcgaXNzdWVzIHJlcG9ydGVkIHRvIHVzIGZyb20gaW1wbGVtZW50YXRp b24vaW50ZXJvcC9maWVsZC4NCg0KUmV2aWV3IGFuZCBjb21tZW50cyBhY3RpdmVseSBzb3VnaHQu DQoNCkFkcmlhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPl0NCj4gU2VudDogMjYgTWF5IDIwMTUgMTc6MzcNCj4gVG86IExvYSBBbmRlcnNzb247IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBBZHJpYW4gRmFycmVsOyBBZHJpYW4gRmFycmVsOyBTYXNoYQ0K PiBWYWluc2h0ZWluOyBMb2EgQW5kZXJzc29uDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtdmFpbnNodGVpbi1tcGxzLWdhbC10Yy10dGwtaGFuZGxpbmctDQo+ IDAwLnR4dA0KPg0KPg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdmFpbnNodGVpbi1t cGxzLWdhbC10Yy10dGwtaGFuZGxpbmctMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgQWRyaWFuIEZhcnJlbCBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9z aXRvcnkuDQo+DQo+IE5hbWU6ICAgICAgICAgZHJhZnQtdmFpbnNodGVpbi1tcGxzLWdhbC10Yy10 dGwtaGFuZGxpbmcNCj4gUmV2aXNpb246ICAgICAwMA0KPiBUaXRsZTogICAgICAgICAgICAgICAg SGFuZGxpbmcgdGhlIFRDIGFuZCBUVEwgZmllbGRzIGluIGEgTGFiZWwgU3RhY2sgRW50cnkgd2hl biB0aGUNCj4gR2VuZXJpYyBBc3NvY2lhdGVkIENoYW5uZWwgTGFiZWwgaXMgUHJlc2VudA0KPiBE b2N1bWVudCBkYXRlOiAgICAgICAgMjAxNS0wNS0yNg0KPiBHcm91cDogICAgICAgICAgICAgICAg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAgICAgICAgICAgICA2DQo+IFVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdmFp bnNodGVpbi1tcGxzLWdhbC10Yy10dGwtDQo+IGhhbmRsaW5nLTAwLnR4dA0KPiBTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmFpbnNodGVpbi1t cGxzLWdhbC10Yy10dGwtDQo+IGhhbmRsaW5nLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZhaW5zaHRlaW4tbXBscy1nYWwtdGMtdHRsLWhhbmRs aW5nLQ0KPiAwMA0KPg0KPg0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBjbGFyaWZp ZXMgaGFuZGxpbmcgb2YgdGhlIFRyYWZmaWMgQ2xhc3MgKFRDKSBhbmQgVGltZS0NCj4gICAgdG8t TGl2ZSAoVFRMKSBmaWVsZHMgb2YgYSBMYWJlbCBTdGFjayBFbnRyeSB0aGF0IGNvbnRhaW5zIHRo ZSBHZW5lcmljDQo+ICAgIEFzc29jaWF0ZWQgQ2hhbm5lbCAoRy1BQ2gpIExhYmVsIChHQUwpLiAg VGhlc2UgY2xhcmlmaWNhdGlvbnMgYXJlDQo+ICAgIGludGVuZGVkIHRvIGFpZCBpbnRlcm9wZXJh YmlsaXR5IG9mIGltcGxlbWVudGF0aW9ucy4NCj4NCj4gICAgT3JpZ2luYWwgaGFuZGxpbmcgd2Fz IGRlZmluZWQgaW4gUkZDIDU1ODYsIGFuZCB0aGlzIGRvY3VtZW50IHVwZGF0ZXMNCj4gICAgdGhh dCBSRkMuDQo+DQo+DQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxo dHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5n IGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K --_000_40746B2300A8FC4AB04EE722A593182B8C5A1374ONWVEXCHMB04cie_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiMwMDQwQzA7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYg Y2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtjb2xvcjojMDA0MEMw Jz5TYW1lIGhlcmUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwi c2VyaWYiO2NvbG9yOiMwMDQwQzAnPi9oaW1hbnNodTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDQwQzAnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJl aGFsZiBPZiA8L2I+QW5kcmV3IEcuIE1hbGlzPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1h eSAyNywgMjAxNSAzOjIyIEFNPGJyPjxiPlRvOjwvYj4gQWRyaWFuIEZhcnJlbDxicj48Yj5DYzo8 L2I+IG1wbHNAaWV0Zi5vcmc7IExvYSBBbmRlcnNzb248YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBb bXBsc10gTmV3IEktRCBkcmFmdC12YWluc2h0ZWluLW1wbHMtZ2FsLXRjLXR0bC1oYW5kbGluZy0w MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkganVzdCByZWFkIGl0IC0gYSB2ZXJ5 IHVzZWZ1bCBkcmFmdCBpbmRlZWQuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhh bmtzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFuZHk8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBUdWUsIE1heSAyNiwgMjAxNSBhdCAxMjo0 MyBQTSwgQWRyaWFuIEZhcnJlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28u dWsiIHRhcmdldD0iX2JsYW5rIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkhpLDxicj48YnI+U2FzaGEsIExvYSwgYW5k IEkgcHV0IHRvZ2V0aGVyIGEgc2hvcnQgZHJhZnQgdG8gY2xhcmlmeSBiZWhhdmlvciB3cnQgdGhl IFRUTCBhbmQgVEMgZmllbGRzIG9mIHRoZSBsYWJlbCBzdGFjayBlbnRyeSB0aGF0IGNvbnRhaW5z IHRoZSBHQUwuPGJyPjxicj5Ob3RoaW5nIGRyYW1hdGljLCBqdXN0IHRpZ2h0ZW5pbmcgdGhpbmdz IHVwIGZvciBhIGZldyBpc3N1ZXMgcmVwb3J0ZWQgdG8gdXMgZnJvbSBpbXBsZW1lbnRhdGlvbi9p bnRlcm9wL2ZpZWxkLjxicj48YnI+UmV2aWV3IGFuZCBjb21tZW50cyBhY3RpdmVseSBzb3VnaHQu PGJyPjxicj5BZHJpYW48YnI+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl08YnI+Jmd0OyBT ZW50OiAyNiBNYXkgMjAxNSAxNzozNzxicj4mZ3Q7IFRvOiBMb2EgQW5kZXJzc29uOyBBbGV4YW5k ZXIgVmFpbnNodGVpbjsgQWRyaWFuIEZhcnJlbDsgQWRyaWFuIEZhcnJlbDsgU2FzaGE8YnI+Jmd0 OyBWYWluc2h0ZWluOyBMb2EgQW5kZXJzc29uPGJyPiZndDsgU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC12YWluc2h0ZWluLW1wbHMtZ2FsLXRjLXR0bC1oYW5kbGlu Zy08YnI+Jmd0OyAwMC50eHQ8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXZhaW5zaHRlaW4tbXBscy1nYWwtdGMtdHRsLWhhbmRsaW5nLTAwLnR4dDxi cj4mZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRyaWFuIEZhcnJlbCBh bmQgcG9zdGVkIHRvIHRoZTxicj4mZ3Q7IElFVEYgcmVwb3NpdG9yeS48YnI+Jmd0Ozxicj4mZ3Q7 IE5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXZhaW5zaHRlaW4t bXBscy1nYWwtdGMtdHRsLWhhbmRsaW5nPGJyPiZndDsgUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAm bmJzcDswMDxicj4mZ3Q7IFRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSGFuZGxpbmcgdGhlIFRDIGFuZCBUVEwgZmllbGRzIGluIGEg TGFiZWwgU3RhY2sgRW50cnkgd2hlbiB0aGU8YnI+Jmd0OyBHZW5lcmljIEFzc29jaWF0ZWQgQ2hh bm5lbCBMYWJlbCBpcyBQcmVzZW50PGJyPiZndDsgRG9jdW1lbnQgZGF0ZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgMjAxNS0wNS0yNjxicj4mZ3Q7IEdyb3VwOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNz aW9uPGJyPiZndDsgUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA2PGJyPiZndDsgVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC12YWluc2h0ZWluLW1wbHMtZ2FsLXRjLXR0bC0iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdmFpbnNodGVpbi1tcGxz LWdhbC10Yy10dGwtPC9hPjxicj4mZ3Q7IGhhbmRsaW5nLTAwLnR4dDxicj4mZ3Q7IFN0YXR1czom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmFpbnNodGVpbi1tcGxzLWdhbC10Yy10dGwtIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmFpbnNo dGVpbi1tcGxzLWdhbC10Yy10dGwtPC9hPjxicj4mZ3Q7IGhhbmRsaW5nLzxicj4mZ3Q7IEh0bWxp emVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC12YWluc2h0ZWluLW1wbHMtZ2FsLXRjLXR0bC1oYW5kbGluZy0iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmFpbnNodGVp bi1tcGxzLWdhbC10Yy10dGwtaGFuZGxpbmctPC9hPjxicj4mZ3Q7IDAwPGJyPiZndDs8YnI+Jmd0 Ozxicj4mZ3Q7IEFic3RyYWN0Ojxicj4mZ3Q7Jm5ic3A7ICZuYnNwOyBUaGlzIGRvY3VtZW50IGNs YXJpZmllcyBoYW5kbGluZyBvZiB0aGUgVHJhZmZpYyBDbGFzcyAoVEMpIGFuZCBUaW1lLTxicj4m Z3Q7Jm5ic3A7ICZuYnNwOyB0by1MaXZlIChUVEwpIGZpZWxkcyBvZiBhIExhYmVsIFN0YWNrIEVu dHJ5IHRoYXQgY29udGFpbnMgdGhlIEdlbmVyaWM8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgQXNzb2Np YXRlZCBDaGFubmVsIChHLUFDaCkgTGFiZWwgKEdBTCkuJm5ic3A7IFRoZXNlIGNsYXJpZmljYXRp b25zIGFyZTxicj4mZ3Q7Jm5ic3A7ICZuYnNwOyBpbnRlbmRlZCB0byBhaWQgaW50ZXJvcGVyYWJp bGl0eSBvZiBpbXBsZW1lbnRhdGlvbnMuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgT3Jp Z2luYWwgaGFuZGxpbmcgd2FzIGRlZmluZWQgaW4gUkZDIDU1ODYsIGFuZCB0aGlzIGRvY3VtZW50 IHVwZGF0ZXM8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgdGhhdCBSRkMuPGJyPiZndDs8YnI+Jmd0Ozxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPiZndDsgdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4u PGJyPiZndDs8YnI+Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxicj48YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bXBscyBtYWlsaW5nIGxpc3Q8 YnI+PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvYT48 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_40746B2300A8FC4AB04EE722A593182B8C5A1374ONWVEXCHMB04cie_-- From nobody Wed May 27 07:37:35 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4CE1B2B79 for ; Wed, 27 May 2015 07:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 YF8wcuBiPLLp for ; Wed, 27 May 2015 07:37:32 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 107261B2B25 for ; Wed, 27 May 2015 07:37:32 -0700 (PDT) Received: by wizk4 with SMTP id k4so114092160wiz.1 for ; Wed, 27 May 2015 07:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=gvUBwoOCXE4vjdNTiBwQz8bZGam3q0S4XCcRjBDDvXg=; b=uK+qPEnU1Hn7QhHQezrDuC/9oMk/v7cpcjsMHqpUiHuvtRvxnbAJpjkt1WthGTMDKx oIGipf1AbfWB7egaZd8CRnDpTPHNpNiTIcg14Ti3ffaq5d0W4hJGKTtBEtVAV09dXqEA 5b5Btxt98NmxRT5QxdqeDjod2ld3pUjIQFPLa5C4S0ruH6UZ9lH7dUINIO36bfFAa4n+ cuTI3PSWP+JMaxNJfDKF3tFAAej5plnnuWcNUXsuStK86zHWWZYMu7D7k7TpVfQqL7TF q2uz6w1nnSwVrEK7CgTbCxvSzxVmPo8adi3Gk5mqWSwplAj7m7Q2VEaEfOHiB18ea5Q1 bqsA== X-Received: by 10.194.109.229 with SMTP id hv5mr61056671wjb.119.1432737450787; Wed, 27 May 2015 07:37:30 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id x3sm3972445wiy.20.2015.05.27.07.37.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 07:37:29 -0700 (PDT) Message-ID: <5565D6A8.4000209@gmail.com> Date: Wed, 27 May 2015 16:37:28 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Andrew G. Malis" , Adrian Farrel References: <014501d097d3$2886a230$7993e690$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 14:37:34 -0000 +1 nit in section 3.2: c /comply with the this document/comply with this document/ Regards, Huub. On 27-05-15 09:22, Andrew G. Malis wrote: > I just read it - a very useful draft indeed. > > Thanks, > Andy > > > On Tue, May 26, 2015 at 12:43 PM, Adrian Farrel > wrote: > > Hi, > > Sasha, Loa, and I put together a short draft to clarify behavior wrt > the TTL and TC fields of the label stack entry that contains the GAL. > > Nothing dramatic, just tightening things up for a few issues > reported to us from implementation/interop/field. > > Review and comments actively sought. > > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org ] > > Sent: 26 May 2015 17:37 > > To: Loa Andersson; Alexander Vainshtein; Adrian Farrel; Adrian > Farrel; Sasha > > Vainshtein; Loa Andersson > > Subject: New Version Notification for > draft-vainshtein-mpls-gal-tc-ttl-handling- > > 00.txt > > > > > > A new version of I-D, > draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Name: draft-vainshtein-mpls-gal-tc-ttl-handling > > Revision: 00 > > Title: Handling the TC and TTL fields in a Label > Stack Entry when the > > Generic Associated Channel Label is Present > > Document date: 2015-05-26 > > Group: Individual Submission > > Pages: 6 > > URL: > https://www.ietf.org/internet-drafts/draft-vainshtein-mpls-gal-tc-ttl- > > handling-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl- > > handling/ > > Htmlized: > https://tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling- > > 00 > > > > > > Abstract: > > This document clarifies handling of the Traffic Class (TC) and > Time- > > to-Live (TTL) fields of a Label Stack Entry that contains the > Generic > > Associated Channel (G-ACh) Label (GAL). These clarifications are > > intended to aid interoperability of implementations. > > > > Original handling was defined in RFC 5586, and this document > updates > > that RFC. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at > tools.ietf.org . > > > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobody Wed May 27 08:08:53 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53121B2CE8 for ; Wed, 27 May 2015 08:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 jHiSoKXr85G9 for ; Wed, 27 May 2015 08:08:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B821B2CDB for ; Wed, 27 May 2015 08:07:54 -0700 (PDT) Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB189.namprd05.prod.outlook.com (10.242.39.140) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 15:07:33 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.238]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.238]) with mapi id 15.01.0166.017; Wed, 27 May 2015 15:07:33 +0000 From: Santosh Esale To: "EXT - mark.wygant@verizon.com" , Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuMnA4VZxVy5SUKJ5C+NT/cAHJ2OVEeAgAEuWQA= Date: Wed, 27 May 2015 15:07:33 +0000 Message-ID: References: <555C5A1D.7020709@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sesale@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BY2PR05MB189; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB189; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(252514010)(13464003)(51704005)(377454003)(5001860100001)(68736005)(5001830100001)(83506001)(105586002)(102836002)(99286002)(15975445007)(5002640100001)(101416001)(64706001)(66066001)(2201001)(40100003)(230783001)(2900100001)(2501003)(19580395003)(62966003)(77156002)(19580405001)(5001960100002)(2950100001)(107886002)(189998001)(122556002)(86362001)(106356001)(5001770100001)(36756003)(81156007)(4001540100001)(4001350100001)(97736004)(87936001)(2656002)(46102003)(106116001)(50986999)(92566002)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB189; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <806A90B5515423489E8A66D1A00CD01A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 15:07:33.5092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB189 Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:08:53 -0000 U3VwcG9ydC4NCg0KU2FudG9zaCBFc2FsZQ0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExv YSBBbmRlcnNzb24NCj5TZW50OiBXZWRuZXNkYXksIE1heSAyMCwgMjAxNSA0OjU2IEFNDQo+VG86 IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWJvbmljYS1tcGxzLXNlbGYtcGluZ0B0b29scy5pZXRmLm9y ZzsNCj5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IFttcGxzXSBQb2xsIHRv IHNlZSBpZiB3ZSBoYXZlIGNvbnNlbnN1cyBhZG9wdGluZw0KPmRyYWZ0LWJvbmljYS1tcGxzLXNl bGYtcGluZyBhcyBhbiBNUExTIHdnIGRvY3VtZW50DQo+DQo+V29ya2luZyBHcm91cCwNCj4NCj5U aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1ib25pY2Et bXBscy1zZWxmLQ0KPnBpbmctMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K Pg0KPlBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRo ZSBtcGxzIHdvcmtpbmcgZ3JvdXANCj5tYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLiBQbGVh c2UgZ2l2ZSBhIHRlY2huaWNhbCBtb3RpdmF0aW9uIGZvciB5b3VyDQo+c3VwcG9ydC9ub3Qgc3Vw cG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIG5v dA0KPmJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPg0KPlRoZXJlIGlz IG9uZSBJUFIgZGlzY2xvc3VyZXMgZGlyZWN0bHkgYWdhaW5zdCB0aGlzIGRvY3VtZW50LiBBbGwg dGhlDQo+YXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgdGhh dCB0aGV5IGFyZSB1bmF3YXJlIG9mDQo+YW55IHVuZGlzY2xvc2VkIElQUnMgYWdhaW5zdCB0aGlz IGRvY3VtZW50Lg0KPg0KPkhvd2V2ZXIgaWYgeW91IGFyZSBvbiB0aGUgdGhlIG1wbHMgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3QgYW5kIGF3YXJlDQo+b2YgSVBSIHRoYXQgcmVsYXRlcyB0byB0 aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZSB0aGlzIGlzIG5vdy4NCj4NCj5UaGlzIHBv bGwgZW5kcyBKdW5lIDUsIDIwMTUuDQo+DQo+L0xvYQ0KPi0tIA0KPg0KPg0KPkxvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ U2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj5I dWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEg NjQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pm1wbHMgbWFpbGluZyBsaXN0DQo+bXBsc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QNCj5tcGxzQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== From nobody Wed May 27 09:38:52 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B823E1A7113 for ; Wed, 27 May 2015 09:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8SE79NChYG93 for ; Wed, 27 May 2015 09:38:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B14E1A8032 for ; Wed, 27 May 2015 09:38:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA41586; Wed, 27 May 2015 16:38:43 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 May 2015 17:38:42 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 27 May 2015 09:38:33 -0700 From: Lucy yong To: Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuM2DO1cjrJvKUWimpSC3bXxOp2QDXQA Date: Wed, 27 May 2015 16:38:33 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571818AD@dfweml701-chm> References: <555C5A1D.7020709@pi.nu> In-Reply-To: <555C5A1D.7020709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:38:50 -0000 This is a useful draft and should be adopted by the WG. In future version, the draft should clarify that this mechanism applies to = p2p LSP only or other as well such as P2MP LSP. Cheers, Lucy -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, May 20, 2015 4:56 AM To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; mpls-chairs@= tools.ietf.org Subject: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls= -self-ping as an MPLS wg document Working Group, This is to start a two week poll on adopting draft-bonica-mpls-self- ping-06 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There is one IPR disclosures directly against this document. All the author= s has stated on the working group mailing that they are unaware of any undi= sclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends June 5, 2015. /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed May 27 09:57:31 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333C91A8710 for ; Wed, 27 May 2015 09:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 lRehPbQhhmKO for ; Wed, 27 May 2015 09:57:28 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58C61A8734 for ; Wed, 27 May 2015 09:57:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4RGvMs8009307; Wed, 27 May 2015 17:57:22 +0100 Received: from 950129200 (jplon-nat10.juniper.net [193.110.55.10]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4RGvDnB009234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 27 May 2015 17:57:19 +0100 From: "Adrian Farrel" To: Date: Wed, 27 May 2015 17:57:11 +0100 Message-ID: <000101d0989e$31d0da10$95728e30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCYniTlWOlLQcKRSyiebDzEXQiJag== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21574.001 X-TM-AS-Result: No--16.947-10.0-31-10 X-imss-scan-details: No--16.947-10.0-31-10 X-TMASE-MatchedRID: vbSD0OnL8/KnykMun0J1wvHkpkyUphL9t7k6BDMlB1iY+9xM7I+ioFiq Ayk7LkbkmZM6T9wsGgdVy6ITvoVi9ELMcWGLKmhWmlaAItiONP1tofdVs4T9OUiO8DX9hL7R5zl dYRH+EtGQGGkDTVjB4AbqZM3zDkF06mVrY9/neAIcMLpr3hTUAC3S35ohUu37ki4gjoJwH3O8AJ s9IkFC9cVngB/DDw+ktq6XO4P1r2VI+3ozt9gQMp1U1lojafr/QZXZg2I8JaajC1E/zCEIr4uVF YXQQnMyJRrVLqjmxpc5NrMZPf265DB7AhAesYcjLTHwnYOikQ1r9+Kgn2XgeMzvOkSymob/M7D2 bzcRulWWodNQV3v4AMUJsHcBbrX8DGuPXy2mDH8dMzSvzokWv0hW0PnTJ1CB7/4vrKFm8ph2XEz Sk0UxQOfOVcxjDhcwAYt5KiTiutkLbigRnpKlKVHxEBQar9Jn2jJ30Sm6wS6Br2NDMq80V1V4JH eNt4EuXbQ/IrBNDgd9vOhPJmNsiqUJtEVIISYJPMXlLQ3ATP/OfuWIxGZGWxraHtZnj+sx5D9sm qVBD9yilnnVDECPd/H7AvsTxZMb7DafdH0+BI5Jpz74j78uzcC+ksT6a9fy Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:57:30 -0000 Thanks Huub, In the working XML A > -----Original Message----- > From: Huub van Helvoort [mailto:huubatwork@gmail.com] > Sent: 27 May 2015 15:37 > To: Andrew G. Malis; Adrian Farrel > Cc: mpls@ietf.org; Loa Andersson > Subject: Re: [mpls] New I-D = draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt >=20 > +1 >=20 > nit in section 3.2: > c /comply with the this document/comply with this document/ >=20 > Regards, Huub. >=20 > On 27-05-15 09:22, Andrew G. Malis wrote: > > I just read it - a very useful draft indeed. > > > > Thanks, > > Andy > > > > > > On Tue, May 26, 2015 at 12:43 PM, Adrian Farrel > > wrote: > > > > Hi, > > > > Sasha, Loa, and I put together a short draft to clarify behavior = wrt > > the TTL and TC fields of the label stack entry that contains the = GAL. > > > > Nothing dramatic, just tightening things up for a few issues > > reported to us from implementation/interop/field. > > > > Review and comments actively sought. > > > > Adrian > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org = > > [mailto:internet-drafts@ietf.org = ] > > > Sent: 26 May 2015 17:37 > > > To: Loa Andersson; Alexander Vainshtein; Adrian Farrel; = Adrian > > Farrel; Sasha > > > Vainshtein; Loa Andersson > > > Subject: New Version Notification for > > draft-vainshtein-mpls-gal-tc-ttl-handling- > > > 00.txt > > > > > > > > > A new version of I-D, > > draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt > > > has been successfully submitted by Adrian Farrel and posted = to the > > > IETF repository. > > > > > > Name: draft-vainshtein-mpls-gal-tc-ttl-handling > > > Revision: 00 > > > Title: Handling the TC and TTL fields in a = Label > > Stack Entry when the > > > Generic Associated Channel Label is Present > > > Document date: 2015-05-26 > > > Group: Individual Submission > > > Pages: 6 > > > URL: > > = https://www.ietf.org/internet-drafts/draft-vainshtein-mpls-gal-tc-ttl- > > > handling-00.txt > > > Status: > > = https://datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl- > > > handling/ > > > Htmlized: > > = https://tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling- > > > 00 > > > > > > > > > Abstract: > > > This document clarifies handling of the Traffic Class (TC) = and > > Time- > > > to-Live (TTL) fields of a Label Stack Entry that contains = the > > Generic > > > Associated Channel (G-ACh) Label (GAL). These = clarifications are > > > intended to aid interoperability of implementations. > > > > > > Original handling was defined in RFC 5586, and this = document > > updates > > > that RFC. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the = time of > > submission > > > until the htmlized version and diff are available at > > tools.ietf.org . > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 > -- > ************************************************************** > *** > = =E8=AF=B7=E8=AE=B0=E4=BD=8F=EF=BC=8C=E4=BD=A0=E6=98=AF=E7=8B=AC=E4=B8=80=E6= =97=A0=E4=BA=8C=E7=9A=84=EF=BC=8C=E5=B0=B1=E5=83=8F=E5=85=B6=E4=BB=96=E6=AF= =8F=E4=B8=80=E4=B8=AA=E4=BA=BA=E4=B8=80=E6=A0=B7 From nobody Wed May 27 11:02:48 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A531A8965 for ; Wed, 27 May 2015 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xgmPZFYaOrHr for ; Wed, 27 May 2015 11:02:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCDB1A8960 for ; Wed, 27 May 2015 11:02:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA46943; Wed, 27 May 2015 18:02:42 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 May 2015 19:02:41 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 27 May 2015 11:02:33 -0700 From: Linda Dunbar To: Lucy yong , Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuM1lLeM7DeqHEOZL7dx/dtjI52QhraA//+iBTA= Date: Wed, 27 May 2015 18:02:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4C628@dfweml701-chm> References: <555C5A1D.7020709@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D571818AD@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571818AD@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 18:02:46 -0000 +1.=20 Support.=20 Linda -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, May 27, 2015 11:39 AM To: Loa Andersson; mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.or= g; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-= mpls-self-ping as an MPLS wg document This is a useful draft and should be adopted by the WG. In future version, the draft should clarify that this mechanism applies to = p2p LSP only or other as well such as P2MP LSP. Cheers, Lucy -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, May 20, 2015 4:56 AM To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; mpls-chairs@= tools.ietf.org Subject: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls= -self-ping as an MPLS wg document Working Group, This is to start a two week poll on adopting draft-bonica-mpls-self- ping-06 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There is one IPR disclosures directly against this document. All the author= s has stated on the working group mailing that they are unaware of any undi= sclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends June 5, 2015. /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed May 27 16:54:15 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25C21A8A90 for ; Wed, 27 May 2015 16:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 VefzIvwPxRdz for ; Wed, 27 May 2015 16:54:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D64A1A8A7B for ; Wed, 27 May 2015 16:54:13 -0700 (PDT) Received: from CY1PR05MB1897.namprd05.prod.outlook.com (25.162.167.151) by CY1PR05MB1932.namprd05.prod.outlook.com (25.162.216.14) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 23:54:11 +0000 Received: from CY1PR05MB1900.namprd05.prod.outlook.com (25.162.167.154) by CY1PR05MB1897.namprd05.prod.outlook.com (25.162.167.151) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 23:54:10 +0000 Received: from CY1PR05MB1900.namprd05.prod.outlook.com ([25.162.167.154]) by CY1PR05MB1900.namprd05.prod.outlook.com ([25.162.167.154]) with mapi id 15.01.0172.012; Wed, 27 May 2015 23:54:10 +0000 From: Minjie Dai To: Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuMmT9vcqH9wy0CDtwjQB+yfjZ2QFbgA Date: Wed, 27 May 2015 23:54:09 +0000 Message-ID: References: <555C5A1D.7020709@pi.nu> In-Reply-To: <555C5A1D.7020709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mdai@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB1897; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB1932; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CY1PR05MB1897; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB1897; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(479174004)(24454002)(51704005)(377454003)(199003)(252514010)(83506001)(46102003)(101416001)(66066001)(54356999)(105586002)(50986999)(76176999)(68736005)(19580405001)(64706001)(5002640100001)(19580395003)(99286002)(87936001)(2656002)(62966003)(40100003)(4001350100001)(92566002)(36756003)(5001830100001)(5001860100001)(189998001)(122556002)(2201001)(106356001)(5001960100002)(15975445007)(2501003)(4001540100001)(106116001)(2950100001)(5001770100001)(2900100001)(86362001)(107886002)(81156007)(102836002)(230783001)(97736004)(77156002)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1897; H:CY1PR05MB1900.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 23:54:09.6375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1897 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 23:54:15 -0000 Support. Minjie Dai On 5/20/15, 2:55 AM, "Loa Andersson" wrote: >Working Group, > >This is to start a two week poll on adopting draft-bonica-mpls-self- >ping-06 as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There is one IPR disclosures directly against this document. All the >authors has stated on the working group mailing that they are unaware of >any undisclosed IPRs against this document. > >However if you are on the the mpls working group mailing list and >aware of IPR that relates to this draft, the time to disclose >this is now. > >This poll ends June 5, 2015. > >/Loa >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Wed May 27 17:53:06 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC041A8738 for ; Wed, 27 May 2015 17:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 M8BOUFGOJJN2 for ; Wed, 27 May 2015 17:53:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F81E1A90FC for ; Wed, 27 May 2015 17:53:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA65365; Thu, 28 May 2015 00:53:00 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 May 2015 01:52:59 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.28]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 28 May 2015 08:52:55 +0800 From: Xuxiaohu To: Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuM0lb/ClIVSo0COEkQDCSPTh52Pi0GAgAEP9wA= Date: Thu, 28 May 2015 00:52:54 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083375E1@NKGEML512-MBS.china.huawei.com> References: <555C5A1D.7020709@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D571818AD@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571818AD@dfweml701-chm> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 00:53:05 -0000 This is a useful draft and I support the adoption. Best regards, Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, May 20, 2015 4:56 AM > To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus adopting > draft-bonica-mpls-self-ping as an MPLS wg document >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-bonica-mpls-self- > ping-06 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working group > mailing list (mpls@ietf.org). Please give a technical motivation for your > support/not support, especially if you think that the document should not= be > adopted as a working group document. >=20 > There is one IPR disclosures directly against this document. All the auth= ors has > stated on the working group mailing that they are unaware of any undisclo= sed > IPRs against this document. >=20 > However if you are on the the mpls working group mailing list and aware o= f IPR > that relates to this draft, the time to disclose this is now. >=20 > This poll ends June 5, 2015. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed May 27 18:10:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42F91B2B5B for ; Wed, 27 May 2015 18:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 pAqNrPUUWeKT for ; Wed, 27 May 2015 18:10:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6FF1A03A1 for ; Wed, 27 May 2015 18:10:00 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-92-556611da14b5 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AA.01.32689.AD116655; Wed, 27 May 2015 20:50:03 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Wed, 27 May 2015 21:09:58 -0400 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuMpAIyTTesLm0OZ+FuxSQ++Vp2QVGuAgACKHwD//8DXwA== Date: Thu, 28 May 2015 01:09:57 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9AA772@eusaamb103.ericsson.se> References: <555C5A1D.7020709@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D571818AD@dfweml701-chm> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083375E1@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083375E1@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPlO5twbRQg2lfGS162+ezW/ybO4fZ 4vulJSwWt5auZHVg8Viy5CeTx6zpbWweXy5/ZgtgjuKySUnNySxLLdK3S+DKmLHwKVPBB/6K +S/ZGxhf83QxcnBICJhITFwf0cXICWSKSVy4t56ti5GLQ0jgKKPE7ctXoJzljBI7/z1jBqli EzCSeLGxhx0kISJwi1FiUcMWFpCEsECRxLnrzxhBbBGBYomFu15D2U4SLzZPYAfZxiKgKvHo qztImFfAV+LPl1VQC1YzStz8D7Kak4NTIEzixc2LYMsYgU76fmoNE4jNLCAucevJfCaIUwUk luw5zwxhi0q8fPyPFcJWkpi09BwrRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C 0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBMbKMQk23R2Me15aHmIU4GBU4uF98CYlVIg1say4 MvcQozQHi5I47zfDkFAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKu09wbzO4cyCGw0yk5f u9YpOj3ep0P0lbfmygvday0flK5Lrt+wolRihZaqw++CHPnwYr60pwp3Tzyde65jzoqJDxZp lL7heDRHSr0k+/lC76PF4h+2v5qvynjZIPz4/bQNc4OidVbt93Bp1XHUFz/Ob+sft1rn/9ct +kc5rkseKV3RNq9yqRJLcUaioRZzUXEiAOeY9AB2AgAA Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 01:10:01 -0000 I believe that the document addresses practical use case and offers reasona= ble solution. The document have been improved and I think that now is ready= for WG adoption. Regards, Greg=09 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, May 20, 2015 4:56 AM > To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus adopting=20 > draft-bonica-mpls-self-ping as an MPLS wg document >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-bonica-mpls-self- > ping-06 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working=20 > group mailing list (mpls@ietf.org). Please give a technical motivation=20 > for your support/not support, especially if you think that the=20 > document should not be adopted as a working group document. >=20 > There is one IPR disclosures directly against this document. All the=20 > authors has stated on the working group mailing that they are unaware=20 > of any undisclosed IPRs against this document. >=20 > However if you are on the the mpls working group mailing list and=20 > aware of IPR that relates to this draft, the time to disclose this is now= . >=20 > This poll ends June 5, 2015. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed May 27 18:47:40 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DE31B2B7C for ; Wed, 27 May 2015 18:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 h9LPpXUTUy_7 for ; Wed, 27 May 2015 18:47:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F1C1B2B76 for ; Wed, 27 May 2015 18:47:35 -0700 (PDT) Received: from DM2PR0501MB1310.namprd05.prod.outlook.com (25.160.130.151) by DM2PR0501MB1311.namprd05.prod.outlook.com (25.160.130.152) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 01:47:16 +0000 Received: from DM2PR0501MB1310.namprd05.prod.outlook.com ([25.160.130.151]) by DM2PR0501MB1310.namprd05.prod.outlook.com ([25.160.130.151]) with mapi id 15.01.0172.012; Thu, 28 May 2015 01:47:16 +0000 From: Raveendra Torvi To: Gregory Mirsky Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuMu9hbBta/+l0mrUDBhExs+F52QEV2AgACKHwCAAATDgIAACm4T Date: Thu, 28 May 2015 01:47:16 +0000 Message-ID: <8995D06A-93EB-4C27-8315-C6FC52C65B03@juniper.net> References: <555C5A1D.7020709@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D571818AD@dfweml701-chm> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083375E1@NKGEML512-MBS.china.huawei.com>, <7347100B5761DC41A166AC17F22DF1121B9AA772@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B9AA772@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rtorvi@juniper.net; x-originating-ip: [24.218.20.33] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1311; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DM2PR0501MB1311; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1311; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(189002)(164054003)(51444003)(24454002)(199003)(13464003)(62966003)(77156002)(102836002)(40100003)(64706001)(66066001)(36756003)(230783001)(97736004)(2900100001)(68736005)(5001830100001)(2950100001)(92566002)(101416001)(122556002)(93886004)(46102003)(86362001)(50986999)(99286002)(105586002)(106116001)(87936001)(2656002)(54356999)(76176999)(83716003)(5001960100002)(106356001)(81156007)(19580395003)(110136002)(4001540100001)(82746002)(189998001)(5001860100001)(5002640100001)(33656002)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1311; H:DM2PR0501MB1310.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 01:47:16.4926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1311 Archived-At: Cc: "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 01:47:38 -0000 As a co-author, I support this draft for WG adoption. Thanks, Ravi > On May 27, 2015, at 9:10 PM, Gregory Mirsky = wrote: >=20 > I believe that the document addresses practical use case and offers reaso= nable solution. The document have been improved and I think that now is rea= dy for WG adoption. >=20 > Regards, > Greg =20 >=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Wednesday, May 20, 2015 4:56 AM >> To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; >> mpls-chairs@tools.ietf.org >> Subject: [mpls] Poll to see if we have consensus adopting=20 >> draft-bonica-mpls-self-ping as an MPLS wg document >>=20 >> Working Group, >>=20 >> This is to start a two week poll on adopting draft-bonica-mpls-self- >> ping-06 as an MPLS working group document. >>=20 >> Please send your comments (support/not support) to the mpls working=20 >> group mailing list (mpls@ietf.org). Please give a technical motivation=20 >> for your support/not support, especially if you think that the=20 >> document should not be adopted as a working group document. >>=20 >> There is one IPR disclosures directly against this document. All the=20 >> authors has stated on the working group mailing that they are unaware=20 >> of any undisclosed IPRs against this document. >>=20 >> However if you are on the the mpls working group mailing list and=20 >> aware of IPR that relates to this draft, the time to disclose this is no= w From nobody Thu May 28 00:32:51 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43C21A6F2F for ; Thu, 28 May 2015 00:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 LaUTa58nfbp2 for ; Thu, 28 May 2015 00:32:47 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0689.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::689]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34701A6FF2 for ; Thu, 28 May 2015 00:32:45 -0700 (PDT) Received: from DB5PR03MB0999.eurprd03.prod.outlook.com (25.162.154.17) by DB5PR03MB1000.eurprd03.prod.outlook.com (25.162.154.18) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 07:15:42 +0000 Received: from DB5PR03MB0999.eurprd03.prod.outlook.com ([25.162.154.17]) by DB5PR03MB0999.eurprd03.prod.outlook.com ([25.162.154.17]) with mapi id 15.01.0172.012; Thu, 28 May 2015 07:15:43 +0000 From: Yaakov Stein To: Alexander Vainshtein , "mpls@ietf.org" Thread-Topic: [mpls] review of draft-mirsky-mpls-residence-time Thread-Index: AQHQl3oNpYbslVqzzkqNvhquyBxTfJ2Q+SVg Date: Thu, 28 May 2015 07:15:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yaakov_s@rad.com; x-originating-ip: [80.74.105.107] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR03MB1000; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DB5PR03MB1000; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB1000; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(51694002)(199003)(479174004)(37854004)(189002)(33656002)(19625215002)(66066001)(102836002)(19580395003)(2950100001)(15975445007)(68736005)(64706001)(2900100001)(76576001)(74316001)(230783001)(50986999)(101416001)(19580405001)(87936001)(2501003)(2656002)(19300405004)(5001960100002)(107886002)(189998001)(5001860100001)(5001920100001)(122556002)(81156007)(92566002)(105586002)(4001540100001)(54356999)(97736004)(5001770100001)(5002640100001)(62966003)(106116001)(77156002)(76176999)(106356001)(40100003)(86362001)(46102003)(5001830100001)(16236675004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB1000; H:DB5PR03MB0999.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rad.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DB5PR03MB0999E172F50EC022BD742F93E5CA0DB5PR03MB0999eurp_" MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 07:15:42.7123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB1000 Archived-At: Subject: Re: [mpls] review of draft-mirsky-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 07:32:50 -0000 --_000_DB5PR03MB0999E172F50EC022BD742F93E5CA0DB5PR03MB0999eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FzaGENCg0KSSBob3BlIHRoYXQgeW91IGFyZSBmZWVsaW5nIGJldHRlci4NCg0KMS4gSSBhbSBs b29raW5nIGF0IHZlcnNpb24gNiBvZiB0aGlzIGRyYWZ0LCB3aGljaCBvbiBwYWdlIDUgc2hvd3Mg dGhlIFNjcmF0Y2ggUGFkIGZvbGxvd2VkIGJ5IFR5cGUsIExlbmd0aCwgVmFsdWUNCmFuZCBleHBs YWlucyA6DQpUaGUgVHlwZSBmaWVsZCBpZGVudGlmaWVzIHRoZSB0eXBlIG9mIFZhbHVlIHRoYXQg dGhlIFRMViBjYXJyaWVzLg0KICBJQU5BIHdpbGwgYmUgYXNrZWQgdG8gY3JlYXRlIGEgc3ViLXJl Z2lzdHJ5IGluIEdlbmVyaWMgQXNzb2NpYXRlZA0KQ2hhbm5lbCAoRy1BQ2gpIFBhcmFtZXRlcnMg UmVnaXN0cnkgY2FsbGVkICJNUExTIFJUTSBUTFYNClJlZ2lzdHJ5Ii4NCg0KMi4gSSBhZ3JlZSB0 aGF0IGEgbGVnYWN5IGRldmljZSB3aWxsIG5vdCBpbnNwZWN0IHlvdXIgc3RydWN0dXJlLg0KSSB3 YXMganVzdCBxdWVzdGlvbmluZyBpdHMgaGFuZGxpbmcgb2YgR0FDaCBwYWNrZXRzLCB3aGV0aGVy IG9yIG5vdCBUVEwgaGFzIGV4cGlyZWQuDQoNCjMuIEFzIHlvdSB3aWxsIHJlbWVtYmVyLCB3aGF0 IHlvdSBjYWxsIG1vZGlmaWNhdGlvbiBvZiB0aGUgTVBMUyBkYXRhIHBsYW5lIGJ5IHRoZSBUSUNU T0MgZHJhZnQNCndhcyBwcmVjaXNlbHkgd2hhdCB3ZSB3ZXJlIGluc3RydWN0ZWQgYnkgdGhlIE1Q TFMgV0cgcmV2aWV3ZXJzLg0KT3VyIG9yaWdpbmFsIGluY2xpbmF0aW9uIHdhcyB0byByZXF1ZXN0 IGEgcmVzZXJ2ZWQgbGFiZWwgZm9yIHRpbWluZyBwYWNrZXRzLg0KVGhlIFRJQ1RPQyBkcmFmdCBk b2VzIG5vdCBkZWZpbmUgYW55IG5ldyBGT1JXQVJESU5HIGJlaGF2aW9yLA0KaXQgZG9lcyByZXF1 aXJlIHN0YW5kYXJkIDE1ODggZmllbGQgbW9kaWZpY2F0aW9uLg0KVGhpcyBpcyBwcmVjaXNlbHkg dGhlIHNhbWUgbGF5ZXIgdmlvbGF0aW9uIGFzIDE1ODggVEMgbWFuZGF0ZXMgZm9yIGFsbCBpdHMg dHJhbnNwb3J0IGxheWVycywNCkV0aGVybmV0LCBJRFAvSVB2NCwgSURQL0lQdjYsIERldmljZU5F VCwgQ29udHJvbE5FVCwgUFJPRklORVQsIOKApg0KDQpZKEopUw0KDQpGcm9tOiBBbGV4YW5kZXIg VmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KU2Vu dDogMjYvMDUvMjAxNSAwOTowNg0KVG86IFlhYWtvdiBTdGVpbjsgbXBsc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFttcGxzXSByZXZpZXcgb2YgZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRlbmNlLXRp bWUNCg0KDQpZYWFrb3YsDQoNCkxvdHMgb2YgdGhhbmtzIGZvciBhIHZlcnkgZGV0YWlsZWQgcmV2 aWV3Lg0KDQpJIGRlZmVyIHRvIG90aGVyIGNvLWF1dGhvcnMgdG8gZGVzY3JpYmUgdGhlIHJlbGV2 YW50IHVzZSBjYXNlcyBpbiBtb3JlIGRldGFpbC4NCg0KDQoNCkkganVzdCB3YW50ZWQgdG8gY29t bWVudCBvbiB0d28gcG9pbnRzOg0KDQoxLiBUaGUgZHJhZnQgZG9lcyBub3QgdXNlIEdBQ2ggVExW cyAodGhhdCBoYXZlIGJlZW4gZGVwcmVjYXRlZCBCVFcpLg0KDQoyLiBBIGxlZ2FjeSBkZXZpY2Ug dGhhdCBkb2VzIG5vdCBoYXZlIFJUTSBjYXBhYmlsaXRpZXMgd2lsbCBuZXZlciBpbnNwZWN0IHRo ZSBHQUwvR0FDaCBjb25zdHJ1Y3QgdXNlZCBpbiB0aGUgZHJhZnQsIGJlY2F1c2Ugc3VjaCBpbnNw ZWN0aW9uIGNhbiBvbmx5IGhhcHBlbiBlaXRoZXIgYXQgdGhlIExTUCB0YWlsLWVuZCBub2RlIG9y IGF0IGFuIFJUTS0gY2FwYWJsZSBub2RlIHRoYXQgdHJhcHMgdGhlIFJUTSBwYWNrZXQgZHVlIHRv IFRUTCBleHBpcmF0aW9uLg0KDQpUaGlzIGxhc3QgcG9pbnQgaXMgSU1ITyBhIG1ham9yIGRpZmZl cmVudGlhdG9yIGJldHdlZW4gdGhpcyBkcmFmdCBhbmQgb25lIGhhbmRsZWQgYnkgdGhlIFRJQ1RP QyBXRzoNCg0KLSB0aGlzIGRyYWZ0IGRvZXMgbm90IGNoYW5nZSB0aGUgTVBMUyBEUCBhcyBkZWZp bmVkIGluIFJGQyAzMDMxIGFuZCBSRkMgMzQ0Mw0KDQotIHRoZSBUSUNUT0MgZHJhZnQgKGF0IGxl YXN0IHRvIHRoZSBiZXN0IG9mIG15IHJlY29sbGVjdGlvbikgYXNzaWduZWQgc3BlY2lhbCBoYW5k bGluZyB0byBsYWJlbHMgdXNlZCBieSB0aGUgTFNQcyBjYXJyeWluZyBQVFAgcGFja2V0cyB0aGF0 IHdhcyBub3QgZGVmaW5lZCBhcyBhICJsYWJlbCBhY3Rpb24iIGluIFJGQyAzMDMxIChuZWl0aGVy IFBvcCwgbm9yIFN3YXAgbm9yIFB1c2gpLg0KDQoNCg0KUmVnYXJkcywNCg0KU2FzaGENCg0KDQoN Cg0KVGh1bWIgdHlwZWQgb24gbXkgTEcsDQpTYXNoYQ0KDQotLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0NCkZyb206IFlhYWtvdiBTdGVpbg0KRGF0ZTogMjYvMDUvMjAxNSAwODoxMQ0KVG86 IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KU3ViamVjdDpbbXBsc10gcmV2 aWV3IG9mIGRyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lDQpMb2EgYXNrZWQgbWUgdG8g Y29tbWVudCBvbiB0aGlzIGRyYWZ0IGJlZm9yZSBpdHMgYWNjZXB0YW5jZSBhcyBhIE1QTFMgV0cg ZHJhZnQuDQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBwdXJwb3NlIG9mIHRoaXMgZHJh ZnQgaXMgdG8gcHJvdmlkZSBhIGZvcm0gb2Ygd2hhdCBpcyBjYWxsZWQg4oCcb24tcGF0aCB0aW1p bmcgc3VwcG9ydOKAnSBpbiB0aGUgVElDVE9DIFdHLg0KVGhlIHNwZWNpZmljIGtpbmQgb2Ygb24t cGF0aCBzdXBwb3J0IGlzIGFjY3VtdWxhdGlvbiBvZiByZXNpZGVuY2UgdGltZXMgaW4gTFNScyB3 aGljaCBhIHRpbWUtc2Vuc2l0aXZlIGZsb3cgdHJhdmVyc2VzLg0KQXMgc3VjaCBpdCBpcyBlc3Nl bnRpYWxseSB0aGUgc2FtZSBhcyB3aGF0IGlzIGNhbGxlZCDigJx0cmFuc3BhcmVudCBjbG9ja2lu Z+KAnSAoVEMpIGluIElFRUUgMTU4OCwgYW5kIHRoZSBkcmFmdCBpbmRlZWQgcmUtdXNlcyBUQyB0 ZWNobm9sb2dpZXMuDQoNCkhvd2V2ZXIgdGhpcyBkcmFmdCBhdHRlbXB0cyB0byByZW1lZHkgYSBw cm9ibGVtIHdpdGggVEMgYXMgcHJlc2VudGx5IGltcGxlbWVudGVkIOKAkyBpdHMgbGF5ZXIgdmlv bGF0aW9uLg0KVGhpcyB2aW9sYXRpb24gb2NjdXJzIHNpbmNlIHBoeXNpY2FsIGxheWVyIHRpbWlu ZyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIG1vZGlmeSBhIGZpZWxkIG9mIGEgaGlnaGVyIGxheWVy IHByb3RvY29sLg0KVGhlIHByZXNlbnQgZHJhZnQgcmVtZWRpZXMgdGhpcyBieSBmb3JjaW5nIGhv cC1ieS1ob3AgYmVoYXZpb3IgYnkgVFRMIGZpZWxkIG1hbmlwdWxhdGlvbiwNCmJ1dCBhdCB0aGUg cHJpY2Ugb2YgaGF2aW5nIHRvIHRyYW5zcG9ydCB0aW1pbmcgZmxvd3MgaW4gdGhlIGFzc29jaWF0 ZWQgY2hhbm5lbCwNCnByZXZpb3VzbHkgbGltaXRlZCB0byBPQU0gYW5kIGNvbnRyb2wvbWFuYWdl bWVudCBwbGFuZSB1c2VzLg0KDQpBcyBzdWNoIHRoZSBkcmFmdCBlbGVnYW50bHkgc29sdmVzIGEg dGhlb3JldGljYWwgcHJvYmxlbS4NCg0KSSBhbSBsZXNzIHN1cmUgdGhhdCBpdCBzb2x2ZXMgYSBy ZWFsLXdvcmxkIHByb2JsZW0sIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnMgOg0KDQoxLiBGaXJz dCBpcyB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgc2ltcGxlciBhbHRlcm5hdGl2ZSBmb3Igb24t cGF0aCBzdXBwb3J0IG9mIDE1ODggb3ZlciBNUExTIHRoYXQgaGFzIGFscmVhZHkgcGFzc2VkIFdH IExDIGluIFRJQ1RPQy4NClRoZSBleGlzdGluZyBUSUNUT0MgZHJhZnQgd2FzIHB1cnBvc2VseSBj b25zdHJhaW5lZA0KKGZvbGxvd2luZyBhZHZpY2Ugb2YgcmV2aWV3ZXJzIHdobyBhcmUgTVBMUyBl eHBlcnRzKQ0KdG8gbm90IHRvdWNoIHRoZSBNUExTIGZvcndhcmRpbmcgcGxhbmUsIHdoaWxlIHRo aXMgZHJhZnQgZGVmaW5lcyBHQUNoIFRMVnMgYW5kIHN1Yi1UTFZzLg0KVGhlIHByZXNlbnQgZHJh ZnQgaXMgYWRtaXR0ZWRseSBtdWNoIHdpZGVyIGluIGFwcGxpY2FiaWxpdHksIGJ1dCBubyB1c2Ug b3RoZXIgdGhhbiAxNTg4IG9uLXBhdGggc3VwcG9ydCBpcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0 Lg0KDQoyLiBPbmUgY29uY2VpdmFibGUgdXNlIHdvdWxkIGJlIGZvciBoaWdobHkgYWNjdXJhdGUg b25lLXdheSBkZWxheSBlc3RpbWF0aW9uIHdpdGhvdXQgc3luY2hyb25pemVkIGNsb2Nrcw0KKGFu ZCBJIGFtIG5vdCBzdXJlIHdoZW4gdGhpcyB1c2UgaXMgcmVhbGx5IG5lZWRlZCkuDQpPZiBjb3Vy c2UgdGhlIHByZXNlbnQgbWV0aG9kIG9ubHkgYWNjb3VudHMgZm9yIHJlc2lkZW5jZSB0aW1lIGlu IExTUnMsIG5vdCBmb3IgcHJvcGFnYXRpb24gbGF0ZW5jaWVzIG9uIGxpbmtzICh3aGljaCAxNTg4 IGNhbiBoYW5kbGUgYXMgd2VsbCkuDQpUaGUgbWV0aG9kb2xvZ3kgdG8gb3ZlcmNvbWUgdGhpcyBs aW1pdGF0aW9uIHdvdWxkIGFzc3VtYWJseSBiZSB0byByZWx5IG9uIGEgY28tcm91dGVkIHJvdW5k LXRyaXAsIHRvIHVzIHRoaXMgZHJhZnQgdG8gY2FuY2VsIHJlc2lkZW5jZSB0aW1lcywNCmFuZCB0 aGVuIHRvIG1lYXN1cmUgdGhlIHJlbWFpbmluZyByb3VuZC10cmlwIHRpbWUgYW5kIGRpdmlkZSBi eSB0d28uDQpIb3dldmVyLCBleGlzdGluZyBhbGdvcml0aG1zIGRvIGEgcHJldHR5IGdvb2Qgam9i IGF0IGNhbmNlbGxpbmcgcmVzaWRlbmNlIHRpbWVzDQpleGNlcHQgd2hlbiB0aGUgZmxvdyB0cmF2 ZXJzZXMgYSBsYXJnZSBudW1iZXIgb2YgbmV0d29yayBlbGVtZW50cyB3aGljaCBhcmUgaGVhdmls eSBsb2FkZWQgd2l0aCBwbGVzaW9jaHJvbm91c2x5IHJlbGF0ZWQgaW50ZXJmZXJpbmcgZmxvd3Mu DQpEbyB0aGUgYXV0aG9ycyBoYXZlIGFub3RoZXIgdXNlIGNhc2UgaW4gbWluZCA/DQoNCjMuIFRo ZSBwcmltYXJ5IGRvY3VtZW50ZWQgYXBwbGljYXRpb24gZm9yIDE1ODggaW4gdGVsZWNvbSBuZXR3 b3JrcyBpcyBjZWxsdWxhciBiYWNraGF1bC4NClRoaXMgYXBwbGljYXRpb24gYWxyZWFkeSBoYXMg YSBwbGV0aG9yYSBvZiBzb2x1dGlvbnMsIGJhc2VkIG9uIEdQUywgMTU4OCBvdmVyIEV0aGVybmV0 IHdpdGggYm91bmRhcnkgY2xvY2tzIChCQyksIGRpc3RyaWJ1dGVkIGdyYW5kIG1hc3RlcnMsIGV0 Yy4gZXRjLiBldGMuDQpOb3RlIHRoYXQgQkMgYXMgd2lkZWx5IGRlcGxveWVkIGlzIGFscmVhZHkg aG9wLWJ5LWhvcCwgYW5kIGluIHRoYXQgd2F5IHNpbWlsYXIgdG8gdGhpcyBkcmFmdC4NCklzIHll dCBhbm90aGVyIHNvbHV0aW9uIHJlYWxseSBuZWVkZWQgPw0KDQo0LiBSZWxhdGVkIHRvIHRoZSBw cmV2aW91cyBxdWVzdGlvbnMgaXMgdGhlIGlzc3VlIG9mIGltcGxlbWVudGF0aW9uIGluIGFscmVh ZHkgZXhpc3RpbmcgbmV0d29ya3MuDQpUaGlzIHNvbHV0aW9uIHJlcXVpcmVzIGhhcmR3YXJlIHVw Z3JhZGVzIGF0IGxlYXN0IGZvciB0aGUgYWNjdXJhdGUgdGltZS1zdGFtcGluZyBhbmQgcG9zc2li bHkgZm9yIHRoZSBhY2N1bXVsYXRpb24gYW5kIGZpZWxkIG1vZGlmaWNhdGlvbg0KKGFsdGhvdWdo IHRoZSBsYXR0ZXIgbWF5IHNvZnR3YXJlIHVwZ3JhZGVzLCBlc3BlY2lhbGx5IGlmIDItc3RlcCBj b3JyZWN0aW9uIGlzIHV0aWxpemVkKS4NCklmIHdlIG5lZWQgdG8gdXBncmFkZSBoYXJkd2FyZSwg d2h5IG5vdCBkZXBsb3kgQkNzID8NCkEgZmV3IHllYXJzIGJhY2sgSSB3b3VsZCBoYXZlIHNhaWQg dGhhdCBUQyBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBtaW5pYXR1cml6ZWQgZGV2aWNlcyB3aGVy ZSBCQyBjb3VsZCBub3QsDQpidXQgYWR2YW5jZXMgaW4gbWluaWF0dXJpemF0aW9uIG9mIE9DWE9z IGhhdmUgc2V2ZXJlbHkgcmVkdWNlZCB0aGlzIGFkdmFudGFnZSB0byBjYXNlcyB3aGVyZSBhdG9t aWMtY2xvY2sgaG9sZC1vdmVyIGlzIHJlcXVpcmVkLg0KDQo1LiBJZiBhbm90aGVyIHNvbHV0aW9u IGZvciB0aGlzIHNwZWNpZmljIGFwcGxpY2F0aW9uIGlzIG5lZWRlZCwgaXMgaXQgbmVlZGVkIGZv ciBNUExTID8NCkNlbGx1bGFyIGJhY2toYXVsIG92ZXIgY2FycmllciBFdGhlcm5ldCBpcyB3aWRl bHkgZGVwbG95ZWQsIGlzIGNlbGx1bGFyIGJhY2toYXVsIG92ZXIgTVBMUyBzdWZmaWNpZW50bHkg d2lkZXNwcmVhZCB0byBtZXJpdCB0aGlzIGV4dGVuc2lvbiA/DQoNCjYuIE1QTFMgZG9lcyBub3Qg ZGVmaW5lIGl0cyBvd24gcGh5c2ljYWwgbGF5ZXIgKHdoaWNoIEV0aGVybmV0IGRvZXMg4oCTIHRo ZSBsYXllciBjYWxsZWQgRVRZIGluIHRoZSBJVFUpLg0KQXMgc3VjaCBpdCBpcyBub3QgY2xlYXIg dGhhdCBNUExTIGlzIHRoZSByaWdodCBwbGFjZSB0byBzb2x2ZSB0aGUgdGltaW5nIGRpc3RyaWJ1 dGlvbiBwcm9ibGVtLg0KTVBMUyBuZWNlc3NhcmlseSBydW5zIG92ZXIgc29tZSBwaHlzaWNhbCBs YXllciB3aGljaCBtYXkgYWxyZWFkeSBoYXZlIG9uLXBhdGggc3VwcG9ydCwgb3IgbWF5IG1vcmUg ZWNvbm9taWNhbGx5IHN1cHBvcnQgaXQuDQoNCkFsbCBvZiB0aGUgYXV0aG9ycyB3b3JrIGZvciB2 ZW5kb3JzIOKAkyBoYXZlIHRoZXNlIHZlbmRvcnMgaW1wbGVtZW50ZWQgdGhpcyBvciBkbyB0aGV5 IHBsYW4gaW1wbGVtZW50aW5nID8NCklmIHRoZSBhbnN3ZXIgaXMgYSByZXNvdW5kaW5nIHllcywg dGhlbiBJIGFzc3VtZSB0aGF0IHdlIHdpbGwgaGVhciByZWJ1dHRhbHMgdG8gbW9zdCBvZiB0aGUg YWJvdmUgcmVtYXJrcy4NCg0KUmVnYXJkaW5nIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCwgSSBo YXZlIGEgbWFqb3IgaXNzdWUgd2l0aCB0aGUgdXNlIG9mIHRoZSB0ZXJtIOKAnFNjcmF0Y2ggUGFk 4oCdIGZvciB0aGUgY29ycmVjdGlvbiBmaWVsZA0KKGFuZCBCVFcsIGl0IGlzIHNvbWV0aW1lcyBj YWxsZWQg4oCcU2NyYXRjaCBQYWTigJ0gYW5kIHNvbWV0aW1lcyDigJxTY3JhdGNoUGFk4oCdIGFu ZCBzb21ldGltZXMg4oCcc2NyYXRjaCBwYWTigJ0pLg0KVGhpcyBmaWVsZCBpcyBub3Qgc29tZSBv cGFxdWUgbWV0YS1kYXRhIHRyYW5zcG9ydGVkIGJ5IHRoaXMgbmV3bHkgZGVmaW5lZCBoZWFkZXIs DQppdCBpcyB0aGUgdmVyeSBjcnV4IG9mIHRoZSBzb2x1dGlvbiBhbmQgcmVxdWlyZXMgbWFuaXB1 bGF0aW9uIHRvIHdvcmsuDQpDYWxsaW5nIGl0IGEg4oCcc2NyYXRjaCBwYWTigJ0gKHdpdGggYW55 IG9mIHRoZSBzcGVsbGluZ3MpIGlzIHRhbnRhbW91bnQgdG8gY2FsbGluZyBhbiBNUExTIGxhYmVs IGFuIOKAnGFyYml0cmFyeSBiaXQtZmllbGTigJ0uDQpCb3RoIHRlcm1zIG1heSBiZSB0ZWNobmlj YWxseSBjb3JyZWN0LCBidXQgaGlkZSB0aGUgbWVhbmluZyBvZiB0aGUgZmllbGQgYW5kIGluY3Jl YXNlIHRoZSBsb2FkIG9uIHJlYWRlciBpbiB1bmRlcnN0YW5kaW5nIHRoZSB0ZWNobm9sb2d5Lg0K DQpBcyBhbiBhc2lkZSwgdGhlIGFmb3JlbWVudGlvbmVkIFRJQ1RPQyBXRyBkcmFmdCBvcmlnaW5h bGx5IGNvbnRhaW5lZCBleHRlbnNpb25zIHRvIE9TUEYsIFJTVlAtVEUsIGV0Yy4NCkl0IHdhcyBk ZWNpZGVkIHRvIHNlcGFyYXRlIHRoZSBjb250cm9sIGV4dGVuc2lvbnMgZnJvbSB0aGUgZm9yd2Fy ZGluZyBwbGFuZSBkcmFmdCwgYW5kIHRvIHB1cnN1ZSBlYWNoIGluIHRoZSBtb3N0IGFwcHJvcHJp YXRlIFdHLg0KSXQgbWlnaHQgYmUgYSBnb29kIGlkZWEgdG8gZG8gdGhlIHNhbWUgaGVyZS4NCg0K T25lIG9mIHRoZSBmYWN0cyBvZiBsaWZlIHdpdGggb24tcGF0aCBzdXBwb3J0IG9mIHRpbWluZyBk aXN0cmlidXRpb24gaXMgdGhhdCBpdCBpcyBvZnRlbiBvbmx5IHBhcnRpYWwuDQpXaGF0IGhhcHBl bnMgdG8gdGhpcyBzb2x1dGlvbiB3aGVuIHRoZXJlIGlzIG9ubHkgcGFydGlhbCBzdXBwb3J0Pw0K SSBjYW4gaW1hZ2luZSB1bnJlY29nbml6ZWQgR0FDaCBwYWNrZXRzIGJlaW5nIGJvb3RlZCB0byBD UFUgaW4gc3VjaCBjYXNlcywgc2V2ZXJlbHkgaW1wYWN0aW5nIHVuY29tcGVuc2F0ZWQgcmVzaWRl bmNlIHRpbWUuDQoNClkoSilTDQoNCg== --_000_DB5PR03MB0999E172F50EC022BD742F93E5CA0DB5PR03MB0999eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNh c2hhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGhvcGUgdGhhdCB5b3Ug YXJlIGZlZWxpbmcgYmV0dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ MS4gSSBhbSBsb29raW5nIGF0IHZlcnNpb24gNiBvZiB0aGlzIGRyYWZ0LCB3aGljaCBvbiBwYWdl IDUgc2hvd3MgdGhlIFNjcmF0Y2ggUGFkIGZvbGxvd2VkIGJ5IFR5cGUsIExlbmd0aCwgVmFsdWU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+YW5kIGV4cGxhaW5zIDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PC9zcGFuPjxzcGFu IGxhbmc9IkVOIj5UaGUgVHlwZSBmaWVsZCBpZGVudGlmaWVzIHRoZSB0eXBlIG9mIFZhbHVlIHRo YXQgdGhlIFRMViBjYXJyaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsgSUFOQSB3aWxsIGJlIGFza2VkIHRvIGNyZWF0 ZSBhIHN1Yi1yZWdpc3RyeSBpbiBHZW5lcmljIEFzc29jaWF0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+Q2hhbm5lbCAoRy1BQ2gp IFBhcmFtZXRlcnMgUmVnaXN0cnkgY2FsbGVkICZxdW90O01QTFMgUlRNIFRMVjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj5SZWdpc3Ry eSZxdW90Oy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Mi4gSSBhZ3JlZSB0aGF0IGEgbGVnYWN5IGRldmljZSB3 aWxsIG5vdCBpbnNwZWN0IHlvdXIgc3RydWN0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIHdhcyBqdXN0 IHF1ZXN0aW9uaW5nIGl0cyBoYW5kbGluZyBvZiBHQUNoIHBhY2tldHMsIHdoZXRoZXIgb3Igbm90 IFRUTCBoYXMgZXhwaXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjMu IEFzIHlvdSB3aWxsIHJlbWVtYmVyLCB3aGF0IHlvdSBjYWxsIG1vZGlmaWNhdGlvbiBvZiB0aGUg TVBMUyBkYXRhIHBsYW5lIGJ5IHRoZSBUSUNUT0MgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+d2FzIHBy ZWNpc2VseSB3aGF0IHdlIHdlcmUgaW5zdHJ1Y3RlZCBieSB0aGUgTVBMUyBXRyByZXZpZXdlcnMu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+T3VyIG9yaWdpbmFsIGluY2xpbmF0aW9uIHdhcyB0byByZXF1ZXN0 IGEgcmVzZXJ2ZWQgbGFiZWwgZm9yIHRpbWluZyBwYWNrZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUg VElDVE9DIGRyYWZ0IGRvZXMgbm90IGRlZmluZSBhbnkgbmV3IEZPUldBUkRJTkcgYmVoYXZpb3Is PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPml0IGRvZXMgcmVxdWlyZSBzdGFuZGFyZCAxNTg4IGZpZWxkIG1vZGlm aWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBpcyBwcmVjaXNlbHkgdGhlIHNhbWUgbGF5ZXIg dmlvbGF0aW9uIGFzIDE1ODggVEMgbWFuZGF0ZXMgZm9yIGFsbCBpdHMgdHJhbnNwb3J0IGxheWVy cywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5FdGhlcm5ldCwgSURQL0lQdjQsIElEUC9JUHY2LCBEZXZpY2VO RVQsIENvbnRyb2xORVQsIFBST0ZJTkVULCDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlkoSilTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj5Gcm9tOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNi8wNS8yMDE1IDA5OjA2 PGJyPg0KPGI+VG86PC9iPiBZYWFrb3YgU3RlaW47IG1wbHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFttcGxzXSByZXZpZXcgb2YgZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRlbmNl LXRpbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPllhYWtvdiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Mb3RzIG9mIHRoYW5rcyBmb3IgYSB2 ZXJ5IGRldGFpbGVkIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5JIGRlZmVyIHRvIG90aGVyIGNvLWF1dGhvcnMgdG8gZGVzY3JpYmUgdGhlIHJlbGV2YW50 IHVzZSBjYXNlcyBpbiBtb3JlIGRldGFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5JIGp1c3Qgd2FudGVkIHRvIGNvbW1lbnQgb24gdHdvIHBvaW50czo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4xLiBUaGUgZHJhZnQgZG9lcyBub3QgdXNlIEdBQ2gg VExWcyAodGhhdCBoYXZlIGJlZW4gZGVwcmVjYXRlZCBCVFcpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjIuIEEgbGVnYWN5IGRldmljZSB0aGF0IGRvZXMgbm90IGhh dmUgUlRNIGNhcGFiaWxpdGllcyB3aWxsIG5ldmVyIGluc3BlY3QgdGhlIEdBTC9HQUNoIGNvbnN0 cnVjdCB1c2VkIGluIHRoZSBkcmFmdCwgYmVjYXVzZSBzdWNoIGluc3BlY3Rpb24gY2FuIG9ubHkg aGFwcGVuIGVpdGhlciBhdCB0aGUgTFNQIHRhaWwtZW5kDQogbm9kZSBvciBhdCBhbiBSVE0tIGNh cGFibGUgbm9kZSB0aGF0IHRyYXBzIHRoZSBSVE0gcGFja2V0IGR1ZSB0byBUVEwgZXhwaXJhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGlzIGxhc3QgcG9p bnQgaXMgSU1ITyBhIG1ham9yIGRpZmZlcmVudGlhdG9yIGJldHdlZW4gdGhpcyBkcmFmdCBhbmQg b25lIGhhbmRsZWQgYnkgdGhlIFRJQ1RPQyBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4tIHRoaXMgZHJhZnQgZG9lcyBub3QgY2hhbmdlIHRoZSBNUExTIERQIGFz IGRlZmluZWQgaW4gUkZDIDMwMzEgYW5kIFJGQyAzNDQzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+LSB0aGUgVElDVE9DIGRyYWZ0IChhdCBsZWFzdCB0byB0aGUgYmVz dCBvZiBteSByZWNvbGxlY3Rpb24pIGFzc2lnbmVkIHNwZWNpYWwgaGFuZGxpbmcgdG8gbGFiZWxz IHVzZWQgYnkgdGhlIExTUHMgY2FycnlpbmcgUFRQIHBhY2tldHMgdGhhdCB3YXMgbm90IGRlZmlu ZWQgYXMgYSAmcXVvdDtsYWJlbCBhY3Rpb24mcXVvdDsgaW4gUkZDDQogMzAzMSAobmVpdGhlciBQ b3AsIG5vciBTd2FwIG5vciBQdXNoKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNhc2hhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPlRodW1iIHR5cGVkIG9uIG15IExHLDxicj4NClNhc2hhPGJyPg0KPGJy Pg0KLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tPGJyPg0KPGI+RnJvbTombmJzcDs8L2I+ WWFha292IFN0ZWluPGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+MjYvMDUvMjAxNSAwODoxMTxicj4N CjxiPlRvOiZuYnNwOzwvYj48YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRm Lm9yZzwvYT47PGJyPg0KPGI+U3ViamVjdDo8L2I+W21wbHNdIHJldmlldyBvZiBkcmFmdC1taXJz a3ktbXBscy1yZXNpZGVuY2UtdGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Mb2EgYXNrZWQgbWUgdG8gY29tbWVudCBvbiB0aGlzIGRyYWZ0IGJl Zm9yZSBpdHMgYWNjZXB0YW5jZSBhcyBhIE1QTFMgV0cgZHJhZnQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBwdXJwb3NlIG9mIHRoaXMgZHJhZnQg aXMgdG8gcHJvdmlkZSBhIGZvcm0gb2Ygd2hhdCBpcyBjYWxsZWQg4oCcb24tcGF0aCB0aW1pbmcg c3VwcG9ydOKAnSBpbiB0aGUgVElDVE9DIFdHLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgc3BlY2lmaWMga2luZCBvZiBvbi1wYXRoIHN1cHBvcnQgaXMgYWNjdW11 bGF0aW9uIG9mIHJlc2lkZW5jZSB0aW1lcyBpbiBMU1JzIHdoaWNoIGEgdGltZS1zZW5zaXRpdmUg ZmxvdyB0cmF2ZXJzZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBz dWNoIGl0IGlzIGVzc2VudGlhbGx5IHRoZSBzYW1lIGFzIHdoYXQgaXMgY2FsbGVkIOKAnHRyYW5z cGFyZW50IGNsb2NraW5n4oCdIChUQykgaW4gSUVFRSAxNTg4LCBhbmQgdGhlIGRyYWZ0IGluZGVl ZCByZS11c2VzIFRDIHRlY2hub2xvZ2llcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dl dmVyIHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmVtZWR5IGEgcHJvYmxlbSB3aXRoIFRDIGFzIHBy ZXNlbnRseSBpbXBsZW1lbnRlZCDigJMgaXRzIGxheWVyIHZpb2xhdGlvbi4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB2aW9sYXRpb24gb2NjdXJzIHNpbmNlIHBo eXNpY2FsIGxheWVyIHRpbWluZyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIG1vZGlmeSBhIGZpZWxk IG9mIGEgaGlnaGVyIGxheWVyIHByb3RvY29sLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgcHJlc2VudCBkcmFmdCByZW1lZGllcyB0aGlzIGJ5IGZvcmNpbmcgaG9w LWJ5LWhvcCBiZWhhdmlvciBieSBUVEwgZmllbGQgbWFuaXB1bGF0aW9uLA0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgYXQgdGhlIHByaWNlIG9mIGhhdmluZyB0byB0 cmFuc3BvcnQgdGltaW5nIGZsb3dzIGluIHRoZSBhc3NvY2lhdGVkIGNoYW5uZWwsDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByZXZpb3VzbHkgbGltaXRlZCB0byBPQU0g YW5kIGNvbnRyb2wvbWFuYWdlbWVudCBwbGFuZSB1c2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BcyBzdWNoIHRoZSBkcmFmdCBlbGVnYW50bHkgc29sdmVzIGEgdGhlb3JldGljYWwgcHJvYmxl bS4gPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBsZXNzIHN1cmUgdGhhdCBpdCBzb2x2 ZXMgYSByZWFsLXdvcmxkIHByb2JsZW0sIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnMgOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBGaXJzdCBpcyB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEg c2ltcGxlciBhbHRlcm5hdGl2ZSBmb3Igb24tcGF0aCBzdXBwb3J0IG9mIDE1ODggb3ZlciBNUExT IHRoYXQgaGFzIGFscmVhZHkgcGFzc2VkIFdHIExDIGluIFRJQ1RPQy4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGV4aXN0aW5nIFRJQ1RPQyBkcmFmdCB3YXMgcHVy cG9zZWx5IGNvbnN0cmFpbmVkIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KGZvbGxvd2luZyBhZHZpY2Ugb2YgcmV2aWV3ZXJzIHdobyBhcmUgTVBMUyBleHBlcnRzKSA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIG5vdCB0b3VjaCB0aGUgTVBMUyBm b3J3YXJkaW5nIHBsYW5lLCB3aGlsZSB0aGlzIGRyYWZ0IGRlZmluZXMgR0FDaCBUTFZzIGFuZCBz dWItVExWcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByZXNl bnQgZHJhZnQgaXMgYWRtaXR0ZWRseSBtdWNoIHdpZGVyIGluIGFwcGxpY2FiaWxpdHksIGJ1dCBu byB1c2Ugb3RoZXIgdGhhbiAxNTg4IG9uLXBhdGggc3VwcG9ydCBpcyBkZXNjcmliZWQgaW4gdGhl IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBPbmUgY29uY2VpdmFibGUgdXNlIHdv dWxkIGJlIGZvciBoaWdobHkgYWNjdXJhdGUgb25lLXdheSBkZWxheSBlc3RpbWF0aW9uIHdpdGhv dXQgc3luY2hyb25pemVkIGNsb2Nrcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4oYW5kIEkgYW0gbm90IHN1cmUgd2hlbiB0aGlzIHVzZSBpcyByZWFsbHkgbmVlZGVkKS4g PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UgdGhlIHByZXNl bnQgbWV0aG9kIG9ubHkgYWNjb3VudHMgZm9yIHJlc2lkZW5jZSB0aW1lIGluIExTUnMsIG5vdCBm b3IgcHJvcGFnYXRpb24gbGF0ZW5jaWVzIG9uIGxpbmtzICh3aGljaCAxNTg4IGNhbiBoYW5kbGUg YXMgd2VsbCkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBtZXRo b2RvbG9neSB0byBvdmVyY29tZSB0aGlzIGxpbWl0YXRpb24gd291bGQgYXNzdW1hYmx5IGJlIHRv IHJlbHkgb24gYSBjby1yb3V0ZWQgcm91bmQtdHJpcCwgdG8gdXMgdGhpcyBkcmFmdCB0byBjYW5j ZWwgcmVzaWRlbmNlIHRpbWVzLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5hbmQgdGhlbiB0byBtZWFzdXJlIHRoZSByZW1haW5pbmcgcm91bmQtdHJpcCB0aW1lIGFuZCBk aXZpZGUgYnkgdHdvLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dl dmVyLCBleGlzdGluZyBhbGdvcml0aG1zIGRvIGEgcHJldHR5IGdvb2Qgam9iIGF0IGNhbmNlbGxp bmcgcmVzaWRlbmNlIHRpbWVzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmV4Y2VwdCB3aGVuIHRoZSBmbG93IHRyYXZlcnNlcyBhIGxhcmdlIG51bWJlciBvZiBuZXR3b3Jr IGVsZW1lbnRzIHdoaWNoIGFyZSBoZWF2aWx5IGxvYWRlZCB3aXRoIHBsZXNpb2Nocm9ub3VzbHkg cmVsYXRlZCBpbnRlcmZlcmluZyBmbG93cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRvIHRoZSBhdXRob3JzIGhhdmUgYW5vdGhlciB1c2UgY2FzZSBpbiBtaW5kID88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gVGhlIHByaW1hcnkgZG9jdW1lbnRlZCBhcHBsaWNhdGlv biBmb3IgMTU4OCBpbiB0ZWxlY29tIG5ldHdvcmtzIGlzIGNlbGx1bGFyIGJhY2toYXVsLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFwcGxpY2F0aW9uIGFscmVh ZHkgaGFzIGEgcGxldGhvcmEgb2Ygc29sdXRpb25zLCBiYXNlZCBvbiBHUFMsIDE1ODggb3ZlciBF dGhlcm5ldCB3aXRoIGJvdW5kYXJ5IGNsb2NrcyAoQkMpLCBkaXN0cmlidXRlZCBncmFuZCBtYXN0 ZXJzLCBldGMuIGV0Yy4gZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm90ZSB0aGF0IEJDIGFzIHdpZGVseSBkZXBsb3llZCBpcyBhbHJlYWR5IGhvcC1ieS1ob3AsIGFu ZCBpbiB0aGF0IHdheSBzaW1pbGFyIHRvIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JcyB5ZXQgYW5vdGhlciBzb2x1dGlvbiByZWFsbHkgbmVlZGVkID8g PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuIFJlbGF0ZWQgdG8gdGhlIHByZXZpb3VzIHF1ZXN0 aW9ucyBpcyB0aGUgaXNzdWUgb2YgaW1wbGVtZW50YXRpb24gaW4gYWxyZWFkeSBleGlzdGluZyBu ZXR3b3Jrcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzb2x1 dGlvbiByZXF1aXJlcyBoYXJkd2FyZSB1cGdyYWRlcyBhdCBsZWFzdCBmb3IgdGhlIGFjY3VyYXRl IHRpbWUtc3RhbXBpbmcgYW5kIHBvc3NpYmx5IGZvciB0aGUgYWNjdW11bGF0aW9uIGFuZCBmaWVs ZCBtb2RpZmljYXRpb24NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGFs dGhvdWdoIHRoZSBsYXR0ZXIgbWF5IHNvZnR3YXJlIHVwZ3JhZGVzLCBlc3BlY2lhbGx5IGlmIDIt c3RlcCBjb3JyZWN0aW9uIGlzIHV0aWxpemVkKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgd2UgbmVlZCB0byB1cGdyYWRlIGhhcmR3YXJlLCB3aHkgbm90IGRlcGxv eSBCQ3MgPyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgZmV3IHllYXJz IGJhY2sgSSB3b3VsZCBoYXZlIHNhaWQgdGhhdCBUQyBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBt aW5pYXR1cml6ZWQgZGV2aWNlcyB3aGVyZSBCQyBjb3VsZCBub3QsDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBhZHZhbmNlcyBpbiBtaW5pYXR1cml6YXRpb24gb2Yg T0NYT3MgaGF2ZSBzZXZlcmVseSByZWR1Y2VkIHRoaXMgYWR2YW50YWdlIHRvIGNhc2VzIHdoZXJl IGF0b21pYy1jbG9jayBob2xkLW92ZXIgaXMgcmVxdWlyZWQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjUuIElmIGFub3RoZXIgc29sdXRpb24gZm9yIHRoaXMgc3BlY2lmaWMgYXBwbGljYXRpb24g aXMgbmVlZGVkLCBpcyBpdCBuZWVkZWQgZm9yIE1QTFMgPw0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5DZWxsdWxhciBiYWNraGF1bCBvdmVyIGNhcnJpZXIgRXRoZXJuZXQg aXMgd2lkZWx5IGRlcGxveWVkLCBpcyBjZWxsdWxhciBiYWNraGF1bCBvdmVyIE1QTFMgc3VmZmlj aWVudGx5IHdpZGVzcHJlYWQgdG8gbWVyaXQgdGhpcyBleHRlbnNpb24gPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj42LiBNUExTIGRvZXMgbm90IGRlZmluZSBpdHMgb3duIHBoeXNpY2FsIGxheWVy ICh3aGljaCBFdGhlcm5ldCBkb2VzIOKAkyB0aGUgbGF5ZXIgY2FsbGVkIEVUWSBpbiB0aGUgSVRV KS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc3VjaCBpdCBpcyBu b3QgY2xlYXIgdGhhdCBNUExTIGlzIHRoZSByaWdodCBwbGFjZSB0byBzb2x2ZSB0aGUgdGltaW5n IGRpc3RyaWJ1dGlvbiBwcm9ibGVtLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NUExTIG5lY2Vzc2FyaWx5IHJ1bnMgb3ZlciBzb21lIHBoeXNpY2FsIGxheWVyIHdoaWNo IG1heSBhbHJlYWR5IGhhdmUgb24tcGF0aCBzdXBwb3J0LCBvciBtYXkgbW9yZSBlY29ub21pY2Fs bHkgc3VwcG9ydCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIG9mIHRoZSBhdXRob3Jz IHdvcmsgZm9yIHZlbmRvcnMg4oCTIGhhdmUgdGhlc2UgdmVuZG9ycyBpbXBsZW1lbnRlZCB0aGlz IG9yIGRvIHRoZXkgcGxhbiBpbXBsZW1lbnRpbmcgPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JZiB0aGUgYW5zd2VyIGlzIGEgcmVzb3VuZGluZyB5ZXMsIHRoZW4gSSBh c3N1bWUgdGhhdCB3ZSB3aWxsIGhlYXIgcmVidXR0YWxzIHRvIG1vc3Qgb2YgdGhlIGFib3ZlIHJl bWFya3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyB0aGUgY29udGVudCBvZiB0 aGUgZHJhZnQsIEkgaGF2ZSBhIG1ham9yIGlzc3VlIHdpdGggdGhlIHVzZSBvZiB0aGUgdGVybSDi gJxTY3JhdGNoIFBhZOKAnSBmb3IgdGhlIGNvcnJlY3Rpb24gZmllbGQNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGFuZCBCVFcsIGl0IGlzIHNvbWV0aW1lcyBjYWxsZWQg 4oCcU2NyYXRjaCBQYWTigJ0gYW5kIHNvbWV0aW1lcyDigJxTY3JhdGNoUGFk4oCdIGFuZCBzb21l dGltZXMg4oCcc2NyYXRjaCBwYWTigJ0pLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIGZpZWxkIGlzIG5vdCBzb21lIG9wYXF1ZSBtZXRhLWRhdGEgdHJhbnNwb3J0 ZWQgYnkgdGhpcyBuZXdseSBkZWZpbmVkIGhlYWRlciwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+aXQgaXMgdGhlIHZlcnkgY3J1eCBvZiB0aGUgc29sdXRpb24gYW5kIHJl cXVpcmVzIG1hbmlwdWxhdGlvbiB0byB3b3JrLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DYWxsaW5nIGl0IGEg4oCcc2NyYXRjaCBwYWTigJ0gKHdpdGggYW55IG9mIHRo ZSBzcGVsbGluZ3MpIGlzIHRhbnRhbW91bnQgdG8gY2FsbGluZyBhbiBNUExTIGxhYmVsIGFuIOKA nGFyYml0cmFyeSBiaXQtZmllbGTigJ0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJvdGggdGVybXMgbWF5IGJlIHRlY2huaWNhbGx5IGNvcnJlY3QsIGJ1dCBoaWRlIHRo ZSBtZWFuaW5nIG9mIHRoZSBmaWVsZCBhbmQgaW5jcmVhc2UgdGhlIGxvYWQgb24gcmVhZGVyIGlu IHVuZGVyc3RhbmRpbmcgdGhlIHRlY2hub2xvZ3kuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IGFuIGFzaWRlLCB0aGUgYWZvcmVtZW50aW9uZWQgVElDVE9DIFdHIGRyYWZ0IG9yaWdpbmFsbHkg Y29udGFpbmVkIGV4dGVuc2lvbnMgdG8gT1NQRiwgUlNWUC1URSwgZXRjLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd2FzIGRlY2lkZWQgdG8gc2VwYXJhdGUgdGhlIGNv bnRyb2wgZXh0ZW5zaW9ucyBmcm9tIHRoZSBmb3J3YXJkaW5nIHBsYW5lIGRyYWZ0LCBhbmQgdG8g cHVyc3VlIGVhY2ggaW4gdGhlIG1vc3QgYXBwcm9wcmlhdGUgV0cuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0byBkbyB0aGUgc2Ft ZSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgb2YgdGhlIGZhY3RzIG9mIGxpZmUg d2l0aCBvbi1wYXRoIHN1cHBvcnQgb2YgdGltaW5nIGRpc3RyaWJ1dGlvbiBpcyB0aGF0IGl0IGlz IG9mdGVuIG9ubHkgcGFydGlhbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldoYXQgaGFwcGVucyB0byB0aGlzIHNvbHV0aW9uIHdoZW4gdGhlcmUgaXMgb25seSBwYXJ0aWFs IHN1cHBvcnQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIGlt YWdpbmUgdW5yZWNvZ25pemVkIEdBQ2ggcGFja2V0cyBiZWluZyBib290ZWQgdG8gQ1BVIGluIHN1 Y2ggY2FzZXMsIHNldmVyZWx5IGltcGFjdGluZyB1bmNvbXBlbnNhdGVkIHJlc2lkZW5jZSB0aW1l LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZKEopUzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_DB5PR03MB0999E172F50EC022BD742F93E5CA0DB5PR03MB0999eurp_-- From nobody Thu May 28 01:41:32 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8743F1A904E for ; Thu, 28 May 2015 01:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham 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 QJ-PLpGPZgOV for ; Thu, 28 May 2015 01:41:29 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::612]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3991A9045 for ; Thu, 28 May 2015 01:41:28 -0700 (PDT) Received: from DB5PR03MB0999.eurprd03.prod.outlook.com (25.162.154.17) by DB5PR03MB0997.eurprd03.prod.outlook.com (25.162.154.158) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 08:41:11 +0000 Received: from DB5PR03MB0999.eurprd03.prod.outlook.com ([25.162.154.17]) by DB5PR03MB0999.eurprd03.prod.outlook.com ([25.162.154.17]) with mapi id 15.01.0172.012; Thu, 28 May 2015 08:41:11 +0000 From: Yaakov Stein To: "Osborne, Eric" Thread-Topic: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Thread-Index: AQHQhky7CoX4gxzfLUGxZrSN4qgSRZ1vhCDwgB7joQCAAriQcA== Date: Thu, 28 May 2015 08:41:11 +0000 Message-ID: References: <55473BCB.70709@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A30535E@USIDCWVEMBX03.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD1A30535E@USIDCWVEMBX03.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yaakov_s@rad.com; x-originating-ip: [80.74.100.131] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR03MB0997; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DB5PR03MB0997; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB0997; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(2656002)(2900100001)(87936001)(86362001)(62966003)(40100003)(74316001)(106116001)(33656002)(105586002)(77156002)(230783001)(106356001)(68736005)(122556002)(2950100001)(102836002)(97736004)(4001540100001)(110136002)(76176999)(81156007)(5001960100002)(50986999)(46102003)(66066001)(189998001)(64706001)(5001860100001)(5001830100001)(92566002)(76576001)(54356999)(101416001)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB0997; H:DB5PR03MB0999.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rad.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 08:41:11.3636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB0997 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 08:41:31 -0000 > General question: does RTM work over LAGs? They're a flavor of ECMP in s= ome respects. If not, that needs to be spelled out somewhere. > It might be worth spending a few lines in the introduction talking about = who might want to use this and what sort of restrictions it places on a net= work design. All the caveats that were discussed in the context of the TICTOC draft appl= y here as well. In particular, all packets of timing flows must follow the same path, thus = ruling out LAG, ECMP, entropy labels, etc. Protection switching must also be avoided, since undetected delay changes a= re more detrimental than not receiving timing packets and going into holdov= er. Y(J)S From nobody Thu May 28 03:51:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE261A8893 for ; Thu, 28 May 2015 03:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Rx5FIJacCRbn for ; Thu, 28 May 2015 03:51:44 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.100]) (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 456FC1A88AD for ; Thu, 28 May 2015 03:51:44 -0700 (PDT) Received: from [216.82.253.163] by server-4.bemta-7.messagelabs.com id FC/C7-06011-F33F6655; Thu, 28 May 2015 10:51:43 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-3.tower-166.messagelabs.com!1432810303!20116095!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32452 invoked from network); 28 May 2015 10:51:43 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-3.tower-166.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 May 2015 10:51:43 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 3A5851DE7F; Thu, 28 May 2015 10:51:43 +0000 (GMT) Received: from USADCWVEHT03.corp.global.level3.com (10.2.36.143) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 28 May 2015 04:51:42 -0600 Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by usadcwveht03.corp.global.level3.com ([::1]) with mapi id 14.03.0210.002; Thu, 28 May 2015 06:51:42 -0400 From: "Osborne, Eric" To: Yaakov Stein Thread-Topic: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Thread-Index: AQHQhky7J1BgNHb+6kGzNmhgHoqlC51vhCDwgB7f3NCAAzgYgP//vzOg Date: Thu, 28 May 2015 10:51:40 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD1A30B724@USIDCWVEMBX03.corp.global.level3.com> References: <55473BCB.70709@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A30535E@USIDCWVEMBX03.corp.global.level3.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.141.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 10:51:45 -0000 Inline ... > > It might be worth spending a few lines in the introduction talking abou= t > who might want to use this and what sort of restrictions it places on a > network design. >=20 > All the caveats that were discussed in the context of the TICTOC draft ap= ply > here as well. >=20 > In particular, all packets of timing flows must follow the same path, thu= s > ruling out LAG, ECMP, entropy labels, etc. > Protection switching must also be avoided, since undetected delay changes > are more detrimental than not receiving timing packets and going into > holdover. Guh. I remember being in the room for some of this stuff. This essentiall= y boils down to TE LSPs specifically for timing. This sort of stuff needs = to be spelled out very particularly, since these sorts of things aren't obv= ious to everyone who might consider the technology. It doesn't have to be = much, but IMO this draft needs "here's how to design your network around th= is protocol". eric From nobody Thu May 28 03:58:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB32C1A88D2 for ; Thu, 28 May 2015 03:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ZRBE00bfMQD4 for ; Thu, 28 May 2015 03:58:42 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280631A88F3 for ; Thu, 28 May 2015 03:58:42 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (25.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 10:18:42 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0172.012; Thu, 28 May 2015 10:18:42 +0000 From: Alexander Vainshtein To: Yaakov Stein , "Osborne, Eric" Thread-Topic: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt Thread-Index: AQHQmS+riFY6dTVf4UyJnALXilqIsA== Date: Thu, 28 May 2015 10:18:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Infraware POLARIS Mobile Mailer v2.5 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [109.253.145.242] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(479174004)(199003)(33656002)(81156007)(76576001)(5001770100001)(50986999)(106356001)(102836002)(5001960100002)(101416001)(92566002)(2900100001)(15975445007)(122556002)(68736005)(105586002)(40100003)(19625215002)(2656002)(4001540100001)(62966003)(77156002)(97736004)(189998001)(19617315012)(19580405001)(106116001)(86362001)(66066001)(46102003)(64706001)(74316001)(16236675004)(230783001)(87936001)(19580395003)(5001860100001)(5002640100001)(5001830100001)(50226001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DB3PR03MB07801776CA5795DF981615D59DCA0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 10:18:42.2953 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 10:58:45 -0000 --_000_DB3PR03MB07801776CA5795DF981615D59DCA0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFha292IGFuZCBhbGwsDQoNClRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcgYWxsIFJU TSBwYWNrZXRzIHdpbGwgY3Jvc3MgdGhlIHNhbWUgbGluayBpbiBMQUcgdGhhdCB1c2VzIGFueSAi bm9ybWFsIiBoYXNoaW5nIG1lY2hhbmlzbSBmb3IgbGFiZWxlZCBwYWNrZXRzLg0KDQoNCg0KVGhp cyBpcyBiZWNhdXNlIHRoZXNlIHBhY2tldHMgd2lsbCBuZXZlciBiZSBtaXNpbnRlcnByZXRlZCBh cyBJUCBwYWNrZXRzIChkdWUgdG8gR0FDaCBoZWFkZXIpIGFuZCB3aWxsIHVzZSB0aGUgc2FtZSBs YWJlbCBzdGFjay4NCg0KDQoNCk1heWJlIHdlIHNob3VsZCBhZGQgdGhlIGNvcnJlc29vbmRpbmcg Y2xhcmlmaWNhdGlvbiB0byB0aGUgZHJhZnQuDQoNCg0KDQpUaHVtYiB0eXBlZCBvbiBteSBMRywN ClNhc2hhDQoNCi0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLQ0KRnJvbTogWWFha292IFN0 ZWluDQpEYXRlOiAyOC8wNS8yMDE1IDExOjQxDQpUbzogT3Nib3JuZSwgRXJpYzsNCkNjOiBtcGxz QGlldGYub3JnOw0KU3ViamVjdDpSZTogW21wbHNdIE1QTFNfUlQgcmV2aWV3IG9mIGRyYWZ0LW1p cnNreS1tcGxzLXJlc2lkZW5jZS10aW1lLTA2LnR4dA0KDQo+IEdlbmVyYWwgcXVlc3Rpb246IGRv ZXMgUlRNIHdvcmsgb3ZlciBMQUdzPyAgVGhleSdyZSBhIGZsYXZvciBvZiBFQ01QIGluIHNvbWUg cmVzcGVjdHMuICBJZiBub3QsIHRoYXQgbmVlZHMgdG8gYmUgc3BlbGxlZCBvdXQgc29tZXdoZXJl Lg0KDQo+IEl0IG1pZ2h0IGJlIHdvcnRoIHNwZW5kaW5nIGEgZmV3IGxpbmVzIGluIHRoZSBpbnRy b2R1Y3Rpb24gdGFsa2luZyBhYm91dCB3aG8gbWlnaHQgd2FudCB0byB1c2UgdGhpcyBhbmQgd2hh dCBzb3J0IG9mIHJlc3RyaWN0aW9ucyBpdCBwbGFjZXMgb24gYSBuZXR3b3JrIGRlc2lnbi4NCg0K QWxsIHRoZSBjYXZlYXRzIHRoYXQgd2VyZSBkaXNjdXNzZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhl IFRJQ1RPQyBkcmFmdCBhcHBseSBoZXJlIGFzIHdlbGwuDQoNCkluIHBhcnRpY3VsYXIsIGFsbCBw YWNrZXRzIG9mIHRpbWluZyBmbG93cyBtdXN0IGZvbGxvdyB0aGUgc2FtZSBwYXRoLCB0aHVzIHJ1 bGluZyBvdXQgTEFHLCBFQ01QLCBlbnRyb3B5IGxhYmVscywgZXRjLg0KUHJvdGVjdGlvbiBzd2l0 Y2hpbmcgbXVzdCBhbHNvIGJlIGF2b2lkZWQsIHNpbmNlIHVuZGV0ZWN0ZWQgZGVsYXkgY2hhbmdl cyBhcmUgbW9yZSBkZXRyaW1lbnRhbCB0aGFuIG5vdCByZWNlaXZpbmcgdGltaW5nIHBhY2tldHMg YW5kIGdvaW5nIGludG8gaG9sZG92ZXIuDQoNClkoSilTDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= --_000_DB3PR03MB07801776CA5795DF981615D59DCA0DB3PR03MB0780eurp_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8c3R5bGU+PCEtLSAuRW1haWxRdW90ZSB7 IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3JkZXItbGVmdDogIzgwMDAw MCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206 MDsiPllhYWtvdiBhbmQgYWxsLDwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJv dHRvbTowOyI+VG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZyBhbGwgUlRNIHBhY2tldHMg d2lsbCBjcm9zcyB0aGUgc2FtZSBsaW5rIGluIExBRyB0aGF0IHVzZXMgYW55ICZxdW90O25vcm1h bCZxdW90OyBoYXNoaW5nIG1lY2hhbmlzbSBmb3IgbGFiZWxlZCBwYWNrZXRzLjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij5UaGlzIGlzIGJlY2F1c2UgdGhlc2UgcGFj a2V0cyB3aWxsIG5ldmVyIGJlIG1pc2ludGVycHJldGVkIGFzIElQIHBhY2tldHMgKGR1ZSB0byBH QUNoIGhlYWRlcikgYW5kIHdpbGwgdXNlIHRoZSBzYW1lIGxhYmVsIHN0YWNrLjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij5NYXliZSB3ZSBzaG91bGQgYWRkIHRoZSBj b3JyZXNvb25kaW5nIGNsYXJpZmljYXRpb24gdG8gdGhlIGRyYWZ0LjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+Jm5ic3A7PC9wPg0KPGRldjNfamp5PlRodW1i IHR5cGVkIG9uIG15IExHLDxicj4NClNhc2hhPC9kZXYzX2pqeT48YnI+DQo8YnI+DQotLS0tLS0g T3JpZ2luYWwgbWVzc2FnZSAtLS0tLS08YnI+DQo8Yj5Gcm9tOiZuYnNwOzwvYj5ZYWFrb3YgU3Rl aW48eWFha292X3NAcmFkLmNvbT48YnI+DQo8Yj5EYXRlOiZuYnNwOzwvYj4yOC8wNS8yMDE1IDEx OjQxPGJyPg0KPGI+VG86Jm5ic3A7PC9iPk9zYm9ybmUsIEVyaWM7PGJyPg0KPGI+Q2M6Jm5ic3A7 PC9iPm1wbHNAaWV0Zi5vcmc7PGJyPg0KPGI+U3ViamVjdDo8L2I+UmU6IFttcGxzXSBNUExTX1JU IHJldmlldyBvZiBkcmFmdC1taXJza3ktbXBscy1yZXNpZGVuY2UtdGltZS0wNi50eHQ8YnI+DQo8 YnI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQgLS0+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPiZndDsgR2VuZXJh bCBxdWVzdGlvbjogZG9lcyBSVE0gd29yayBvdmVyIExBR3M/ICZuYnNwO1RoZXkncmUgYSBmbGF2 b3Igb2YgRUNNUCBpbiBzb21lIHJlc3BlY3RzLiAmbmJzcDtJZiBub3QsIHRoYXQgbmVlZHMgdG8g YmUgc3BlbGxlZCBvdXQgc29tZXdoZXJlLjxicj4NCjxicj4NCiZndDsgSXQgbWlnaHQgYmUgd29y dGggc3BlbmRpbmcgYSBmZXcgbGluZXMgaW4gdGhlIGludHJvZHVjdGlvbiB0YWxraW5nIGFib3V0 IHdobyBtaWdodCB3YW50IHRvIHVzZSB0aGlzIGFuZCB3aGF0IHNvcnQgb2YgcmVzdHJpY3Rpb25z IGl0IHBsYWNlcyBvbiBhIG5ldHdvcmsgZGVzaWduLjxicj4NCjxicj4NCkFsbCB0aGUgY2F2ZWF0 cyB0aGF0IHdlcmUgZGlzY3Vzc2VkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBUSUNUT0MgZHJhZnQg YXBwbHkgaGVyZSBhcyB3ZWxsLjxicj4NCjxicj4NCkluIHBhcnRpY3VsYXIsIGFsbCBwYWNrZXRz IG9mIHRpbWluZyBmbG93cyBtdXN0IGZvbGxvdyB0aGUgc2FtZSBwYXRoLCB0aHVzIHJ1bGluZyBv dXQgTEFHLCBFQ01QLCBlbnRyb3B5IGxhYmVscywgZXRjLjxicj4NClByb3RlY3Rpb24gc3dpdGNo aW5nIG11c3QgYWxzbyBiZSBhdm9pZGVkLCBzaW5jZSB1bmRldGVjdGVkIGRlbGF5IGNoYW5nZXMg YXJlIG1vcmUgZGV0cmltZW50YWwgdGhhbiBub3QgcmVjZWl2aW5nIHRpbWluZyBwYWNrZXRzIGFu ZCBnb2luZyBpbnRvIGhvbGRvdmVyLjxicj4NCjxicj4NClkoSilTPGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxp bmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX0JMQU5LIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9m b250Pjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB3PR03MB07801776CA5795DF981615D59DCA0DB3PR03MB0780eurp_-- From nobody Thu May 28 04:28:08 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E651A8ABB for ; Thu, 28 May 2015 04:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 X6d9Rg8KRZg4 for ; Thu, 28 May 2015 04:28:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20591A8AB3 for ; Thu, 28 May 2015 04:27:58 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (25.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 11:21:24 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0172.012; Thu, 28 May 2015 11:21:23 +0000 From: Alexander Vainshtein To: Yaakov Stein , "mpls@ietf.org" Thread-Topic: [mpls] review of draft-mirsky-mpls-residence-time Thread-Index: AQHQmThtpYbslVqzzkqNvhquyBxTfA== Date: Thu, 28 May 2015 11:21:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Infraware POLARIS Mobile Mailer v2.5 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [109.253.145.242] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(51694002)(37854004)(189002)(479174004)(2501003)(76576001)(40100003)(106356001)(87936001)(230783001)(16236675004)(77156002)(62966003)(5001830100001)(33656002)(5001770100001)(4001540100001)(2900100001)(19625215002)(81156007)(5001860100001)(189998001)(106116001)(2656002)(86362001)(122556002)(92566002)(107886002)(5002640100001)(97736004)(5001960100002)(102836002)(105586002)(50986999)(68736005)(46102003)(101416001)(66066001)(74316001)(64706001)(50226001)(19580405001)(19580395003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DB3PR03MB078027B62C3C7BC5435B08879DCA0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 11:21:22.9674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777 Archived-At: Subject: Re: [mpls] review of draft-mirsky-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 11:28:05 -0000 --_000_DB3PR03MB078027B62C3C7BC5435B08879DCA0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFha292LA0KDQpMb3RzIG9mIHRoYW5rcyBmb3IgYSBwcm9tcHQgcmVzcG9uc2UuDQoNCg0KDQpQ bGVhc2Ugc2VlIGlubGluZSBiZWxvdy4NCg0KDQoNClRodW1iIHR5cGVkIG9uIG15IExHLA0KU2Fz aGENCg0KLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tDQpGcm9tOiBZYWFrb3YgU3RlaW4N CkRhdGU6IDI4LzA1LzIwMTUgMTA6MTUNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjttcGxzQGll dGYub3JnOw0KU3ViamVjdDpSRTogW21wbHNdIHJldmlldyBvZiBkcmFmdC1taXJza3ktbXBscy1y ZXNpZGVuY2UtdGltZQ0KDQpTYXNoYQ0KDQpJIGhvcGUgdGhhdCB5b3UgYXJlIGZlZWxpbmcgYmV0 dGVyLg0KW1tTYXNoYV1dIE5vdCB5ZXQuDQoxLiBJIGFtIGxvb2tpbmcgYXQgdmVyc2lvbiA2IG9m IHRoaXMgZHJhZnQsIHdoaWNoIG9uIHBhZ2UgNSBzaG93cyB0aGUgU2NyYXRjaCBQYWQgZm9sbG93 ZWQgYnkgVHlwZSwgTGVuZ3RoLCBWYWx1ZQ0KYW5kIGV4cGxhaW5zIDoNClRoZSBUeXBlIGZpZWxk IGlkZW50aWZpZXMgdGhlIHR5cGUgb2YgVmFsdWUgdGhhdCB0aGUgVExWIGNhcnJpZXMuDQogIElB TkEgd2lsbCBiZSBhc2tlZCB0byBjcmVhdGUgYSBzdWItcmVnaXN0cnkgaW4gR2VuZXJpYyBBc3Nv Y2lhdGVkDQpDaGFubmVsIChHLUFDaCkgUGFyYW1ldGVycyBSZWdpc3RyeSBjYWxsZWQgIk1QTFMg UlRNIFRMVg0KUmVnaXN0cnkiLg0KW1tTYXNoYV1dIFRoaXMgaXMgbm90IHdoYXQgaGFzIGJlZW4g ZGVmaW5lZCBhcyBhICJHQUNoIFRMVl1dIGluIFJGQyA1NTg2IGFuZCB0aGVuIGRlcHJlY2F0ZWQu DQoNCjIuIEkgYWdyZWUgdGhhdCBhIGxlZ2FjeSBkZXZpY2Ugd2lsbCBub3QgaW5zcGVjdCB5b3Vy IHN0cnVjdHVyZS4NCkkgd2FzIGp1c3QgcXVlc3Rpb25pbmcgaXRzIGhhbmRsaW5nIG9mIEdBQ2gg cGFja2V0cywgd2hldGhlciBvciBub3QgVFRMIGhhcyBleHBpcmVkLg0KW1tTYXNoYV1dIEEgbGVn YWN5IGRldmljZSB0aGF0IGlzIGNvbXBsaWFudCB3aXRoIFJGQyAzMDMxIHdpbGwgbmV2ZXIgaWRl bnRpZnkgdGhlIHBhY2tldCBhcyBhIEdBQ2ggb25lIGJlY2F1c2UgaXQgd2lsbCBuZXZlciBpbnNw ZWN0IHRoZSBsYWJybCBzdGFjayBlbnRyeSB0aGF0IGNvbnRhaW5zIEdBTC4NCg0KMy4gQXMgeW91 IHdpbGwgcmVtZW1iZXIsIHdoYXQgeW91IGNhbGwgbW9kaWZpY2F0aW9uIG9mIHRoZSBNUExTIGRh dGEgcGxhbmUgYnkgdGhlIFRJQ1RPQyBkcmFmdA0Kd2FzIHByZWNpc2VseSB3aGF0IHdlIHdlcmUg aW5zdHJ1Y3RlZCBieSB0aGUgTVBMUyBXRyByZXZpZXdlcnMuDQpPdXIgb3JpZ2luYWwgaW5jbGlu YXRpb24gd2FzIHRvIHJlcXVlc3QgYSByZXNlcnZlZCBsYWJlbCBmb3IgdGltaW5nIHBhY2tldHMu DQpUaGUgVElDVE9DIGRyYWZ0IGRvZXMgbm90IGRlZmluZSBhbnkgbmV3IEZPUldBUkRJTkcgYmVo YXZpb3IsDQppdCBkb2VzIHJlcXVpcmUgc3RhbmRhcmQgMTU4OCBmaWVsZCBtb2RpZmljYXRpb24u DQpUaGlzIGlzIHByZWNpc2VseSB0aGUgc2FtZSBsYXllciB2aW9sYXRpb24gYXMgMTU4OCBUQyBt YW5kYXRlcyBmb3IgYWxsIGl0cyB0cmFuc3BvcnQgbGF5ZXJzLA0KRXRoZXJuZXQsIElEUC9JUHY0 LCBJRFAvSVB2NiwgRGV2aWNlTkVULCBDb250cm9sTkVULCBQUk9GSU5FVCwg4oCmDQpbW1Nhc2hh XV0gIFRoaXMgZHJhZnQgcmVwcmVzZW50cyBhbiBhdHRlbXAgdG8gYnlwYXNzIHRoaXMgbGF5ZXIg dmlvbGF0aW9uIGZvciBNUExTLiBGcm9tIG15IFBPViB0aGlzIGlzIGl0cyBtYWluIGFkZGVkIHZh bHVlLg0KDQpZKEopUw0KDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KU2VudDogMjYvMDUvMjAxNSAwOTowNg0KVG86 IFlhYWtvdiBTdGVpbjsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSByZXZpZXcg b2YgZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRlbmNlLXRpbWUNCg0KDQpZYWFrb3YsDQoNCkxvdHMg b2YgdGhhbmtzIGZvciBhIHZlcnkgZGV0YWlsZWQgcmV2aWV3Lg0KDQpJIGRlZmVyIHRvIG90aGVy IGNvLWF1dGhvcnMgdG8gZGVzY3JpYmUgdGhlIHJlbGV2YW50IHVzZSBjYXNlcyBpbiBtb3JlIGRl dGFpbC4NCg0KDQoNCkkganVzdCB3YW50ZWQgdG8gY29tbWVudCBvbiB0d28gcG9pbnRzOg0KDQox LiBUaGUgZHJhZnQgZG9lcyBub3QgdXNlIEdBQ2ggVExWcyAodGhhdCBoYXZlIGJlZW4gZGVwcmVj YXRlZCBCVFcpLg0KDQoyLiBBIGxlZ2FjeSBkZXZpY2UgdGhhdCBkb2VzIG5vdCBoYXZlIFJUTSBj YXBhYmlsaXRpZXMgd2lsbCBuZXZlciBpbnNwZWN0IHRoZSBHQUwvR0FDaCBjb25zdHJ1Y3QgdXNl ZCBpbiB0aGUgZHJhZnQsIGJlY2F1c2Ugc3VjaCBpbnNwZWN0aW9uIGNhbiBvbmx5IGhhcHBlbiBl aXRoZXIgYXQgdGhlIExTUCB0YWlsLWVuZCBub2RlIG9yIGF0IGFuIFJUTS0gY2FwYWJsZSBub2Rl IHRoYXQgdHJhcHMgdGhlIFJUTSBwYWNrZXQgZHVlIHRvIFRUTCBleHBpcmF0aW9uLg0KDQpUaGlz IGxhc3QgcG9pbnQgaXMgSU1ITyBhIG1ham9yIGRpZmZlcmVudGlhdG9yIGJldHdlZW4gdGhpcyBk cmFmdCBhbmQgb25lIGhhbmRsZWQgYnkgdGhlIFRJQ1RPQyBXRzoNCg0KLSB0aGlzIGRyYWZ0IGRv ZXMgbm90IGNoYW5nZSB0aGUgTVBMUyBEUCBhcyBkZWZpbmVkIGluIFJGQyAzMDMxIGFuZCBSRkMg MzQ0Mw0KDQotIHRoZSBUSUNUT0MgZHJhZnQgKGF0IGxlYXN0IHRvIHRoZSBiZXN0IG9mIG15IHJl Y29sbGVjdGlvbikgYXNzaWduZWQgc3BlY2lhbCBoYW5kbGluZyB0byBsYWJlbHMgdXNlZCBieSB0 aGUgTFNQcyBjYXJyeWluZyBQVFAgcGFja2V0cyB0aGF0IHdhcyBub3QgZGVmaW5lZCBhcyBhICJs YWJlbCBhY3Rpb24iIGluIFJGQyAzMDMxIChuZWl0aGVyIFBvcCwgbm9yIFN3YXAgbm9yIFB1c2gp Lg0KDQoNCg0KUmVnYXJkcywNCg0KU2FzaGENCg0KDQoNCg0KVGh1bWIgdHlwZWQgb24gbXkgTEcs DQpTYXNoYQ0KDQotLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0NCkZyb206IFlhYWtvdiBT dGVpbg0KRGF0ZTogMjYvMDUvMjAxNSAwODoxMQ0KVG86IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+Ow0KU3ViamVjdDpbbXBsc10gcmV2aWV3IG9mIGRyYWZ0LW1pcnNreS1tcGxz LXJlc2lkZW5jZS10aW1lDQpMb2EgYXNrZWQgbWUgdG8gY29tbWVudCBvbiB0aGlzIGRyYWZ0IGJl Zm9yZSBpdHMgYWNjZXB0YW5jZSBhcyBhIE1QTFMgV0cgZHJhZnQuDQoNCkFzIGZhciBhcyBJIHVu ZGVyc3RhbmQsIHRoZSBwdXJwb3NlIG9mIHRoaXMgZHJhZnQgaXMgdG8gcHJvdmlkZSBhIGZvcm0g b2Ygd2hhdCBpcyBjYWxsZWQg4oCcb24tcGF0aCB0aW1pbmcgc3VwcG9ydOKAnSBpbiB0aGUgVElD VE9DIFdHLg0KVGhlIHNwZWNpZmljIGtpbmQgb2Ygb24tcGF0aCBzdXBwb3J0IGlzIGFjY3VtdWxh dGlvbiBvZiByZXNpZGVuY2UgdGltZXMgaW4gTFNScyB3aGljaCBhIHRpbWUtc2Vuc2l0aXZlIGZs b3cgdHJhdmVyc2VzLg0KQXMgc3VjaCBpdCBpcyBlc3NlbnRpYWxseSB0aGUgc2FtZSBhcyB3aGF0 IGlzIGNhbGxlZCDigJx0cmFuc3BhcmVudCBjbG9ja2luZ+KAnSAoVEMpIGluIElFRUUgMTU4OCwg YW5kIHRoZSBkcmFmdCBpbmRlZWQgcmUtdXNlcyBUQyB0ZWNobm9sb2dpZXMuDQoNCkhvd2V2ZXIg dGhpcyBkcmFmdCBhdHRlbXB0cyB0byByZW1lZHkgYSBwcm9ibGVtIHdpdGggVEMgYXMgcHJlc2Vu dGx5IGltcGxlbWVudGVkIOKAkyBpdHMgbGF5ZXIgdmlvbGF0aW9uLg0KVGhpcyB2aW9sYXRpb24g b2NjdXJzIHNpbmNlIHBoeXNpY2FsIGxheWVyIHRpbWluZyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRv IG1vZGlmeSBhIGZpZWxkIG9mIGEgaGlnaGVyIGxheWVyIHByb3RvY29sLg0KVGhlIHByZXNlbnQg ZHJhZnQgcmVtZWRpZXMgdGhpcyBieSBmb3JjaW5nIGhvcC1ieS1ob3AgYmVoYXZpb3IgYnkgVFRM IGZpZWxkIG1hbmlwdWxhdGlvbiwNCmJ1dCBhdCB0aGUgcHJpY2Ugb2YgaGF2aW5nIHRvIHRyYW5z cG9ydCB0aW1pbmcgZmxvd3MgaW4gdGhlIGFzc29jaWF0ZWQgY2hhbm5lbCwNCnByZXZpb3VzbHkg bGltaXRlZCB0byBPQU0gYW5kIGNvbnRyb2wvbWFuYWdlbWVudCBwbGFuZSB1c2VzLg0KDQpBcyBz dWNoIHRoZSBkcmFmdCBlbGVnYW50bHkgc29sdmVzIGEgdGhlb3JldGljYWwgcHJvYmxlbS4NCg0K SSBhbSBsZXNzIHN1cmUgdGhhdCBpdCBzb2x2ZXMgYSByZWFsLXdvcmxkIHByb2JsZW0sIGZvciB0 aGUgZm9sbG93aW5nIHJlYXNvbnMgOg0KDQoxLiBGaXJzdCBpcyB0aGUgZmFjdCB0aGF0IHRoZXJl IGlzIGEgc2ltcGxlciBhbHRlcm5hdGl2ZSBmb3Igb24tcGF0aCBzdXBwb3J0IG9mIDE1ODggb3Zl ciBNUExTIHRoYXQgaGFzIGFscmVhZHkgcGFzc2VkIFdHIExDIGluIFRJQ1RPQy4NClRoZSBleGlz dGluZyBUSUNUT0MgZHJhZnQgd2FzIHB1cnBvc2VseSBjb25zdHJhaW5lZA0KKGZvbGxvd2luZyBh ZHZpY2Ugb2YgcmV2aWV3ZXJzIHdobyBhcmUgTVBMUyBleHBlcnRzKQ0KdG8gbm90IHRvdWNoIHRo ZSBNUExTIGZvcndhcmRpbmcgcGxhbmUsIHdoaWxlIHRoaXMgZHJhZnQgZGVmaW5lcyBHQUNoIFRM VnMgYW5kIHN1Yi1UTFZzLg0KVGhlIHByZXNlbnQgZHJhZnQgaXMgYWRtaXR0ZWRseSBtdWNoIHdp ZGVyIGluIGFwcGxpY2FiaWxpdHksIGJ1dCBubyB1c2Ugb3RoZXIgdGhhbiAxNTg4IG9uLXBhdGgg c3VwcG9ydCBpcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0Lg0KDQoyLiBPbmUgY29uY2VpdmFibGUg dXNlIHdvdWxkIGJlIGZvciBoaWdobHkgYWNjdXJhdGUgb25lLXdheSBkZWxheSBlc3RpbWF0aW9u IHdpdGhvdXQgc3luY2hyb25pemVkIGNsb2Nrcw0KKGFuZCBJIGFtIG5vdCBzdXJlIHdoZW4gdGhp cyB1c2UgaXMgcmVhbGx5IG5lZWRlZCkuDQpPZiBjb3Vyc2UgdGhlIHByZXNlbnQgbWV0aG9kIG9u bHkgYWNjb3VudHMgZm9yIHJlc2lkZW5jZSB0aW1lIGluIExTUnMsIG5vdCBmb3IgcHJvcGFnYXRp b24gbGF0ZW5jaWVzIG9uIGxpbmtzICh3aGljaCAxNTg4IGNhbiBoYW5kbGUgYXMgd2VsbCkuDQpU aGUgbWV0aG9kb2xvZ3kgdG8gb3ZlcmNvbWUgdGhpcyBsaW1pdGF0aW9uIHdvdWxkIGFzc3VtYWJs eSBiZSB0byByZWx5IG9uIGEgY28tcm91dGVkIHJvdW5kLXRyaXAsIHRvIHVzIHRoaXMgZHJhZnQg dG8gY2FuY2VsIHJlc2lkZW5jZSB0aW1lcywNCmFuZCB0aGVuIHRvIG1lYXN1cmUgdGhlIHJlbWFp bmluZyByb3VuZC10cmlwIHRpbWUgYW5kIGRpdmlkZSBieSB0d28uDQpIb3dldmVyLCBleGlzdGlu ZyBhbGdvcml0aG1zIGRvIGEgcHJldHR5IGdvb2Qgam9iIGF0IGNhbmNlbGxpbmcgcmVzaWRlbmNl IHRpbWVzDQpleGNlcHQgd2hlbiB0aGUgZmxvdyB0cmF2ZXJzZXMgYSBsYXJnZSBudW1iZXIgb2Yg bmV0d29yayBlbGVtZW50cyB3aGljaCBhcmUgaGVhdmlseSBsb2FkZWQgd2l0aCBwbGVzaW9jaHJv bm91c2x5IHJlbGF0ZWQgaW50ZXJmZXJpbmcgZmxvd3MuDQpEbyB0aGUgYXV0aG9ycyBoYXZlIGFu b3RoZXIgdXNlIGNhc2UgaW4gbWluZCA/DQoNCjMuIFRoZSBwcmltYXJ5IGRvY3VtZW50ZWQgYXBw bGljYXRpb24gZm9yIDE1ODggaW4gdGVsZWNvbSBuZXR3b3JrcyBpcyBjZWxsdWxhciBiYWNraGF1 bC4NClRoaXMgYXBwbGljYXRpb24gYWxyZWFkeSBoYXMgYSBwbGV0aG9yYSBvZiBzb2x1dGlvbnMs IGJhc2VkIG9uIEdQUywgMTU4OCBvdmVyIEV0aGVybmV0IHdpdGggYm91bmRhcnkgY2xvY2tzIChC QyksIGRpc3RyaWJ1dGVkIGdyYW5kIG1hc3RlcnMsIGV0Yy4gZXRjLiBldGMuDQpOb3RlIHRoYXQg QkMgYXMgd2lkZWx5IGRlcGxveWVkIGlzIGFscmVhZHkgaG9wLWJ5LWhvcCwgYW5kIGluIHRoYXQg d2F5IHNpbWlsYXIgdG8gdGhpcyBkcmFmdC4NCklzIHlldCBhbm90aGVyIHNvbHV0aW9uIHJlYWxs eSBuZWVkZWQgPw0KDQo0LiBSZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBxdWVzdGlvbnMgaXMgdGhl IGlzc3VlIG9mIGltcGxlbWVudGF0aW9uIGluIGFscmVhZHkgZXhpc3RpbmcgbmV0d29ya3MuDQpU aGlzIHNvbHV0aW9uIHJlcXVpcmVzIGhhcmR3YXJlIHVwZ3JhZGVzIGF0IGxlYXN0IGZvciB0aGUg YWNjdXJhdGUgdGltZS1zdGFtcGluZyBhbmQgcG9zc2libHkgZm9yIHRoZSBhY2N1bXVsYXRpb24g YW5kIGZpZWxkIG1vZGlmaWNhdGlvbg0KKGFsdGhvdWdoIHRoZSBsYXR0ZXIgbWF5IHNvZnR3YXJl IHVwZ3JhZGVzLCBlc3BlY2lhbGx5IGlmIDItc3RlcCBjb3JyZWN0aW9uIGlzIHV0aWxpemVkKS4N CklmIHdlIG5lZWQgdG8gdXBncmFkZSBoYXJkd2FyZSwgd2h5IG5vdCBkZXBsb3kgQkNzID8NCkEg ZmV3IHllYXJzIGJhY2sgSSB3b3VsZCBoYXZlIHNhaWQgdGhhdCBUQyBjb3VsZCBiZSBpbXBsZW1l bnRlZCBpbiBtaW5pYXR1cml6ZWQgZGV2aWNlcyB3aGVyZSBCQyBjb3VsZCBub3QsDQpidXQgYWR2 YW5jZXMgaW4gbWluaWF0dXJpemF0aW9uIG9mIE9DWE9zIGhhdmUgc2V2ZXJlbHkgcmVkdWNlZCB0 aGlzIGFkdmFudGFnZSB0byBjYXNlcyB3aGVyZSBhdG9taWMtY2xvY2sgaG9sZC1vdmVyIGlzIHJl cXVpcmVkLg0KDQo1LiBJZiBhbm90aGVyIHNvbHV0aW9uIGZvciB0aGlzIHNwZWNpZmljIGFwcGxp Y2F0aW9uIGlzIG5lZWRlZCwgaXMgaXQgbmVlZGVkIGZvciBNUExTID8NCkNlbGx1bGFyIGJhY2to YXVsIG92ZXIgY2FycmllciBFdGhlcm5ldCBpcyB3aWRlbHkgZGVwbG95ZWQsIGlzIGNlbGx1bGFy IGJhY2toYXVsIG92ZXIgTVBMUyBzdWZmaWNpZW50bHkgd2lkZXNwcmVhZCB0byBtZXJpdCB0aGlz IGV4dGVuc2lvbiA/DQoNCjYuIE1QTFMgZG9lcyBub3QgZGVmaW5lIGl0cyBvd24gcGh5c2ljYWwg bGF5ZXIgKHdoaWNoIEV0aGVybmV0IGRvZXMg4oCTIHRoZSBsYXllciBjYWxsZWQgRVRZIGluIHRo ZSBJVFUpLg0KQXMgc3VjaCBpdCBpcyBub3QgY2xlYXIgdGhhdCBNUExTIGlzIHRoZSByaWdodCBw bGFjZSB0byBzb2x2ZSB0aGUgdGltaW5nIGRpc3RyaWJ1dGlvbiBwcm9ibGVtLg0KTVBMUyBuZWNl c3NhcmlseSBydW5zIG92ZXIgc29tZSBwaHlzaWNhbCBsYXllciB3aGljaCBtYXkgYWxyZWFkeSBo YXZlIG9uLXBhdGggc3VwcG9ydCwgb3IgbWF5IG1vcmUgZWNvbm9taWNhbGx5IHN1cHBvcnQgaXQu DQoNCkFsbCBvZiB0aGUgYXV0aG9ycyB3b3JrIGZvciB2ZW5kb3JzIOKAkyBoYXZlIHRoZXNlIHZl bmRvcnMgaW1wbGVtZW50ZWQgdGhpcyBvciBkbyB0aGV5IHBsYW4gaW1wbGVtZW50aW5nID8NCklm IHRoZSBhbnN3ZXIgaXMgYSByZXNvdW5kaW5nIHllcywgdGhlbiBJIGFzc3VtZSB0aGF0IHdlIHdp bGwgaGVhciByZWJ1dHRhbHMgdG8gbW9zdCBvZiB0aGUgYWJvdmUgcmVtYXJrcy4NCg0KUmVnYXJk aW5nIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCwgSSBoYXZlIGEgbWFqb3IgaXNzdWUgd2l0aCB0 aGUgdXNlIG9mIHRoZSB0ZXJtIOKAnFNjcmF0Y2ggUGFk4oCdIGZvciB0aGUgY29ycmVjdGlvbiBm aWVsZA0KKGFuZCBCVFcsIGl0IGlzIHNvbWV0aW1lcyBjYWxsZWQg4oCcU2NyYXRjaCBQYWTigJ0g YW5kIHNvbWV0aW1lcyDigJxTY3JhdGNoUGFk4oCdIGFuZCBzb21ldGltZXMg4oCcc2NyYXRjaCBw YWTigJ0pLg0KVGhpcyBmaWVsZCBpcyBub3Qgc29tZSBvcGFxdWUgbWV0YS1kYXRhIHRyYW5zcG9y dGVkIGJ5IHRoaXMgbmV3bHkgZGVmaW5lZCBoZWFkZXIsDQppdCBpcyB0aGUgdmVyeSBjcnV4IG9m IHRoZSBzb2x1dGlvbiBhbmQgcmVxdWlyZXMgbWFuaXB1bGF0aW9uIHRvIHdvcmsuDQpDYWxsaW5n IGl0IGEg4oCcc2NyYXRjaCBwYWTigJ0gKHdpdGggYW55IG9mIHRoZSBzcGVsbGluZ3MpIGlzIHRh bnRhbW91bnQgdG8gY2FsbGluZyBhbiBNUExTIGxhYmVsIGFuIOKAnGFyYml0cmFyeSBiaXQtZmll bGTigJ0uDQpCb3RoIHRlcm1zIG1heSBiZSB0ZWNobmljYWxseSBjb3JyZWN0LCBidXQgaGlkZSB0 aGUgbWVhbmluZyBvZiB0aGUgZmllbGQgYW5kIGluY3JlYXNlIHRoZSBsb2FkIG9uIHJlYWRlciBp biB1bmRlcnN0YW5kaW5nIHRoZSB0ZWNobm9sb2d5Lg0KDQpBcyBhbiBhc2lkZSwgdGhlIGFmb3Jl bWVudGlvbmVkIFRJQ1RPQyBXRyBkcmFmdCBvcmlnaW5hbGx5IGNvbnRhaW5lZCBleHRlbnNpb25z IHRvIE9TUEYsIFJTVlAtVEUsIGV0Yy4NCkl0IHdhcyBkZWNpZGVkIHRvIHNlcGFyYXRlIHRoZSBj b250cm9sIGV4dGVuc2lvbnMgZnJvbSB0aGUgZm9yd2FyZGluZyBwbGFuZSBkcmFmdCwgYW5kIHRv IHB1cnN1ZSBlYWNoIGluIHRoZSBtb3N0IGFwcHJvcHJpYXRlIFdHLg0KSXQgbWlnaHQgYmUgYSBn b29kIGlkZWEgdG8gZG8gdGhlIHNhbWUgaGVyZS4NCg0KT25lIG9mIHRoZSBmYWN0cyBvZiBsaWZl IHdpdGggb24tcGF0aCBzdXBwb3J0IG9mIHRpbWluZyBkaXN0cmlidXRpb24gaXMgdGhhdCBpdCBp cyBvZnRlbiBvbmx5IHBhcnRpYWwuDQpXaGF0IGhhcHBlbnMgdG8gdGhpcyBzb2x1dGlvbiB3aGVu IHRoZXJlIGlzIG9ubHkgcGFydGlhbCBzdXBwb3J0Pw0KSSBjYW4gaW1hZ2luZSB1bnJlY29nbml6 ZWQgR0FDaCBwYWNrZXRzIGJlaW5nIGJvb3RlZCB0byBDUFUgaW4gc3VjaCBjYXNlcywgc2V2ZXJl bHkgaW1wYWN0aW5nIHVuY29tcGVuc2F0ZWQgcmVzaWRlbmNlIHRpbWUuDQoNClkoSilTDQoNCg== --_000_DB3PR03MB078027B62C3C7BC5435B08879DCA0DB3PR03MB0780eurp_ Content-Type: text/html; charset="utf-8" Content-ID: <09AA0E29628D5B4094F100D5D80CC6AE@ECI365.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZn0NCi0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7 Ij4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+WWFha292LDwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+TG90cyBvZiB0aGFua3Mg Zm9yIGEgcHJvbXB0IHJlc3BvbnNlLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2lu LWJvdHRvbTowOyI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90 dG9tOjA7Ij5QbGVhc2Ugc2VlIGlubGluZSBiZWxvdy48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRv cDowO21hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwvcD4NCjxkZXYzX2pqeT5UaHVtYiB0eXBlZCBv biBteSBMRyw8YnI+DQpTYXNoYTwvZGV2M19qank+PGJyPg0KPGJyPg0KLS0tLS0tIE9yaWdpbmFs IG1lc3NhZ2UgLS0tLS0tPGJyPg0KPGI+RnJvbTombmJzcDs8L2I+WWFha292IFN0ZWluPHlhYWtv dl9zQHJhZC5jb20+PGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+MjgvMDUvMjAxNSAxMDoxNTxicj4N CjxiPlRvOiZuYnNwOzwvYj5BbGV4YW5kZXIgVmFpbnNodGVpbjttcGxzQGlldGYub3JnOzxicj4N CjxiPlN1YmplY3Q6PC9iPlJFOiBbbXBsc10gcmV2aWV3IG9mIGRyYWZ0LW1pcnNreS1tcGxzLXJl c2lkZW5jZS10aW1lPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TYXNoYTwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5JIGhvcGUgdGhhdCB5b3UgYXJlIGZlZWxpbmcgYmV0dGVyLjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1tTYXNoYV1d IE5vdCB5ZXQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4xLiBJIGFtIGxvb2tpbmcgYXQgdmVyc2lvbiA2IG9mIHRoaXMgZHJhZnQs IHdoaWNoIG9uIHBhZ2UgNSBzaG93cyB0aGUgU2NyYXRjaCBQYWQgZm9sbG93ZWQgYnkgVHlwZSwg TGVuZ3RoLCBWYWx1ZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+YW5kIGV4cGxhaW5zIDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjwvc3Bhbj48c3BhbiBsYW5nPSJF TiI+VGhlIFR5cGUgZmllbGQgaWRlbnRpZmllcyB0aGUgdHlwZSBvZiBWYWx1ZSB0aGF0IHRoZSBU TFYgY2Fycmllcy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4iPiZuYnNwOyZuYnNwO0lBTkEgd2lsbCBiZSBhc2tlZCB0byBjcmVhdGUgYSBzdWItcmVnaXN0 cnkgaW4gR2VuZXJpYyBBc3NvY2lhdGVkPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOIj5DaGFubmVsIChHLUFDaCkgUGFyYW1ldGVycyBSZWdpc3RyeSBjYWxs ZWQgJnF1b3Q7TVBMUyBSVE0gVExWPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOIj5SZWdpc3RyeSZxdW90Oy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4iPltbU2FzaGFdXSBUaGlzIGlzIG5vdCB3aGF0IGhhcyBiZWVu IGRlZmluZWQgYXMgYSAmcXVvdDtHQUNoIFRMVl1dIGluIFJGQyA1NTg2IGFuZCB0aGVuIGRlcHJl Y2F0ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Mi4gSSBhZ3JlZSB0aGF0IGEgbGVnYWN5IGRldmljZSB3aWxsIG5vdCBpbnNwZWN0IHlvdXIgc3Ry dWN0dXJlLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SSB3YXMganVzdCBxdWVzdGlvbmluZyBpdHMgaGFuZGxpbmcgb2YgR0FDaCBw YWNrZXRzLCB3aGV0aGVyIG9yIG5vdCBUVEwgaGFzIGV4cGlyZWQuPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bW1Nhc2hhXV0gQSBs ZWdhY3kgZGV2aWNlIHRoYXQgaXMgY29tcGxpYW50IHdpdGggUkZDIDMwMzEgd2lsbCBuZXZlciBp ZGVudGlmeSB0aGUgcGFja2V0IGFzIGEgR0FDaCBvbmUgYmVjYXVzZSBpdCB3aWxsIG5ldmVyIGlu c3BlY3QgdGhlIGxhYnJsIHN0YWNrIGVudHJ5IHRoYXQgY29udGFpbnMgR0FMLjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4zLiBBcyB5b3Ugd2lsbCByZW1lbWJlciwgd2hhdCB5b3UgY2FsbCBtb2RpZmljYXRpb24g b2YgdGhlIE1QTFMgZGF0YSBwbGFuZSBieSB0aGUgVElDVE9DIGRyYWZ0PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj53YXMgcHJlY2lz ZWx5IHdoYXQgd2Ugd2VyZSBpbnN0cnVjdGVkIGJ5IHRoZSBNUExTIFdHIHJldmlld2Vycy4NCjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+T3VyIG9yaWdpbmFsIGluY2xpbmF0aW9uIHdhcyB0byByZXF1ZXN0IGEgcmVzZXJ2ZWQgbGFi ZWwgZm9yIHRpbWluZyBwYWNrZXRzLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIFRJQ1RPQyBkcmFmdCBkb2VzIG5vdCBkZWZp bmUgYW55IG5ldyBGT1JXQVJESU5HIGJlaGF2aW9yLDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+aXQgZG9lcyByZXF1aXJlIHN0YW5k YXJkIDE1ODggZmllbGQgbW9kaWZpY2F0aW9uLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBpcyBwcmVjaXNlbHkgdGhlIHNh bWUgbGF5ZXIgdmlvbGF0aW9uIGFzIDE1ODggVEMgbWFuZGF0ZXMgZm9yIGFsbCBpdHMgdHJhbnNw b3J0IGxheWVycywNCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+RXRoZXJuZXQsIElEUC9JUHY0LCBJRFAvSVB2NiwgRGV2aWNlTkVU LCBDb250cm9sTkVULCBQUk9GSU5FVCwg4oCmPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bW1Nhc2hhXV0gJm5ic3A7VGhpcyBkcmFm dCByZXByZXNlbnRzIGFuIGF0dGVtcCB0byBieXBhc3MgdGhpcyBsYXllciB2aW9sYXRpb24gZm9y IE1QTFMuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gcm9tIG15IFBP ViB0aGlzIGlzIGl0cyBtYWluIGFkZGVkIHZhbHVlLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZKEopUzwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0OyBwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IDI2LzA1LzIwMTUgMDk6MDY8YnI+DQo8Yj5Ubzo8L2I+IFlhYWtvdiBTdGVpbjsgbXBsc0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIHJldmlldyBvZiBkcmFmdC1taXJz a3ktbXBscy1yZXNpZGVuY2UtdGltZTwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjsgbWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+WWFha292LDwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjsgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+TG90cyBvZiB0aGFua3MgZm9yIGEgdmVyeSBkZXRhaWxlZCBy ZXZpZXcuPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluOyBtYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JIGRlZmVyIHRvIG90aGVyIGNv LWF1dGhvcnMgdG8gZGVzY3JpYmUgdGhlIHJlbGV2YW50IHVzZSBjYXNlcyBpbiBtb3JlIGRldGFp bC48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47IG1hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjsgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+SSBqdXN0IHdhbnRlZCB0byBjb21tZW50IG9uIHR3byBwb2ludHM6PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4xLiBUaGUgZHJhZnQgZG9lcyBub3QgdXNlIEdB Q2ggVExWcyAodGhhdCBoYXZlIGJlZW4gZGVwcmVjYXRlZCBCVFcpLjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjsgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Mi4gQSBsZWdhY3kgZGV2aWNlIHRoYXQgZG9lcyBub3QgaGF2ZSBSVE0g Y2FwYWJpbGl0aWVzIHdpbGwgbmV2ZXIgaW5zcGVjdCB0aGUgR0FML0dBQ2ggY29uc3RydWN0IHVz ZWQgaW4gdGhlIGRyYWZ0LCBiZWNhdXNlIHN1Y2ggaW5zcGVjdGlvbiBjYW4gb25seSBoYXBwZW4g ZWl0aGVyIGF0IHRoZSBMU1AgdGFpbC1lbmQNCiBub2RlIG9yIGF0IGFuIFJUTS0gY2FwYWJsZSBu b2RlIHRoYXQgdHJhcHMgdGhlIFJUTSBwYWNrZXQgZHVlIHRvIFRUTCBleHBpcmF0aW9uLjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjsgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhpcyBsYXN0IHBvaW50IGlzIElNSE8gYSBtYWpv ciBkaWZmZXJlbnRpYXRvciBiZXR3ZWVuIHRoaXMgZHJhZnQgYW5kIG9uZSBoYW5kbGVkIGJ5IHRo ZSBUSUNUT0MgV0c6PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluOyBtYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4tIHRoaXMgZHJhZnQg ZG9lcyBub3QgY2hhbmdlIHRoZSBNUExTIERQIGFzIGRlZmluZWQgaW4gUkZDIDMwMzEgYW5kIFJG QyAzNDQzPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluOyBtYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4tIHRoZSBUSUNUT0MgZHJhZnQg KGF0IGxlYXN0IHRvIHRoZSBiZXN0IG9mIG15IHJlY29sbGVjdGlvbikgYXNzaWduZWQgc3BlY2lh bCBoYW5kbGluZyB0byBsYWJlbHMgdXNlZCBieSB0aGUgTFNQcyBjYXJyeWluZyBQVFAgcGFja2V0 cyB0aGF0IHdhcyBub3QgZGVmaW5lZCBhcyBhICZxdW90O2xhYmVsIGFjdGlvbiZxdW90OyBpbiBS RkMNCiAzMDMxIChuZWl0aGVyIFBvcCwgbm9yIFN3YXAgbm9yIFB1c2gpLjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjsgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu OyBtYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5S ZWdhcmRzLDwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjsgbWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U2FzaGE8L3NwYW4+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47IG1hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjsgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VGh1bWIgdHlwZWQgb24gbXkgTEcsPGJy Pg0KU2FzaGE8YnI+DQo8YnI+DQotLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS08YnI+DQo8 Yj5Gcm9tOiZuYnNwOzwvYj5ZYWFrb3YgU3RlaW48YnI+DQo8Yj5EYXRlOiZuYnNwOzwvYj4yNi8w NS8yMDE1IDA4OjExPGJyPg0KPGI+VG86Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjs8YnI+DQo8Yj5TdWJqZWN0OjwvYj5bbXBsc10gcmV2 aWV3IG9mIGRyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lPC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb2EgYXNrZWQgbWUgdG8gY29tbWVudCBvbiB0aGlzIGRy YWZ0IGJlZm9yZSBpdHMgYWNjZXB0YW5jZSBhcyBhIE1QTFMgV0cgZHJhZnQuPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgZmFyIGFz IEkgdW5kZXJzdGFuZCwgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCBpcyB0byBwcm92aWRlIGEg Zm9ybSBvZiB3aGF0IGlzIGNhbGxlZCDigJxvbi1wYXRoIHRpbWluZyBzdXBwb3J04oCdIGluIHRo ZSBUSUNUT0MgV0cuDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3BlY2lmaWMga2lu ZCBvZiBvbi1wYXRoIHN1cHBvcnQgaXMgYWNjdW11bGF0aW9uIG9mIHJlc2lkZW5jZSB0aW1lcyBp biBMU1JzIHdoaWNoIGEgdGltZS1zZW5zaXRpdmUgZmxvdyB0cmF2ZXJzZXMuPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgc3VjaCBpdCBpcyBlc3NlbnRpYWxseSB0aGUgc2FtZSBhcyB3aGF0 IGlzIGNhbGxlZCDigJx0cmFuc3BhcmVudCBjbG9ja2luZ+KAnSAoVEMpIGluIElFRUUgMTU4OCwg YW5kIHRoZSBkcmFmdCBpbmRlZWQgcmUtdXNlcyBUQyB0ZWNobm9sb2dpZXMuDQo8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVy IHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmVtZWR5IGEgcHJvYmxlbSB3aXRoIFRDIGFzIHByZXNl bnRseSBpbXBsZW1lbnRlZCDigJMgaXRzIGxheWVyIHZpb2xhdGlvbi4NCjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgdmlvbGF0aW9uIG9jY3VycyBzaW5jZSBwaHlzaWNhbCBsYXllciB0 aW1pbmcgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBtb2RpZnkgYSBmaWVsZCBvZiBhIGhpZ2hlciBs YXllciBwcm90b2NvbC4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcmVzZW50IGRy YWZ0IHJlbWVkaWVzIHRoaXMgYnkgZm9yY2luZyBob3AtYnktaG9wIGJlaGF2aW9yIGJ5IFRUTCBm aWVsZCBtYW5pcHVsYXRpb24sDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgYXQgdGhl IHByaWNlIG9mIGhhdmluZyB0byB0cmFuc3BvcnQgdGltaW5nIGZsb3dzIGluIHRoZSBhc3NvY2lh dGVkIGNoYW5uZWwsDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcmV2aW91c2x5IGxpbWl0 ZWQgdG8gT0FNIGFuZCBjb250cm9sL21hbmFnZW1lbnQgcGxhbmUgdXNlcy48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBzdWNoIHRo ZSBkcmFmdCBlbGVnYW50bHkgc29sdmVzIGEgdGhlb3JldGljYWwgcHJvYmxlbS4gPC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBs ZXNzIHN1cmUgdGhhdCBpdCBzb2x2ZXMgYSByZWFsLXdvcmxkIHByb2JsZW0sIGZvciB0aGUgZm9s bG93aW5nIHJlYXNvbnMgOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjEuIEZpcnN0IGlzIHRoZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBz aW1wbGVyIGFsdGVybmF0aXZlIGZvciBvbi1wYXRoIHN1cHBvcnQgb2YgMTU4OCBvdmVyIE1QTFMg dGhhdCBoYXMgYWxyZWFkeSBwYXNzZWQgV0cgTEMgaW4gVElDVE9DLg0KPC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGV4aXN0aW5nIFRJQ1RPQyBkcmFmdCB3YXMgcHVycG9zZWx5IGNvbnN0 cmFpbmVkIDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihmb2xsb3dpbmcgYWR2aWNlIG9mIHJl dmlld2VycyB3aG8gYXJlIE1QTFMgZXhwZXJ0cykgPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ dG8gbm90IHRvdWNoIHRoZSBNUExTIGZvcndhcmRpbmcgcGxhbmUsIHdoaWxlIHRoaXMgZHJhZnQg ZGVmaW5lcyBHQUNoIFRMVnMgYW5kIHN1Yi1UTFZzLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIHByZXNlbnQgZHJhZnQgaXMgYWRtaXR0ZWRseSBtdWNoIHdpZGVyIGluIGFwcGxpY2Fi aWxpdHksIGJ1dCBubyB1c2Ugb3RoZXIgdGhhbiAxNTg4IG9uLXBhdGggc3VwcG9ydCBpcyBkZXNj cmliZWQgaW4gdGhlIGRyYWZ0LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIE9uZSBjb25jZWl2YWJsZSB1c2Ugd291bGQgYmUgZm9y IGhpZ2hseSBhY2N1cmF0ZSBvbmUtd2F5IGRlbGF5IGVzdGltYXRpb24gd2l0aG91dCBzeW5jaHJv bml6ZWQgY2xvY2tzDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYW5kIEkgYW0gbm90IHN1 cmUgd2hlbiB0aGlzIHVzZSBpcyByZWFsbHkgbmVlZGVkKS4gPC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T2YgY291cnNlIHRoZSBwcmVzZW50IG1ldGhvZCBvbmx5IGFjY291bnRzIGZvciByZXNp ZGVuY2UgdGltZSBpbiBMU1JzLCBub3QgZm9yIHByb3BhZ2F0aW9uIGxhdGVuY2llcyBvbiBsaW5r cyAod2hpY2ggMTU4OCBjYW4gaGFuZGxlIGFzIHdlbGwpLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIG1ldGhvZG9sb2d5IHRvIG92ZXJjb21lIHRoaXMgbGltaXRhdGlvbiB3b3VsZCBh c3N1bWFibHkgYmUgdG8gcmVseSBvbiBhIGNvLXJvdXRlZCByb3VuZC10cmlwLCB0byB1cyB0aGlz IGRyYWZ0IHRvIGNhbmNlbCByZXNpZGVuY2UgdGltZXMsDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hbmQgdGhlbiB0byBtZWFzdXJlIHRoZSByZW1haW5pbmcgcm91bmQtdHJpcCB0aW1lIGFu ZCBkaXZpZGUgYnkgdHdvLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgZXhp c3RpbmcgYWxnb3JpdGhtcyBkbyBhIHByZXR0eSBnb29kIGpvYiBhdCBjYW5jZWxsaW5nIHJlc2lk ZW5jZSB0aW1lcw0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZXhjZXB0IHdoZW4gdGhlIGZs b3cgdHJhdmVyc2VzIGEgbGFyZ2UgbnVtYmVyIG9mIG5ldHdvcmsgZWxlbWVudHMgd2hpY2ggYXJl IGhlYXZpbHkgbG9hZGVkIHdpdGggcGxlc2lvY2hyb25vdXNseSByZWxhdGVkIGludGVyZmVyaW5n IGZsb3dzLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHRoZSBhdXRob3JzIGhhdmUgYW5v dGhlciB1c2UgY2FzZSBpbiBtaW5kID88L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBUaGUgcHJpbWFyeSBkb2N1bWVudGVkIGFwcGxp Y2F0aW9uIGZvciAxNTg4IGluIHRlbGVjb20gbmV0d29ya3MgaXMgY2VsbHVsYXIgYmFja2hhdWwu DQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFwcGxpY2F0aW9uIGFscmVhZHkgaGFz IGEgcGxldGhvcmEgb2Ygc29sdXRpb25zLCBiYXNlZCBvbiBHUFMsIDE1ODggb3ZlciBFdGhlcm5l dCB3aXRoIGJvdW5kYXJ5IGNsb2NrcyAoQkMpLCBkaXN0cmlidXRlZCBncmFuZCBtYXN0ZXJzLCBl dGMuIGV0Yy4gZXRjLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCBCQyBhcyB3 aWRlbHkgZGVwbG95ZWQgaXMgYWxyZWFkeSBob3AtYnktaG9wLCBhbmQgaW4gdGhhdCB3YXkgc2lt aWxhciB0byB0aGlzIGRyYWZ0LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHlldCBhbm90 aGVyIHNvbHV0aW9uIHJlYWxseSBuZWVkZWQgPyA8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBSZWxhdGVkIHRvIHRoZSBwcmV2aW91 cyBxdWVzdGlvbnMgaXMgdGhlIGlzc3VlIG9mIGltcGxlbWVudGF0aW9uIGluIGFscmVhZHkgZXhp c3RpbmcgbmV0d29ya3MuDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNvbHV0aW9u IHJlcXVpcmVzIGhhcmR3YXJlIHVwZ3JhZGVzIGF0IGxlYXN0IGZvciB0aGUgYWNjdXJhdGUgdGlt ZS1zdGFtcGluZyBhbmQgcG9zc2libHkgZm9yIHRoZSBhY2N1bXVsYXRpb24gYW5kIGZpZWxkIG1v ZGlmaWNhdGlvbg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGFsdGhvdWdoIHRoZSBsYXR0 ZXIgbWF5IHNvZnR3YXJlIHVwZ3JhZGVzLCBlc3BlY2lhbGx5IGlmIDItc3RlcCBjb3JyZWN0aW9u IGlzIHV0aWxpemVkKS4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIG5lZWQgdG8g dXBncmFkZSBoYXJkd2FyZSwgd2h5IG5vdCBkZXBsb3kgQkNzID8gPC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QSBmZXcgeWVhcnMgYmFjayBJIHdvdWxkIGhhdmUgc2FpZCB0aGF0IFRDIGNvdWxk IGJlIGltcGxlbWVudGVkIGluIG1pbmlhdHVyaXplZCBkZXZpY2VzIHdoZXJlIEJDIGNvdWxkIG5v dCwNCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBhZHZhbmNlcyBpbiBtaW5pYXR1cml6 YXRpb24gb2YgT0NYT3MgaGF2ZSBzZXZlcmVseSByZWR1Y2VkIHRoaXMgYWR2YW50YWdlIHRvIGNh c2VzIHdoZXJlIGF0b21pYy1jbG9jayBob2xkLW92ZXIgaXMgcmVxdWlyZWQuPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NS4gSWYgYW5v dGhlciBzb2x1dGlvbiBmb3IgdGhpcyBzcGVjaWZpYyBhcHBsaWNhdGlvbiBpcyBuZWVkZWQsIGlz IGl0IG5lZWRlZCBmb3IgTVBMUyA/DQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DZWxsdWxh ciBiYWNraGF1bCBvdmVyIGNhcnJpZXIgRXRoZXJuZXQgaXMgd2lkZWx5IGRlcGxveWVkLCBpcyBj ZWxsdWxhciBiYWNraGF1bCBvdmVyIE1QTFMgc3VmZmljaWVudGx5IHdpZGVzcHJlYWQgdG8gbWVy aXQgdGhpcyBleHRlbnNpb24gPzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYuIE1QTFMgZG9lcyBub3QgZGVmaW5lIGl0cyBvd24gcGh5 c2ljYWwgbGF5ZXIgKHdoaWNoIEV0aGVybmV0IGRvZXMg4oCTIHRoZSBsYXllciBjYWxsZWQgRVRZ IGluIHRoZSBJVFUpLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc3VjaCBpdCBpcyBu b3QgY2xlYXIgdGhhdCBNUExTIGlzIHRoZSByaWdodCBwbGFjZSB0byBzb2x2ZSB0aGUgdGltaW5n IGRpc3RyaWJ1dGlvbiBwcm9ibGVtLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TVBMUyBu ZWNlc3NhcmlseSBydW5zIG92ZXIgc29tZSBwaHlzaWNhbCBsYXllciB3aGljaCBtYXkgYWxyZWFk eSBoYXZlIG9uLXBhdGggc3VwcG9ydCwgb3IgbWF5IG1vcmUgZWNvbm9taWNhbGx5IHN1cHBvcnQg aXQuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWxsIG9mIHRoZSBhdXRob3JzIHdvcmsgZm9yIHZlbmRvcnMg4oCTIGhhdmUgdGhlc2Ug dmVuZG9ycyBpbXBsZW1lbnRlZCB0aGlzIG9yIGRvIHRoZXkgcGxhbiBpbXBsZW1lbnRpbmcgPw0K PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIGFuc3dlciBpcyBhIHJlc291bmRpbmcg eWVzLCB0aGVuIEkgYXNzdW1lIHRoYXQgd2Ugd2lsbCBoZWFyIHJlYnV0dGFscyB0byBtb3N0IG9m IHRoZSBhYm92ZSByZW1hcmtzLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyB0aGUgY29udGVudCBvZiB0aGUgZHJhZnQs IEkgaGF2ZSBhIG1ham9yIGlzc3VlIHdpdGggdGhlIHVzZSBvZiB0aGUgdGVybSDigJxTY3JhdGNo IFBhZOKAnSBmb3IgdGhlIGNvcnJlY3Rpb24gZmllbGQNCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPihhbmQgQlRXLCBpdCBpcyBzb21ldGltZXMgY2FsbGVkIOKAnFNjcmF0Y2ggUGFk4oCdIGFu ZCBzb21ldGltZXMg4oCcU2NyYXRjaFBhZOKAnSBhbmQgc29tZXRpbWVzIOKAnHNjcmF0Y2ggcGFk 4oCdKS4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZmllbGQgaXMgbm90IHNvbWUg b3BhcXVlIG1ldGEtZGF0YSB0cmFuc3BvcnRlZCBieSB0aGlzIG5ld2x5IGRlZmluZWQgaGVhZGVy LA0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXQgaXMgdGhlIHZlcnkgY3J1eCBvZiB0aGUg c29sdXRpb24gYW5kIHJlcXVpcmVzIG1hbmlwdWxhdGlvbiB0byB3b3JrLg0KPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Q2FsbGluZyBpdCBhIOKAnHNjcmF0Y2ggcGFk4oCdICh3aXRoIGFueSBv ZiB0aGUgc3BlbGxpbmdzKSBpcyB0YW50YW1vdW50IHRvIGNhbGxpbmcgYW4gTVBMUyBsYWJlbCBh biDigJxhcmJpdHJhcnkgYml0LWZpZWxk4oCdLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Qm90aCB0ZXJtcyBtYXkgYmUgdGVjaG5pY2FsbHkgY29ycmVjdCwgYnV0IGhpZGUgdGhlIG1lYW5p bmcgb2YgdGhlIGZpZWxkIGFuZCBpbmNyZWFzZSB0aGUgbG9hZCBvbiByZWFkZXIgaW4gdW5kZXJz dGFuZGluZyB0aGUgdGVjaG5vbG9neS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbiBhc2lkZSwgdGhlIGFmb3JlbWVudGlvbmVk IFRJQ1RPQyBXRyBkcmFmdCBvcmlnaW5hbGx5IGNvbnRhaW5lZCBleHRlbnNpb25zIHRvIE9TUEYs IFJTVlAtVEUsIGV0Yy48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3YXMgZGVjaWRlZCB0 byBzZXBhcmF0ZSB0aGUgY29udHJvbCBleHRlbnNpb25zIGZyb20gdGhlIGZvcndhcmRpbmcgcGxh bmUgZHJhZnQsIGFuZCB0byBwdXJzdWUgZWFjaCBpbiB0aGUgbW9zdCBhcHByb3ByaWF0ZSBXRy48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0byBkbyB0 aGUgc2FtZSBoZXJlLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uZSBvZiB0aGUgZmFjdHMgb2YgbGlmZSB3aXRoIG9uLXBhdGggc3Vw cG9ydCBvZiB0aW1pbmcgZGlzdHJpYnV0aW9uIGlzIHRoYXQgaXQgaXMgb2Z0ZW4gb25seSBwYXJ0 aWFsLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaGFwcGVucyB0byB0aGlzIHNvbHV0 aW9uIHdoZW4gdGhlcmUgaXMgb25seSBwYXJ0aWFsIHN1cHBvcnQ/DQo8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGNhbiBpbWFnaW5lIHVucmVjb2duaXplZCBHQUNoIHBhY2tldHMgYmVpbmcg Ym9vdGVkIHRvIENQVSBpbiBzdWNoIGNhc2VzLCBzZXZlcmVseSBpbXBhY3RpbmcgdW5jb21wZW5z YXRlZCByZXNpZGVuY2UgdGltZS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZKEopUzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DB3PR03MB078027B62C3C7BC5435B08879DCA0DB3PR03MB0780eurp_-- From nobody Thu May 28 18:18:29 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE171AD36F for ; Thu, 28 May 2015 18:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oI8o2ms4PvQe for ; Thu, 28 May 2015 18:18:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3071AD0A6 for ; Thu, 28 May 2015 18:18:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWQ17944; Fri, 29 May 2015 01:18:24 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 May 2015 02:18:24 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.243]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 29 May 2015 09:18:19 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" , "draft-bonica-mpls-self-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document Thread-Index: AQHQkuMpoHC+IIZp8EiZk7w61TVjQp2SNLlw Date: Fri, 29 May 2015 01:18:19 +0000 Message-ID: References: <555C5A1D.7020709@pi.nu> In-Reply-To: <555C5A1D.7020709@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 01:18:29 -0000 Yes/support. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, May 20, 2015 5:56 PM > To: mpls@ietf.org; draft-bonica-mpls-self-ping@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus adopting > draft-bonica-mpls-self-ping as an MPLS wg document >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-bonica-mpls-self- > ping-06 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working group > mailing list (mpls@ietf.org). Please give a technical motivation for your > support/not support, especially if you think that the document should not= be > adopted as a working group document. >=20 > There is one IPR disclosures directly against this document. All the auth= ors has > stated on the working group mailing that they are unaware of any undisclo= sed > IPRs against this document. >=20 > However if you are on the the mpls working group mailing list and aware o= f IPR > that relates to this draft, the time to disclose this is now. >=20 > This poll ends June 5, 2015. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri May 29 11:57:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D870F1B2C30; Fri, 29 May 2015 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 uUTrfj8pGCjO; Fri, 29 May 2015 11:57:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B671B2C1B; Fri, 29 May 2015 11:57:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4TIvjqE031264; Fri, 29 May 2015 19:57:45 +0100 Received: from 950129200 (jplon-nat12.juniper.net [193.110.55.12]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4TIvfO6031231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 29 May 2015 19:57:44 +0100 From: "Adrian Farrel" To: "'Charlie Kaufman'" References: <554CAAE8.9090800@pi.nu> <5564375E.9060306@pi.nu> In-Reply-To: <5564375E.9060306@pi.nu> Date: Fri, 29 May 2015 19:57:40 +0100 Message-ID: <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF5eSexDRNWQp3PbXquwiAO8nDK8AG1NIBxAwpgEWKeGt5TUA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21578.002 X-TM-AS-Result: No--19.096-10.0-31-10 X-imss-scan-details: No--19.096-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wtcjCbPZgQnFQrO4XR6BRQPwZxaFJX+r1Q9W gBEShsusNJRL3ObC9T403lLuu4Ngvwr0iJbTVMrQVUIE0/jxA/0pWss5kPUFdFpbYq2f4jz+tNM q9uo9SGSdUQQhPyoTsFFO3CvbVp5Y3kon++iVNT3Rc75iroKqApSlv/9klkDi0mAM2eipqlpxQ9 CNI5RA3XndTfZ2f9trubF1G61WsDK2jsN8aguKvIhaKK0I26FpeJ1OirYwzAPqLnOUXH9QdN/LI yZs19OqD4fkXZtjSA5IGIywrjubdcaZnhgjGx375cQFbdjxan6imsR6hkcJAhZ50KsQddqXnUqX H4EzL8J2zheu5Rrnt1Jf31s+j+06/zkYJHv4a2FgP1dNF1ow7QkN8Uvsy+nt2oLGTNKlb9eGXWN Bqn1KYugqahDxmMqz/2Km2iZ9UFITtP2F86umWBD3+0w1DhqKviRliDV2nyxb6PBUqmq+UjtjAP WAT9k7mfH8FreQYWD5uD6QwNqXa/PnSD6On2CewCZxkTHxcclWjiXAsVR2K0iO8DX9hL7R4d2Na uEDjqzpw6f4ioqa6Z0K9Xn3Ln5CDL2trK/H+w4pa6LJktEjgOEpCHUsKYYGobx/SIoF+OYy5PBt qoQlk1/wODk/m7aHNDDF3FEnVHCWHmpvkeKJB1Pjo7D4SFg4YM9jZ5ImeaeA+ITQt7D1AHfDoi9 9VAHrkO2RcZLzfFxIKOYV2FoClO+Qm7Tg9jG3oxWB033D5MKBA/jzcz3nAVVgGGTe6VdACwgUPj ccZ/Dqumt0gZE/iphzqJ5nm6DdwwTYGyiIokyeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtpkzYWdbnR1BaewVHaiHXFPxXrdqkuzUuSUHWbFS8puGgJwEy2zguUIAjJblo AwAwShAy7Ao/AUv4OkKftdT/BMkjQlxoxv9QJeJ1WMCERkGtftyYo2KwDjKpoRvzNKOP9DB8M7t iaMCEN0PsxMBbpmcjFnImzvyS Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org, 'secdir' Subject: Re: [mpls] FYI - [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 18:57:53 -0000 Charlie, Thanks for this. Forgive me for stumbling through the security aspects: I'm sure Stephen will pick me up on whatever I get wrong. > All-- > Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a > protocol for doing opportunistic encryption of MPLS connections. It permits > encryption at any of two scopes: between adjacent Label Switching Routers > (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an > LSP. Opportunistic encryption in this case means that there is no mechanism > specified for authenticating the endpoints of the encrypted channel. The two > endpoints do an anonymous Diffie-Hellman exchange and use the resulting key > to encrypt the connection. The protocol is not protected from a > man-in-the-middle attack (though some mechanisms for detecting such an > attack after the fact are suggested and a keying infrastructure could be > added later). > > The encryption aspects of the protocol seem well thought out and > appropriate. The question at hand is whether to adopt this document as a > working group document and it easily meets that bar (at least from a > security standpoint). I have a number of questions about operational aspects > of the protocol (perhaps due to my limited understanding of MPLS) and I have > some suggestions for enhancements that will probably be necessary eventually > and might be easier to make before there is widespread deployment: > > There is an issue that came up in the design of IKEv2 that may be an issue > here as well. I don't know whether MPLS connections are bi-directional or > whether separate connections need to be established in the two directions. > > If they are bi-directional, then there are race conditions that can occur if > both ends attempt to initialize a connection simultaneously and there must > be some tie-breaking mechanism to assure that exactly one of the connection > attempts succeeds. If they are uni-directional, and if the connection is > always initialized by the sending end, then this is not a problem (though it > is replaced with the problem that messages of this protocol sent in the > reverse direction cannot be tunneled over the MPLS connection). (This > document seems to imply that MPLS connections can be either uni-directional > or bi-directional, but I don't understand MPLS well enough to have > understood it). Even if the connections are bi-directional, it will make > your life simpler if you use different symmetric keys in the two directions. > This can be done easily by getting two independent keys from the key > expansion process. Right. LSPs may be unidirectional or bidirectional. Section 4 and particularly 4.3 describe how the return path is selected for the case of a unidirectional LSP. So we have four questions: 1. Is the return path secure? 2. Who initiates the use of OS? 3. How do we handle race conditions? 4. Should we have different keys in different directions? In fact, the key exchange does not itself need to be secure, but it would be better if it was. 4.2.1 and 4.4 say how to do this if possible, but notes it will likely not be possible in the case of OS. So that's Q1. In the case of a unidirectional LSP, only the source node (i.e. upstream from the perspective of data flow) can be the initiator for the key exchange because the key exchange requires the use of a message flowing on the LSP itself. So, for Q2 we only have to worry about bidirectional LSPs, and that takes us to Q3. But, in fact, a bidirectional LSP is in fact (from the point of view of the forwarding plane) the association of two unidirectional LSPs. The association may be so tight (in the control plane or the management plane, and with fate sharing) that the LSP is referred to as *a* single bidirectional LSP, but that doesn't change the forwarding plane behavior. And, indeed, in the bidirectional case, there is no reason to not have encryption in one direction and not in the other direction (except, of course, that more is better :-). So that means that each direction of the bidirectional LSP is responsible for initiating its own OS. Hence Q3 is not a problem, and Q4 takes care of itself. We should definitely clarify this in the draft (and thank you for making me describe it here), but I'd like some more discussion with the WG to check I am right about this. > A second issue relates to algorithm negotiation. While the protocol allows > for any of the crypto algorithms to be replaced, and the algorithms are > indicated on the wire, it does not appear to allow for a smooth upgrade > where the two ends are updated independently and everything must continue > to work when only one end has been updated. To accomplish that, there > should be an algorithm negotiation (as takes place in IKE and TLS) where one > end presents a list of algorithms is can support and the other end chooses the > algorithms it prefers. A simpler variation would be for a responder to be > able to reject the algorithms assumed by the initiator and send back a list > of algorithms it will accept. Note: it's possible that MPLS already operates > with the restriction that the two ends of a connection must be consistent > and operations will halt if the two ends are updated non-simultaneously. If > that's true, then adding crypto doesn't make the situation any worse and it > would be acceptable to continue to operate that way. I'm so far from being an expert in this matter that I am probably making a fool of myself (again), but is algorithm replacement actually any different from key change? That is, the key negotiation protocol negotiates the key and algorithm to use and so can also negotiate changes in both key and algorithm. Section 4.2.3 mentions this, but is exceptionally week. I'll add some text (assuming what I just wrote is not complete lunacy). The key ID identifies the key and the algorithm in one field, so being able to change the key ID was intended to also allow changing the algorithm. > A possible problem with Key Identifiers: the Key Identifier is only 4 bits > long, which should be sufficient because at most two keys should be active > at any given time. The Key Identifier, however, is chosen effectively > randomly, which means that one time in 16 it will be the same as the Key > Identifier it is replacing. While the protocol could be modified to do > something special in that last (like adding one to the Key Identifier if it > matches the previous value or redoing the key negotiation in that case), it > would probably be better to get the Key-ID from the key expansion when > there is no previous connection and add one (mod 16) when rekeying. Yes, I had assumed that if the key ID was reselected then some form of secondary choice would be made. Not sure that the predictability of simply adding one is good idea (not that I can think of specific associated risk). > There is mention of the possibility of reusing g^i and g^r between > connections. Some crypto purists would object to that, but I wouldn't. If > you want to allow implementations that option, however, you should also > include in the exchange nonce values Ni and Nr that are not reused between > connections rather than depending on unique values for the other parameters > to prevent reuse of keys. Ah, hmm, OK. Stephen? Help! > In section 3.5 (MTU considerations), I suspect you may be underestimating > the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad > bytes to make the encrypted payload size a multiple of 16 bytes. There are > algorithm variants that do not add any padding, but they are somewhat > controversial and difficult to implement in hardware. Further, the total > overhead will be dependent of the crypto algorithm chosen, and the text > should indicate that so that readers don't assume that there is some maximum > number of bytes that can be wired into protocols that run above this. That's helpful. Stephen, I need you to help with this. > I would suggest that most or all of sections 5 and 7 should be moved to > Security Considerations. Failing that, the Security Considerations section > should reference them. Thanks. Since 5 is growing, I've put back pointer from 6. 7.1 is already referenced from 6.2 and 6.3 > Typos: > > P4: "and if may be advisable" -> "and it may be advisable" > P4: "an alternative key derivation functions" -> "alternative key derivation > functions" > P5: "key definition function" -> "key derivation function" > P5: "attck vecotrs" -> "attack vectors" > P5: "descirption" -> "description" > P19: "opostie" -> "opposite" Good. vmt Adrian From nobody Fri May 29 14:03:04 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0211B2D63; Fri, 29 May 2015 14:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GqNt4TI6ZdIv; Fri, 29 May 2015 14:03:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C138A1B2D5C; Fri, 29 May 2015 14:03:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8C37CBF19; Fri, 29 May 2015 22:02:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCAEZhbZ1rgD; Fri, 29 May 2015 22:02:57 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54AEBBF03; Fri, 29 May 2015 22:02:57 +0100 (IST) Message-ID: <5568D401.3040004@cs.tcd.ie> Date: Fri, 29 May 2015 22:02:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Charlie Kaufman' References: <554CAAE8.9090800@pi.nu> <5564375E.9060306@pi.nu> <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> In-Reply-To: <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org, 'secdir' Subject: Re: [mpls] FYI - [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 21:03:03 -0000 Hiya, On 29/05/15 19:57, Adrian Farrel wrote: > Charlie, > > Thanks for this. Forgive me for stumbling through the security aspects: I'm sure > Stephen will pick me up on whatever I get wrong. I'll get to this in a day or so, thanks Charlie for the review and Adrian for processing it. S. > >> All-- >> Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a >> protocol for doing opportunistic encryption of MPLS connections. It permits >> encryption at any of two scopes: between adjacent Label Switching Routers >> (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an >> LSP. Opportunistic encryption in this case means that there is no mechanism >> specified for authenticating the endpoints of the encrypted channel. The two >> endpoints do an anonymous Diffie-Hellman exchange and use the resulting key >> to encrypt the connection. The protocol is not protected from a >> man-in-the-middle attack (though some mechanisms for detecting such an >> attack after the fact are suggested and a keying infrastructure could be >> added later). >> >> The encryption aspects of the protocol seem well thought out and >> appropriate. The question at hand is whether to adopt this document as a >> working group document and it easily meets that bar (at least from a >> security standpoint). I have a number of questions about operational aspects >> of the protocol (perhaps due to my limited understanding of MPLS) and I have >> some suggestions for enhancements that will probably be necessary eventually >> and might be easier to make before there is widespread deployment: >> >> There is an issue that came up in the design of IKEv2 that may be an issue >> here as well. I don't know whether MPLS connections are bi-directional or >> whether separate connections need to be established in the two directions. >> >> If they are bi-directional, then there are race conditions that can occur if >> both ends attempt to initialize a connection simultaneously and there must >> be some tie-breaking mechanism to assure that exactly one of the connection >> attempts succeeds. If they are uni-directional, and if the connection is >> always initialized by the sending end, then this is not a problem (though it >> is replaced with the problem that messages of this protocol sent in the >> reverse direction cannot be tunneled over the MPLS connection). (This >> document seems to imply that MPLS connections can be either uni-directional >> or bi-directional, but I don't understand MPLS well enough to have >> understood it). Even if the connections are bi-directional, it will make >> your life simpler if you use different symmetric keys in the two directions. >> This can be done easily by getting two independent keys from the key >> expansion process. > > Right. LSPs may be unidirectional or bidirectional. > > Section 4 and particularly 4.3 describe how the return path is selected for the > case of a unidirectional LSP. > > So we have four questions: > > 1. Is the return path secure? > 2. Who initiates the use of OS? > 3. How do we handle race conditions? > 4. Should we have different keys in different directions? > > In fact, the key exchange does not itself need to be secure, but it would be > better if it was. 4.2.1 and 4.4 say how to do this if possible, but notes it > will likely not be possible in the case of OS. So that's Q1. > > In the case of a unidirectional LSP, only the source node (i.e. upstream from > the perspective of data flow) can be the initiator for the key exchange because > the key exchange requires the use of a message flowing on the LSP itself. So, > for Q2 we only have to worry about bidirectional LSPs, and that takes us to Q3. > > But, in fact, a bidirectional LSP is in fact (from the point of view of the > forwarding plane) the association of two unidirectional LSPs. The association > may be so tight (in the control plane or the management plane, and with fate > sharing) that the LSP is referred to as *a* single bidirectional LSP, but that > doesn't change the forwarding plane behavior. And, indeed, in the bidirectional > case, there is no reason to not have encryption in one direction and not in the > other direction (except, of course, that more is better :-). So that means that > each direction of the bidirectional LSP is responsible for initiating its own > OS. > > Hence Q3 is not a problem, and Q4 takes care of itself. > > We should definitely clarify this in the draft (and thank you for making me > describe it here), but I'd like some more discussion with the WG to check I am > right about this. > >> A second issue relates to algorithm negotiation. While the protocol allows >> for any of the crypto algorithms to be replaced, and the algorithms are >> indicated on the wire, it does not appear to allow for a smooth upgrade >> where the two ends are updated independently and everything must continue >> to work when only one end has been updated. To accomplish that, there >> should be an algorithm negotiation (as takes place in IKE and TLS) where one >> end presents a list of algorithms is can support and the other end chooses the >> algorithms it prefers. A simpler variation would be for a responder to be >> able to reject the algorithms assumed by the initiator and send back a list >> of algorithms it will accept. Note: it's possible that MPLS already operates >> with the restriction that the two ends of a connection must be consistent >> and operations will halt if the two ends are updated non-simultaneously. If >> that's true, then adding crypto doesn't make the situation any worse and it >> would be acceptable to continue to operate that way. > > I'm so far from being an expert in this matter that I am probably making a fool > of myself (again), but is algorithm replacement actually any different from key > change? That is, the key negotiation protocol negotiates the key and algorithm > to use and so can also negotiate changes in both key and algorithm. > > Section 4.2.3 mentions this, but is exceptionally week. I'll add some text > (assuming what I just wrote is not complete lunacy). > The key ID identifies the key and the algorithm in one field, so being able to > change the key ID was intended to also allow changing the algorithm. > >> A possible problem with Key Identifiers: the Key Identifier is only 4 bits >> long, which should be sufficient because at most two keys should be active >> at any given time. The Key Identifier, however, is chosen effectively >> randomly, which means that one time in 16 it will be the same as the Key >> Identifier it is replacing. While the protocol could be modified to do >> something special in that last (like adding one to the Key Identifier if it >> matches the previous value or redoing the key negotiation in that case), it >> would probably be better to get the Key-ID from the key expansion when >> there is no previous connection and add one (mod 16) when rekeying. > > Yes, I had assumed that if the key ID was reselected then some form of secondary > choice would be made. Not sure that the predictability of simply adding one is > good idea (not that I can think of specific associated risk). > >> There is mention of the possibility of reusing g^i and g^r between >> connections. Some crypto purists would object to that, but I wouldn't. If >> you want to allow implementations that option, however, you should also >> include in the exchange nonce values Ni and Nr that are not reused between >> connections rather than depending on unique values for the other parameters >> to prevent reuse of keys. > > Ah, hmm, OK. > Stephen? > Help! > >> In section 3.5 (MTU considerations), I suspect you may be underestimating >> the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad >> bytes to make the encrypted payload size a multiple of 16 bytes. There are >> algorithm variants that do not add any padding, but they are somewhat >> controversial and difficult to implement in hardware. Further, the total >> overhead will be dependent of the crypto algorithm chosen, and the text >> should indicate that so that readers don't assume that there is some maximum >> number of bytes that can be wired into protocols that run above this. > > That's helpful. > Stephen, I need you to help with this. > >> I would suggest that most or all of sections 5 and 7 should be moved to >> Security Considerations. Failing that, the Security Considerations section >> should reference them. > > Thanks. Since 5 is growing, I've put back pointer from 6. > 7.1 is already referenced from 6.2 and 6.3 > >> Typos: >> >> P4: "and if may be advisable" -> "and it may be advisable" >> P4: "an alternative key derivation functions" -> "alternative key derivation >> functions" >> P5: "key definition function" -> "key derivation function" >> P5: "attck vecotrs" -> "attack vectors" >> P5: "descirption" -> "description" >> P19: "opostie" -> "opposite" > > Good. > > vmt > Adrian > > From nobody Sun May 31 19:59:06 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD691B2A25 for ; Sun, 31 May 2015 19:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wQwBuT2FgK8g for ; Sun, 31 May 2015 19:59:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF3D1B2A24 for ; Sun, 31 May 2015 19:59:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTE02854; Mon, 01 Jun 2015 02:59:01 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Jun 2015 03:59:00 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 1 Jun 2015 10:58:56 +0800 From: "Dongjie (Jimmy)" To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt Thread-Index: AdCX0x/jsrMyNeBHQwaIxqAAuJBdzwEQnilA Date: Mon, 1 Jun 2015 02:58:54 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92757D5387B@nkgeml512-mbx.china.huawei.com> References: <014501d097d3$2886a230$7993e690$@olddog.co.uk> In-Reply-To: <014501d097d3$2886a230$7993e690$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: 'Loa Andersson' Subject: Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 02:59:05 -0000 Hi authors, I think this draft is useful and makes things clear. One minor nit in section 3.3: s/apply equally all possible uses/apply equally to all possible uses Best regards, Jie > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, May 27, 2015 12:44 AM > To: mpls@ietf.org > Cc: 'Loa Andersson' > Subject: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt >=20 > Hi, >=20 > Sasha, Loa, and I put together a short draft to clarify behavior wrt the = TTL and > TC fields of the label stack entry that contains the GAL. >=20 > Nothing dramatic, just tightening things up for a few issues reported to = us from > implementation/interop/field. >=20 > Review and comments actively sought. >=20 > Adrian >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 26 May 2015 17:37 > > To: Loa Andersson; Alexander Vainshtein; Adrian Farrel; Adrian Farrel; > > Sasha Vainshtein; Loa Andersson > > Subject: New Version Notification for > > draft-vainshtein-mpls-gal-tc-ttl-handling- > > 00.txt > > > > > > A new version of I-D, draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Name: draft-vainshtein-mpls-gal-tc-ttl-handling > > Revision: 00 > > Title: Handling the TC and TTL fields in a Label Stack Entry when the > > Generic Associated Channel Label is Present > > Document date: 2015-05-26 > > Group: Individual Submission > > Pages: 6 > > URL: > https://www.ietf.org/internet-drafts/draft-vainshtein-mpls-gal-tc-ttl- > > handling-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl- > > handling/ > > Htmlized: > https://tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling- > > 00 > > > > > > Abstract: > > This document clarifies handling of the Traffic Class (TC) and Time- > > to-Live (TTL) fields of a Label Stack Entry that contains the Generi= c > > Associated Channel (G-ACh) Label (GAL). These clarifications are > > intended to aid interoperability of implementations. > > > > Original handling was defined in RFC 5586, and this document updates > > that RFC. > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls