From amalis@gmail.com Sat Mar 3 10:33:00 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951B421F86B5; Sat, 3 Mar 2012 10:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdryaycb6Txb; Sat, 3 Mar 2012 10:32:59 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A971321F86B3; Sat, 3 Mar 2012 10:32:58 -0800 (PST) Received: by wicr5 with SMTP id r5so848304wic.31 for ; Sat, 03 Mar 2012 10:32:57 -0800 (PST) Received-SPF: pass (google.com: domain of amalis@gmail.com designates 10.180.79.229 as permitted sender) client-ip=10.180.79.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of amalis@gmail.com designates 10.180.79.229 as permitted sender) smtp.mail=amalis@gmail.com; dkim=pass header.i=amalis@gmail.com Received: from mr.google.com ([10.180.79.229]) by 10.180.79.229 with SMTP id m5mr5229522wix.6.1330799577951 (num_hops = 1); Sat, 03 Mar 2012 10:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=sgVMDnZADC2Fn2qNdEvC3A/P+rgst9R8f96hP7VJBXE=; b=J9b8lBxhNF91HBnOXZmHxYPIC5ItW0T8C6Ks6zjtxYbgkwsOHoyBArEj2oDIUZbprZ o10kgARVw9yc9oU8ZYr2UoKu2Cx30lhtxh+dVqXDq6vqgwh46hfqx1fUioBA8EpY6yml XZSyIyn7GuyVuO/TN8zg53Hjeh/hck031s0bIY1ds8nKmOLiVoLf48VRZ8sXeFc72KdE 1wylZKGkBPM1S21Q90HYPaR2W42ivYqWRGv0ECOizavN2tcDjCVxSFstZZUo5G/f3/FF DdiJ4n8JccbwirCE1UsXyIKYgtS8DKxDqRQ/SkZz5Vq7Wu6LWt6VlClBWGwhwZ/yM0h3 o6Jw== Received: by 10.180.79.229 with SMTP id m5mr4137364wix.6.1330799577851; Sat, 03 Mar 2012 10:32:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.106.1 with HTTP; Sat, 3 Mar 2012 10:32:37 -0800 (PST) From: "Andrew G. Malis" Date: Sat, 3 Mar 2012 13:32:37 -0500 Message-ID: To: The IESG Content-Type: multipart/alternative; boundary=f46d041826581ae71a04ba5aec28 Cc: pwe3@ietf.org, "Stewart Bryant \(stbryant\)" Subject: [PWE3] Publication request for draft-ietf-pwe3-pw-typed-wc-fec-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 18:33:00 -0000 --f46d041826581ae71a04ba5aec28 Content-Type: text/plain; charset=ISO-8859-1 The PWE3 working group requests the publication of draft-ietf-pwe3-pw-typed-wc-fec-03 as a Proposed Standard RFC. The document writeup is attached below. Thanks, Andy ------------- Document Writeup for draft-ietf-pwe3-pw-typed-wc-fec-03 As required by RFC 4858 , this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary An extension (RFC5918) to the Label Distribution Protocol (LDP) (RFC5036) defines the general notion of a "Typed Wildcard Forwarding Equivalence Class (FEC) Element". This can be used when it is desired to request all label bindings for a given type of FEC Element, or to release or withdraw all label bindings for a given type of FEC element. However, a typed wildcard FEC element must be individually defined for each type of FEC element. RFC4447 defines the "PWid FEC Element" and "Generalized PWid FEC Element", but does not specify the Typed Wildcard format for these elements. This document specifies the format of the Typed Wildcard FEC Element for the "PWid FEC Element" and "Generalized PWid FEC Element". The procedures for Typed Wildcard processing for PWid and Generalized PWid FEC Elements are same as described in RFC5918 for any typed wildcard FEC Element type. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was solid consensus in the working group regarding this draft, no controversy or anything rough. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? At least one implementation is in progress, but has not yet been deployed. There may be additional vendors with plans to implement. The draft received a good WG last call, which resulted in comments and a new revision. No particular expert review was necessary. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Andrew Malis and Stewart Bryant respectively. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has been reviewed by the shepherd for quality and completeness, and has also completed working group last call. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The authors have confirmed that they not aware of any IPR on the draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The draft has solid WG consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no nits according to the checker (I ran it myself). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. None. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. N/A (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA actions required. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A --f46d041826581ae71a04ba5aec28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The PWE3 working group requests the publication of draft-ietf-pwe3-pw-typed= -wc-fec-03 as a Proposed Standard RFC.

The document writeup is attac= hed below.

Thanks,
Andy

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

Document Writ= eup for draft-ietf-pwe3-pw-typed-wc-fec-03

As required by RFC 4858 </rfc/rfc4858.txt>, this is the current t= emplate
for the Document Shepherd Write-Up.

Changes are expected = over time. This version is dated 24 February 2012.

(1) What type of = RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?=A0 Why
is = this the proper type of RFC?=A0 Is this type of RFC indicated in the
tit= le page header?

Proposed Standard

(2) The IESG approval annou= ncement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
e= xamples can be found in the "Action" announcements for approveddocuments. The approval announcement contains the following sections:

Technical Summary

An extension (RFC5918) to the Label Distributi= on Protocol (LDP)
(RFC5036) defines the general notion of a "Typed = Wildcard Forwarding
Equivalence Class (FEC) Element".=A0 This can b= e used when it is
desired to request all label bindings for a given type of FEC
Element, o= r to release or withdraw all label bindings for a given
type of FEC elem= ent.=A0 However, a typed wildcard FEC element must be
individually defin= ed for each type of FEC element.

RFC4447 defines the "PWid FEC Element" and "Generalized = PWid FEC
Element", but does not specify the Typed Wildcard format f= or these
elements. This document specifies the format of the Typed Wildc= ard
FEC Element for the "PWid FEC Element" and "Generalized PWid= FEC
Element". The procedures for Typed Wildcard processing for PWi= d and
Generalized PWid FEC Elements are same as described in RFC5918 for=
any typed wildcard FEC Element type.

Working Group Summary

= =A0 Was there anything in WG process that is worth noting? For
=A0 exam= ple, was there controversy about particular points or
=A0 were there de= cisions where the consensus was particularly
=A0 rough?
=A0
There was solid consensus in the working group regard= ing this draft,
no controversy or anything rough.

Document Qualit= y

=A0 Are there existing implementations of the protocol? Have a =A0 significant number of vendors indicated their plan to
=A0 implement the specification? Are there any reviewers that
=A0 merit= special mention as having done a thorough review,
=A0 e.g., one that r= esulted in important changes or a
=A0 conclusion that the document had = no substantive issues? If
=A0 there was a MIB Doctor, Media Type or other expert review,
=A0 what= was its course (briefly)? In the case of a Media Type
=A0 review, on w= hat date was the request posted?
=A0
At least one implementation is = in progress, but has not yet been deployed.
There may be additional vendors with plans to implement.

The draft = received a good WG last call, which resulted in comments
and a new revis= ion. No particular expert review was necessary.

Personnel

=A0 Who is the Document Shepherd? Who is the Responsible Area
=A0 Direct= or?
=A0
Andrew Malis and Stewart Bryant respectively.

(3) Bri= efly describe the review of this document that was performed by
the Docu= ment Shepherd.=A0 If this version of the document is not ready
for publication, please explain why the document is being forwarded to
t= he IESG.

The document has been reviewed by the shepherd for quality = and completeness,
and has also completed working group last call.

(4) Does the document Shepherd have any concerns about the depth or
= breadth of the reviews that have been performed?=A0

No.

(5) = Do portions of the document need review from a particular or from
broade= r perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took= place.

No.

(6) Describe any specific concerns or issues that= the Document Shepherd
has with this document that the Responsible Area = Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortablewith certain parts of the document, or has concerns whether there reallyis a need for it. In any event, if the WG has discussed those issues and<= br> has indicated that it still wishes to advance the document, detail thoseconcerns here.

None.

(7) Has each author confirmed that any = and all appropriate IPR
disclosures required for full conformance with t= he provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The authors= have confirmed that they not aware of any IPR on the draft.

(8) Has= an IPR disclosure been filed that references this document?
If so, summ= arize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed.

(9) How soli= d is the WG consensus behind this document? Does it
represent the stron= g concurrence of a few individuals, with others
being silent, or does th= e WG as a whole understand and agree with it?

The draft has solid WG consensus.

(10) Has anyone threatened an = appeal or otherwise indicated extreme
discontent? If so, please summari= ze the areas of conflict in separate
email messages to the Responsible A= rea Director. (It should be in a
separate email because this questionnaire is publicly available.)

N= o.

(11) Identify any ID nits the Document Shepherd has found in this=
document. (See http://www= .ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
th= orough.

There are no nits according to the checker (I ran it myself)= .

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

= N/A

(13) Have all references within this document been identified as=
either normative or informative?

Yes.

(14) Are there norm= ative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
refe= rences exist, what is the plan for their completion?

No.

(15)= Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in theLast Call procedure.

None.

(16) Will publication of this d= ocument change the status of any
existing RFCs? Are those RFCs listed on= the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
= listed in the Abstract and Introduction, explain why, and point to the
p= art of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describ= e the Document Shepherd's review of the IANA considerations
section,= especially with regard to its consistency with the body of the
document= . Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Con= firm that any referenced IANA registries have been clearly
identified. C= onfirm that newly created IANA registries include a
detailed specificati= on of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reaso= nable name for the new registry has been suggested (see RFC 5226).

T= here are no IANA actions required.

(18) List any new IANA registries= that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful= in selecting the IANA Experts for these new registries.

N/A

= (19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
langua= ge, such as XML code, BNF rules, MIB definitions, etc.

N/A

--f46d041826581ae71a04ba5aec28-- From david.sinicrope@ericsson.com Mon Mar 5 16:29:15 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E756621E8036 for ; Mon, 5 Mar 2012 16:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySpoNjW7s4IL for ; Mon, 5 Mar 2012 16:29:15 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D2F4621E8037 for ; Mon, 5 Mar 2012 16:29:14 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q260TD1t026862 for ; Mon, 5 Mar 2012 18:29:14 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.46]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 5 Mar 2012 19:29:08 -0500 From: David Sinicrope To: "IETF.PWE3" Date: Mon, 5 Mar 2012 19:29:06 -0500 Thread-Topic: [PWE3] PWE3 IETF 83 Slot Requests Thread-Index: Acz7MCSTQoN0tZ0kRMS4nVpgq0THgQ== Message-ID: In-Reply-To: <5F95DE27-BD4D-414A-BD1E-A2969CD7EA2B@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 IETF 83 Slot Requests X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 00:29:16 -0000 Hi All, I've started to put together the Paris PWE3 agenda based on the requests I've received to date. Please check out:=20 http://www.ietf.org/proceedings/83/agenda/agenda-83-pwe3.txt (running order is subject to change) If you have requested a slot, please make sure I've reflected it accurately.=20 If you need a slot and haven't yet requested one, please refer to the email below. If you have questions, please send them to the list. Thanks, Dave=20 -----Original Message----- From: David A Sinicrope Date: Fri, 24 Feb 2012 03:11:36 -0500 To: "IETF.PWE3" Subject: [PWE3] PWE3 IETF 83 Slot Requests >Hi All, >If you need a presentation slot for the IETF 83 PWE3 session, please >reply to this email (subject intact) with: >-topic >-draft name >-requested duration >-speaker > >Thanks, >Dave > > >On Feb 23, 2012, at 3:45 PM, "Malis, Andrew G (Andy)" >> wrote: > > > >Cheers, >Andy >Sent from my Verizon DROID 3 > > >-----Original Message----- >From: "IETF Secretariat" [agenda@ietf.org] >Sent: Thursday, February 23, 2012 03:43 PM Eastern Standard Time >To:=20 >matthew.bocci@alcatel-lucent.com >Cc: pwe3-ads@tools.ietf.org; >pwe3-chairs@tools.ietf.org; >wlo@amsl.com >Subject: pwe3 - Requested session has been scheduled for IETF 83 > > >Dear Matthew Bocci, > >The sessions that you have requested have been scheduled. >Below is the scheduled session information followed by >the original request. > >pwe3 Session 1 (2.5 hours) > Thursday, Morning Session I 0930-1130 > Room Name: 242AB > --------------------------------------------- > > > >Request Information: > >--------------------------------------------------------- >Working Group Name: Pseudowire Emulation Edge to Edge >Area Name: Routing Area >Session Requester: Wanda Lo > >Number of Sessions: 1 >Length of Session(s): 2.5 hours >Number of Attendees: 120 >Conflicts to Avoid: > First Priority: ccamp l2vpn l3vpn mpls tictoc ancp rtgarea rtgwg > Second Priority: intarea > > > > >Special Requests: > >--------------------------------------------------------- > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From iesg-secretary@ietf.org Wed Mar 7 08:33:05 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFA721F8677; Wed, 7 Mar 2012 08:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwrVQ-DsqYpe; Wed, 7 Mar 2012 08:33:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7422221F864F; Wed, 7 Mar 2012 08:33:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307163304.11989.2410.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 08:33:04 -0800 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:33:05 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Mar 7 08:59:53 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2507F21F860F; Wed, 7 Mar 2012 08:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWJQX4ZqQiKF; Wed, 7 Mar 2012 08:59:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1EF21F85AD; Wed, 7 Mar 2012 08:59:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307165952.19747.14674.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 08:59:52 -0800 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Pseudowire Redundancy) to Informational RFC X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:59:53 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Redundancy' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single segment PW applications, or between Terminating PE nodes in Multi-Segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Mar 7 09:00:36 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73021F8777; Wed, 7 Mar 2012 09:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU55D-bZYVhE; Wed, 7 Mar 2012 09:00:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853B321E80B2; Wed, 7 Mar 2012 09:00:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 09:00:32 -0800 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:00:36 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. From stbryant@cisco.com Wed Mar 7 09:47:38 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB5521E80B1; Wed, 7 Mar 2012 09:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk+DdIp010NR; Wed, 7 Mar 2012 09:47:36 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1521E8017; Wed, 7 Mar 2012 09:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2468; q=dns/txt; s=iport; t=1331142456; x=1332352056; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oIzDZmDtj9WF8gdcCGmGIVhI7NDXgMWrvnYnDPuQFcY=; b=FFKricc0UIOWwiuFo8k9D6UF8XHAgQeWTRei8ZOa1g+ubh06RWes/KMS pCBve87G5OYkNynYwRlAU66Ou9dd2ZPol3mKw79q76ZYuDQ8iapHc50uM FkUcfZhSWAVxJ//pVqLWpMmik8fAy4WP9z/74p1Nc/KJgTaL0qv4+bBSI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEKeV0+Q/khN/2dsb2JhbABEtR2BB4IKAQEBBAEBAQ8BAgEiNgoBEAsYCRYECwkDAgECARUfERMBBQIBAR6HZguaPwGDMQ8Bm1mNTYMiBJVBkBeCYw X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208";a="131622045" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 07 Mar 2012 17:47:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27HlYjR006994; Wed, 7 Mar 2012 17:47:34 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q27HlVTN011204; Wed, 7 Mar 2012 17:47:32 GMT Message-ID: <4F579F33.7050508@cisco.com> Date: Wed, 07 Mar 2012 17:47:31 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> In-Reply-To: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, ietf@ietf.org Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:47:38 -0000 Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: "This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: " This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: > The IESG has received a request from the Pseudowire Emulation Edge to > Edge WG (pwe3) to consider the following document: > - 'Pseudowire Preferential Forwarding Status Bit' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes a mechanism for standby status signaling of > redundant pseudowires (PWs) between their termination points. A set > of redundant PWs is configured between provider edge (PE) nodes in > single-segment pseudowire (SS-PW) applications, or between > terminating provider edge (T-PE) nodes in multi-segment pseudowire > (MS-PW) applications. > > In order for the PE/T-PE nodes to indicate the preferred PW to use > for forwarding PW packets to one another, a new status bit is needed > to indicate a preferential forwarding status of Active or Standby for > each PW in a redundant set. > > In addition, a second status bit is defined to allow peer PE nodes to > coordinate a switchover operation of the PW. > > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From mustapha.aissaoui@alcatel-lucent.com Wed Mar 7 09:49:48 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D8421F84E0; Wed, 7 Mar 2012 09:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.12 X-Spam-Level: X-Spam-Status: No, score=-9.12 tagged_above=-999 required=5 tests=[AWL=1.479, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhljSYyt8VRa; Wed, 7 Mar 2012 09:49:47 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3898921F84DE; Wed, 7 Mar 2012 09:49:47 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q27HnjZn012214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Mar 2012 11:49:45 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q27HniUO018423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 11:49:44 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 7 Mar 2012 11:49:44 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "stbryant@cisco.com" , "draft-ietf-pwe3-redundancy-bit@tools.ietf.org" Date: Wed, 7 Mar 2012 11:49:43 -0600 Thread-Topic: Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Thread-Index: Acz8imr3BjHtt4oFQ6a+R4rxvz1BRQAACvjg Message-ID: <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> In-Reply-To: <4F579F33.7050508@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "pwe3@ietf.org" , "ietf@ietf.org" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:49:48 -0000 Ooops. Thank you for pointing this out Stewart. I will make the update and = publish a new revision. Mustapha.=20 -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org Cc: ietf@ietf.org; pwe3@ietf.org Subject: Re: Last Call: (Pseudowire= Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD revie= w and so I am picking it up as a LC comment: In section 10 you say: "This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: " This update should be recorded in the metadata (top left front page) and it= is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: > The IESG has received a request from the Pseudowire Emulation Edge to=20 > Edge WG (pwe3) to consider the following document: > - 'Pseudowire Preferential Forwarding Status Bit' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits=20 > final comments on this action. Please send substantive comments to the=20 > ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may=20 > be sent to iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes a mechanism for standby status signaling of > redundant pseudowires (PWs) between their termination points. A set > of redundant PWs is configured between provider edge (PE) nodes in > single-segment pseudowire (SS-PW) applications, or between > terminating provider edge (T-PE) nodes in multi-segment pseudowire > (MS-PW) applications. > > In order for the PE/T-PE nodes to indicate the preferred PW to use > for forwarding PW packets to one another, a new status bit is needed > to indicate a preferential forwarding status of Active or Standby for > each PW in a redundant set. > > In addition, a second status bit is defined to allow peer PE nodes to > coordinate a switchover operation of the PW. > > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From amalis@gmail.com Wed Mar 7 09:53:30 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607BB21F8555; Wed, 7 Mar 2012 09:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUr20WSm3W8f; Wed, 7 Mar 2012 09:53:29 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 488AF21F8531; Wed, 7 Mar 2012 09:53:29 -0800 (PST) Received: by ghbg16 with SMTP id g16so3442901ghb.31 for ; Wed, 07 Mar 2012 09:53:28 -0800 (PST) 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=pDLkcToLNAj06QnJfDYdNqD1vbg4kui48szl1unZUhU=; b=HvjSXe9xmFhAxJcAzoAbuMskIU/l25vvJnXHhgXLpqW7Eijb36mxuJhyDLhhR4AyrU HUXsegiROa216re00qT524PtTE7Uyxwz0IcpVHcoYyPStr9PH6jqSBTE5tfKGUreaKHN uH3cCwzf1RkACmUtw4oFSPEHqw3/PfRxXPr/c/oUvCcSP0qov/IJMPk2gcmQjw3fag+D 4Lek1QOdzvsTx2DkHRWidWhO+GPoq0p1k0v081sfs4AifRHZ74yiDNj22GsYiMsCaU4n xwi96+f9z/T1pVQDhNrwLpA7IH+5/wY+jlcw3KYes/ELLZxPQc0LUdOPXmfjI4IzI6BB rsnA== Received: by 10.236.43.68 with SMTP id k44mr5722304yhb.77.1331142808879; Wed, 07 Mar 2012 09:53:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.164.19 with HTTP; Wed, 7 Mar 2012 09:53:08 -0800 (PST) In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Andrew G. Malis" Date: Wed, 7 Mar 2012 09:53:08 -0800 Message-ID: To: "Aissaoui, Mustapha (Mustapha)" Content-Type: multipart/alternative; boundary=20cf300e543344c30b04baaad673 Cc: "draft-ietf-pwe3-redundancy-bit@tools.ietf.org" , "pwe3@ietf.org" , "ietf@ietf.org" , "stbryant@cisco.com" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:53:30 -0000 --20cf300e543344c30b04baaad673 Content-Type: text/plain; charset=ISO-8859-1 Mustapha, You might want to wait for any other LC comments before updating. Thanks, Andy On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha) < mustapha.aissaoui@alcatel-lucent.com> wrote: > Ooops. Thank you for pointing this out Stewart. I will make the update and > publish a new revision. > > Mustapha. > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, March 07, 2012 12:48 PM > To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org > Cc: ietf@ietf.org; pwe3@ietf.org > Subject: Re: Last Call: > (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard > > > Authors > > There was on point that I notice that you did not address from the AD > review and so I am picking it up as a LC comment: > > In section 10 you say: > > "This document makes the following update to the PwOperStatusTC > textual convention in RFC5542 [8]: " > > This update should be recorded in the metadata (top left front page) and > it is usual to put a one line note in the abstract. > > Stewart > > > > On 07/03/2012 17:00, The IESG wrote: > > The IESG has received a request from the Pseudowire Emulation Edge to > > Edge WG (pwe3) to consider the following document: > > - 'Pseudowire Preferential Forwarding Status Bit' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may > > be sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes a mechanism for standby status signaling of > > redundant pseudowires (PWs) between their termination points. A set > > of redundant PWs is configured between provider edge (PE) nodes in > > single-segment pseudowire (SS-PW) applications, or between > > terminating provider edge (T-PE) nodes in multi-segment pseudowire > > (MS-PW) applications. > > > > In order for the PE/T-PE nodes to indicate the preferred PW to use > > for forwarding PW packets to one another, a new status bit is needed > > to indicate a preferential forwarding status of Active or Standby for > > each PW in a redundant set. > > > > In addition, a second status bit is defined to allow peer PE nodes to > > coordinate a switchover operation of the PW. > > > > > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --20cf300e543344c30b04baaad673 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mustapha,

You might want to wait for any other LC comments before up= dating.

Thanks,
Andy

On Wed, Ma= r 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha) <<= a href=3D"mailto:mustapha.aissaoui@alcatel-lucent.com">mustapha.aissaoui@al= catel-lucent.com> wrote:
Ooops. Thank you for pointing this out Stewa= rt. I will make the update and publish a new revision.

Mustapha.

-----Original Message-----
From: Stewart Bryant [mailto:stbryant= @cisco.com]
Sent: Wednesday, March 07, 2012 12:48 PM
To: draft-= ietf-pwe3-redundancy-bit@tools.ietf.org
Cc: ietf@ietf.org; pwe3@ietf.org
Subject: Re: Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseu= dowire Preferential Forwarding Status Bit) to Proposed Standard


Authors

There was on point that I notice that you did not address from the AD revie= w and so I am picking it up as a LC comment:

In section 10 you say:

=A0 =A0"This document makes the following update to the PwOperStatusT= C
=A0 =A0textual convention in RFC5542 [8]: "

This update should be recorded in the metadata (top left front page) and it= is usual to put a one line note in the abstract.

Stewart



On 07/03/2012 17:00, The IESG wrote:
> The IESG has received a request from the Pseudowire Emulation Edge to<= br> > Edge WG (pwe3) to consider the following document:
> - 'Pseudowire Preferential Forwarding Status Bit'
> =A0 =A0<draft-ietf-pwe3-redundancy-bit-06.txt> =A0as a Proposed = Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 20= 12-03-21. Exceptionally, comments may
> be sent to iesg@ietf.org instead.= In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> =A0 =A0 This document describes a mechanism for standby status signali= ng of
> =A0 =A0 redundant pseudowires (PWs) between their termination points. = A set
> =A0 =A0 of redundant PWs is configured between provider edge (PE) node= s in
> =A0 =A0 single-segment pseudowire (SS-PW) applications, or between
> =A0 =A0 terminating provider edge (T-PE) nodes in multi-segment pseudo= wire
> =A0 =A0 (MS-PW) applications.
>
> =A0 =A0 In order for the PE/T-PE nodes to indicate the preferred PW to= use
> =A0 =A0 for forwarding PW packets to one another, a new status bit is = needed
> =A0 =A0 to indicate a preferential forwarding status of Active or Stan= dby for
> =A0 =A0 each PW in a redundant set.
>
> =A0 =A0 In addition, a second status bit is defined to allow peer PE n= odes to
> =A0 =A0 coordinate a switchover operation of the PW.
>
>
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-red= undancy-bit/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-p= we3-redundancy-bit/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce
>


--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html


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

--20cf300e543344c30b04baaad673-- From mustapha.aissaoui@alcatel-lucent.com Wed Mar 7 09:55:45 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5661621F850B; Wed, 7 Mar 2012 09:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.233 X-Spam-Level: X-Spam-Status: No, score=-9.233 tagged_above=-999 required=5 tests=[AWL=1.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIarkYKasEXh; Wed, 7 Mar 2012 09:55:44 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 54CF821F8499; Wed, 7 Mar 2012 09:55:44 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q27HtfTV014460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Mar 2012 11:55:41 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q27Htfff016717 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 11:55:41 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 7 Mar 2012 11:55:41 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "Andrew G. Malis" Date: Wed, 7 Mar 2012 11:55:40 -0600 Thread-Topic: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Thread-Index: Acz8izeZXI9/dkIbSZqtuo9E9fuJLwAADwaw Message-ID: <5DF53972F7E9134782DCE51624466FE50AD5811DB2@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DF53972F7E9134782DCE51624466FE50AD5811DB2USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "draft-ietf-pwe3-redundancy-bit@tools.ietf.org" , "pwe3@ietf.org" , "ietf@ietf.org" , "stbryant@cisco.com" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:55:45 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD5811DB2USNAVSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable makes sense Andy. Thanks, Mustapha. ________________________________ From: Andrew G. Malis [mailto:amalis@gmail.com] Sent: Wednesday, March 07, 2012 12:53 PM To: Aissaoui, Mustapha (Mustapha) Cc: stbryant@cisco.com; draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3= @ietf.org; ietf@ietf.org Subject: Re: [PWE3] Last Call: (Pse= udowire Preferential Forwarding Status Bit) to Proposed Standard Mustapha, You might want to wait for any other LC comments before updating. Thanks, Andy On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha) > wrot= e: Ooops. Thank you for pointing this out Stewart. I will make the update and = publish a new revision. Mustapha. -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org Cc: ietf@ietf.org; pwe3@ietf.org Subject: Re: Last Call: (Pseudowire= Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD revie= w and so I am picking it up as a LC comment: In section 10 you say: "This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: " This update should be recorded in the metadata (top left front page) and it= is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: > The IESG has received a request from the Pseudowire Emulation Edge to > Edge WG (pwe3) to consider the following document: > - 'Pseudowire Preferential Forwarding Status Bit' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-03-21. Exceptio= nally, comments may > be sent to iesg@ietf.org instead. In either case, p= lease retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes a mechanism for standby status signaling of > redundant pseudowires (PWs) between their termination points. A set > of redundant PWs is configured between provider edge (PE) nodes in > single-segment pseudowire (SS-PW) applications, or between > terminating provider edge (T-PE) nodes in multi-segment pseudowire > (MS-PW) applications. > > In order for the PE/T-PE nodes to indicate the preferred PW to use > for forwarding PW packets to one another, a new status bit is needed > to indicate a preferential forwarding status of Active or Standby for > each PW in a redundant set. > > In addition, a second status bit is defined to allow peer PE nodes to > coordinate a switchover operation of the PW. > > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_5DF53972F7E9134782DCE51624466FE50AD5811DB2USNAVSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
makes sense Andy.
 
Thanks,
Mustapha.

From: Andrew G. Malis [mailto:amalis@gm= ail.com]=20
Sent: Wednesday, March 07, 2012 12:53 PM
To: Aissaoui,= =20 Mustapha (Mustapha)
Cc: stbryant@cisco.com;=20 draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3@ietf.org;=20 ietf@ietf.org
Subject: Re: [PWE3] Last Call:=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard

Mustapha,

You might want to wait for any other LC comment= s=20 before updating.

Thanks,
Andy

On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha= =20 (Mustapha) <mustapha.aissaoui@alca= tel-lucent.com>=20 wrote:
Ooops. Thank you for pointing this out Stewart. I will = make=20 the update and publish a new revision.

Mustapha.

-----Original Message-----
From: Stewart Bryant=20 [mailto:stbryant@cisco.com]
= Sent:=20 Wednesday, March 07, 2012 12:48 PM
To: draft-ietf-= pwe3-redundancy-bit@tools.ietf.org
Cc:=20 ietf@ietf.org; pwe3@ietf.org
Subject: Re: Last Call= :=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard


Authors

The= re=20 was on point that I notice that you did not address from the AD review an= d so=20 I am picking it up as a LC comment:

In section 10 you=20 say:

   "This document makes the following update to the= =20 PwOperStatusTC
   textual convention in RFC5542 [8]:=20 "

This update should be recorded in the metadata (top left front p= age)=20 and it is usual to put a one line note in the=20 abstract.

Stewart



On 07/03/2012 17:00, The IESG=20 wrote:
> The IESG has received a request from the Pseudowire Emulat= ion=20 Edge to
> Edge WG (pwe3) to consider the following document:
>= ; -=20 'Pseudowire Preferential Forwarding Status Bit'
>  =20  <draft-ietf-pwe3-redundancy-bit-06.txt>  as a Proposed=20 Standard
>
> The IESG plans to make a decision in the next fe= w=20 weeks, and solicits
> final comments on this action. Please send=20 substantive comments to the
> ietf@ietf.org mailing lists by 2012-03-= 21.=20 Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, = please=20 retain the
> beginning of the Subject line to allow automated=20 sorting.
>
> Abstract
>
>
>     T= his=20 document describes a mechanism for standby status signaling of
> &n= bsp;=20   redundant pseudowires (PWs) between their termination points. A=20 set
>     of redundant PWs is configured between provider= edge=20 (PE) nodes in
>     single-segment pseudowire (SS-PW)=20 applications, or between
>     terminating provider edge= =20 (T-PE) nodes in multi-segment pseudowire
>     (MS-PW)=20 applications.
>
>     In order for the PE/T-PE node= s to=20 indicate the preferred PW to use
>     for forwarding PW= =20 packets to one another, a new status bit is needed
>     = to=20 indicate a preferential forwarding status of Active or Standby for
>= ;=20     each PW in a redundant set.
>
>     I= n=20 addition, a second status bit is defined to allow peer PE nodes to
>= ;=20     coordinate a switchover operation of the=20 PW.
>
>
>
>
>
>
> The file can = be=20 obtained via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundanc= y-bit/
>
>=20 IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundanc= y-bit/ballot/
>
>
>=20 No IPR declarations have been submitted directly on this=20 I-D.
>
>
>=20 _______________________________________________
> IETF-Announce mai= ling=20 list
> IETF-Announce@ietf.org
>= https://www.ietf.org/mailman/listinfo/ietf-announce>


--
For=20 corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/i= ndex.html


_______________________________________________pwe3=20 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
<= /DIV>

--_000_5DF53972F7E9134782DCE51624466FE50AD5811DB2USNAVSXCHMBSC_-- From tnadeau@lucidvision.com Wed Mar 7 11:31:40 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948A111E8091; Wed, 7 Mar 2012 11:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e7K5c1p7gZa; Wed, 7 Mar 2012 11:31:39 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFFF11E8085; Wed, 7 Mar 2012 11:31:39 -0800 (PST) Received: from [192.168.1.53] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E0E2217F66A; Wed, 7 Mar 2012 14:31:38 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Date: Wed, 7 Mar 2012 14:31:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <70493619-9792-49DF-AAA4-C81074854CF7@lucidvision.com> References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> To: "Aissaoui, Mustapha (Mustapha)" X-Mailer: Apple Mail (2.1257) Cc: "draft-ietf-pwe3-redundancy-bit@tools.ietf.org" , "pwe3@ietf.org" , "ietf@ietf.org" , "stbryant@cisco.com" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:31:40 -0000 After looking over this just now - and forgive me as I didn't = realize it contained a reference to 5542 until now - it seems to me that = rather that including this in the RFC as "an update to RFC5542", this be = added as an errata entry to 5542. It seems odd to me to note that the = single sentence represented here "updates" the RFC version, when what it = does is really clarify it based on the new behavior outlined in the = redundancy-bit draft, and even then "clarify" is difficult to use since = it is more of an example of such a case of a 'dormant' interface. --Tom On Mar 7, 2012, at 12:49 PM, Aissaoui, Mustapha (Mustapha) wrote: > Ooops. Thank you for pointing this out Stewart. I will make the update = and publish a new revision. >=20 > Mustapha.=20 >=20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: Wednesday, March 07, 2012 12:48 PM > To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org > Cc: ietf@ietf.org; pwe3@ietf.org > Subject: Re: Last Call: = (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard >=20 >=20 > Authors >=20 > There was on point that I notice that you did not address from the AD = review and so I am picking it up as a LC comment: >=20 > In section 10 you say: >=20 > "This document makes the following update to the PwOperStatusTC > textual convention in RFC5542 [8]: " >=20 > This update should be recorded in the metadata (top left front page) = and it is usual to put a one line note in the abstract. >=20 > Stewart >=20 >=20 >=20 > On 07/03/2012 17:00, The IESG wrote: >> The IESG has received a request from the Pseudowire Emulation Edge to=20= >> Edge WG (pwe3) to consider the following document: >> - 'Pseudowire Preferential Forwarding Status Bit' >> as a Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits=20= >> final comments on this action. Please send substantive comments to = the=20 >> ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments = may=20 >> be sent to iesg@ietf.org instead. In either case, please retain the=20= >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This document describes a mechanism for standby status signaling = of >> redundant pseudowires (PWs) between their termination points. A = set >> of redundant PWs is configured between provider edge (PE) nodes in >> single-segment pseudowire (SS-PW) applications, or between >> terminating provider edge (T-PE) nodes in multi-segment pseudowire >> (MS-PW) applications. >>=20 >> In order for the PE/T-PE nodes to indicate the preferred PW to use >> for forwarding PW packets to one another, a new status bit is = needed >> to indicate a preferential forwarding status of Active or Standby = for >> each PW in a redundant set. >>=20 >> In addition, a second status bit is defined to allow peer PE nodes = to >> coordinate a switchover operation of the PW. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ >>=20 >> IESG discussion can be tracked via >> = http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >>=20 >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From stbryant@cisco.com Wed Mar 7 11:46:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFDF11E8086; Wed, 7 Mar 2012 11:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.577 X-Spam-Level: X-Spam-Status: No, score=-110.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwsFuvUK0cOr; Wed, 7 Mar 2012 11:46:06 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC811E8072; Wed, 7 Mar 2012 11:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4568; q=dns/txt; s=iport; t=1331149554; x=1332359154; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mjcA3jxwM7v2vhJflGsVM3nRRY2EzDcgVmyc16euwBk=; b=bg+XTg4vADaUyM58PYsY1uO26iQ73kHwV8HTPKacF1TQ+mRU9SRS+oYN +RX3YYeHWUj58bU2UGqifz5JrQiluvqb4fA4zkUIr9M4RLrRBEvIw6dNw UIKauc3sFbbcq1NEEz1HigFcEdrSlkrdB4qka0AqL9ndT+GroeHKCmyVN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALO5V0+Q/khL/2dsb2JhbABEtSKBB4IKAQEBBAEBAQ8BAgEiNgoBDAQLDgMEAQEBCRYEBAcJAwIBAgEVHwkIBg0BBQIBAR6HZguaRgGDMQ8Bm0mQbwSVQZAXgmM X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208";a="67929983" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 07 Mar 2012 19:45:53 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q27Jjr5M007355; Wed, 7 Mar 2012 19:45:53 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q27JjqsX019064; Wed, 7 Mar 2012 19:45:52 GMT Message-ID: <4F57BAEF.6090007@cisco.com> Date: Wed, 07 Mar 2012 19:45:51 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Thomas Nadeau References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <70493619-9792-49DF-AAA4-C81074854CF7@lucidvision.com> In-Reply-To: <70493619-9792-49DF-AAA4-C81074854CF7@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Aissaoui, Mustapha \(Mustapha\)" , "draft-ietf-pwe3-redundancy-bit@tools.ietf.org" , "pwe3@ietf.org" , "ietf@ietf.org" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:46:07 -0000 It cannot be an erratum. An erratum indicated an error a the time of writing and that is clearly not the case. Is the text " For example, the PW Preferential Forwarding status state machine as defined in [RFCXXXX (this document)] is in state "STANDBY". " actually in the MIB definition itself? If so it's an update to the MIB (as explained in the draft). If not then why not simply explain the event's action on the MIB and not update the MIB itself? - Stewart On 07/03/2012 19:31, Thomas Nadeau wrote: > After looking over this just now - and forgive me as I didn't realize it contained a reference to 5542 until now - it seems to me that rather that including this in the RFC as "an update to RFC5542", this be added as an errata entry to 5542. It seems odd to me to note that the single sentence represented here "updates" the RFC version, when what it does is really clarify it based on the new behavior outlined in the redundancy-bit draft, and even then "clarify" is difficult to use since it is more of an example of such a case of a 'dormant' interface. > > --Tom > > > On Mar 7, 2012, at 12:49 PM, Aissaoui, Mustapha (Mustapha) wrote: > >> Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision. >> >> Mustapha. >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Wednesday, March 07, 2012 12:48 PM >> To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org >> Cc: ietf@ietf.org; pwe3@ietf.org >> Subject: Re: Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard >> >> >> Authors >> >> There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: >> >> In section 10 you say: >> >> "This document makes the following update to the PwOperStatusTC >> textual convention in RFC5542 [8]: " >> >> This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. >> >> Stewart >> >> >> >> On 07/03/2012 17:00, The IESG wrote: >>> The IESG has received a request from the Pseudowire Emulation Edge to >>> Edge WG (pwe3) to consider the following document: >>> - 'Pseudowire Preferential Forwarding Status Bit' >>> as a Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may >>> be sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document describes a mechanism for standby status signaling of >>> redundant pseudowires (PWs) between their termination points. A set >>> of redundant PWs is configured between provider edge (PE) nodes in >>> single-segment pseudowire (SS-PW) applications, or between >>> terminating provider edge (T-PE) nodes in multi-segment pseudowire >>> (MS-PW) applications. >>> >>> In order for the PE/T-PE nodes to indicate the preferred PW to use >>> for forwarding PW packets to one another, a new status bit is needed >>> to indicate a preferential forwarding status of Active or Standby for >>> each PW in a redundant set. >>> >>> In addition, a second status bit is defined to allow peer PE nodes to >>> coordinate a switchover operation of the PW. >>> >>> >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From internet-drafts@ietf.org Sun Mar 11 09:10:50 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7E421F8656; Sun, 11 Mar 2012 09:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9WwO6SI7Zgf; Sun, 11 Mar 2012 09:10:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B28221F862A; Sun, 11 Mar 2012 09:10:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120311161049.32438.62702.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 09:10:49 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-p2mp-pw-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 16:10:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Signaling Root-Initiated Point-to-Multipoint Pseudowire = using LDP Author(s) : Siva Sivabalan Sami Boutros Luca Martini Filename : draft-ietf-pwe3-p2mp-pw-04.txt Pages : 22 Date : 2012-03-11 This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-04.txt From mach.chen@huawei.com Mon Mar 12 00:37:57 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91521F85E0 for ; Mon, 12 Mar 2012 00:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtVmcoy4BkjX for ; Mon, 12 Mar 2012 00:37:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B75FE21F85B1 for ; Mon, 12 Mar 2012 00:37:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00II8H0E8G@szxga04-in.huawei.com> for pwe3@ietf.org; Mon, 12 Mar 2012 15:33:50 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00FSYH09YU@szxga04-in.huawei.com> for pwe3@ietf.org; Mon, 12 Mar 2012 15:33:50 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHT43928; Mon, 12 Mar 2012 15:33:50 +0800 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 15:33:25 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.52]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Mon, 12 Mar 2012 15:33:45 +0800 Date: Mon, 12 Mar 2012 07:33:45 +0000 From: Mach Chen X-Originating-IP: [10.108.4.51] To: "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt Thread-index: AQHNABk1f/qfMGDSzkyu01qa6/PuXJZmQZlg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [PWE3] FW: New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 07:37:57 -0000 Hi, We just submitted a new version of the explicit PW to LSP binding draft (http://tools.ietf.org/html/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05), based on the received comments, the Abstract and part of the Introduction section has been rewrote to make the problem statement and requirements more clear, we'd appreciate you could spend some time to review it, any comments are welcome! Many thanks, Mach > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, March 12, 2012 2:27 PM > To: Mach Chen > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Wayne Cao(wei) > Subject: New Version Notification for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt has been > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > Revision: 05 > Title: LDP extensions for Pseudowire Binding to LSP Tunnels > Creation date: 2012-03-11 > WG ID: Individual Submission > Number of pages: 15 > > Abstract: > Many transport services require that user traffic, in the forms of > Pseudowires (PW), to be delivered on a single co-routed bidirectional > LSP or two LSPs that share the same routes. In addition, the user > traffic may traverse through multiple transport networks. > > This document specifies an optional extension in LDP that enable the > binding between PWs and the underlying LSPs. > > > > > > The IETF Secretariat From jie.dong@huawei.com Mon Mar 12 01:13:53 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2339621F84F6 for ; Mon, 12 Mar 2012 01:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDP4mNkZ-S8v for ; Mon, 12 Mar 2012 01:13:52 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id F383B21F845F for ; Mon, 12 Mar 2012 01:13:47 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00DLWIT9DF@szxga04-in.huawei.com> for pwe3@ietf.org; Mon, 12 Mar 2012 16:12:45 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00933ISC4J@szxga04-in.huawei.com> for pwe3@ietf.org; Mon, 12 Mar 2012 16:12:45 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHT49713; Mon, 12 Mar 2012 16:12:45 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 16:12:43 +0800 Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.44]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 12 Mar 2012 16:12:41 +0800 Date: Mon, 12 Mar 2012 08:12:41 +0000 From: Jie Dong X-Originating-IP: [10.108.4.103] To: "pwe3@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C92723448D01@szxeml538-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: FW: I-D Action: draft-dong-pwe3-redundancy-spe-01.txt Thread-index: Ac0AJ+UYjWxQtXzQSu+f8I/Q8I2QDw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [PWE3] FW: I-D Action: draft-dong-pwe3-redundancy-spe-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:13:53 -0000 Hi all, We have submitted a new version of draft-dong-pwe3-redundancy-spe. A new section "VCCV considerations" is added in this revision. Any comments would be appreciated. Best regards, Jie > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, March 09, 2012 5:33 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-dong-pwe3-redundancy-spe-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Pseudowire Redundancy on S-PE > Author(s) : Jie Dong > Haibo Wang > Filename : draft-dong-pwe3-redundancy-spe-01.txt > Pages : 7 > Date : 2012-03-09 > > This document describes Multi-Segment Pseudowire (MS-PW) protection > scenarios in which the pseudowire redundancy is provided on the > Switching-PE (S-PE). Signaling of preferential forwarding defined in > [I-D.ietf-pwe3-redundancy-bit] is reused. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-dong-pwe3-redundancy-spe-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-dong-pwe3-redundancy-spe-01.txt > From adrian@olddog.co.uk Mon Mar 12 13:25:29 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100F711E8089 for ; Mon, 12 Mar 2012 13:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smrPQZ4AA3kU for ; Mon, 12 Mar 2012 13:25:27 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 259EA11E8075 for ; Mon, 12 Mar 2012 13:25:26 -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 q2CKPMsp029254 for ; Mon, 12 Mar 2012 20:25:23 GMT Received: from 950129200 ([90.84.144.69]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2CKPLQL029242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Mar 2012 20:25:22 GMT From: "Adrian Farrel" To: Date: Mon, 12 Mar 2012 20:25:23 -0000 Message-ID: <033a01cd008e$41978ee0$c4c6aca0$@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: Ac0AjggZ8XBr/0nYThu4o6fpFU4Xwg== Content-Language: en-gb Subject: [PWE3] heads up : I-D Action: draft-yong-trill-trill-o-mpls-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:25:29 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 12 March 2012 18:51 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-yong-trill-trill-o-mpls-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Transparent Interconnection of Lots of Links (TRILL) over MPLS > Pseudo Wires > Author(s) : Lucy Yong > Donald E. Eastlake > Sam Aldrin > Jon Hudson > Filename : draft-yong-trill-trill-o-mpls-01.txt > Pages : 14 > Date : 2012-03-12 > > This informational document describes ways to interconnect TRILL > RBridges by using MPLS Pseudo Wire (PW) services with existing TRILL > and MPLS standards so as to form a unified TRILL campus. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yong-trill-trill-o-mpls-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-yong-trill-trill-o-mpls-01.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From adrian@olddog.co.uk Mon Mar 12 15:07:37 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C711221E811B; Mon, 12 Mar 2012 15:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5h7IGpC0lXt; Mon, 12 Mar 2012 15:07:35 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id BB52D21E8127; Mon, 12 Mar 2012 15:07:34 -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 q2CM7Xqh026322; Mon, 12 Mar 2012 22:07:33 GMT Received: from 950129200 ([90.84.144.248]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2CM7O0I026241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Mar 2012 22:07:31 GMT From: "Adrian Farrel" To: , Date: Mon, 12 Mar 2012 22:07:26 -0000 Message-ID: <037301cd009c$86ea4290$94bec7b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0374_01CD009C.86F16E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0AmstwFklFNpkJSWmctiWPHNLZ7A== Content-Language: en-gb Subject: [PWE3] heads up: Requirements for IP/MPLS network transmission interruption duration X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:07:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0374_01CD009C.86F16E80 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Discussion should probably go to the Ops Area Working Group list. =20 Adrian =20 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of fanpeng Sent: 12 March 2012 15:24 To: opsawg@ietf.org; 'Bradner, Scott'; ietf@cdl.asgaard.org; melinda.shore@gmail.com Cc: =C0=EE=C1=AC=D4=B4 Subject: [OPSAWG] Requirements for IP/MPLS network transmission = interruption duration =20 Greetings all, =20 We have recently submitted a draft on transmission interruption duration (draft-fan-opsawg-transmission-interuption-00 ). We felt it necessary to make requirements for the interruption duration = since there is no consensus on it yet in the industry. We primarily analyzed interruption criteria for softswitch voice, and research on LTE backhaul = and other kinds of service scenarios has been in progress. =20 We would like to hear from you feedbacks about this draft, e.g. whether = or not there should be such requirements or methodology for the analysis. Any = comment on it will be appreciated. =20 The following is a brief introduction: =20 Today's IP/MPLS network is widely used as a bearing network to carry = diversified packet switched services. The transmission qualities of these services = are closely related to the performance of bearing layers, as network = failure, delay, congestion and other abnormities will inevitably bring about service interruption and user perception degradation. However, there is no = consensus in the industry on transmission interruption for IP/MPLS network up to now. = This memo studies relationships between service performance and transmission interruption duration in several scenarios, and is intended to reach a = list of requirements for these interruption duration criteria. =20 =20 Best regards, =20 =20 Fan Peng ------=_NextPart_000_0374_01CD009C.86F16E80 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Discussion should probably go to the Ops Area = Working Group list.

 

Adrian

 

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] = On Behalf Of fanpeng
Sent: 12 March 2012 = 15:24
To: opsawg@ietf.org; 'Bradner, Scott'; = ietf@cdl.asgaard.org; melinda.shore@gmail.com
Cc: =C0=EE=C1=AC=D4=B4
Subject: [OPSAWG] Requirements for IP/MPLS = network transmission interruption = duration

 

Greetings all,

 

We have recently submitted a draft on = transmission interruption duration (draft-fan-opsawg-transmission-interuption-00). We felt it necessary = to make requirements for the interruption duration since there is no = consensus on it yet in the industry. We primarily analyzed interruption = criteria for softswitch voice, and research on LTE backhaul and other = kinds of service scenarios has been in progress.

 

We would like to hear from you = feedbacks about this draft, e.g. whether or not there should be such = requirements or methodology for the analysis. Any comment on it will be = appreciated.

 

The following is a brief = introduction:

 

Today's IP/MPLS network is = widely used as a bearing network to carry diversified packet switched = services. The transmission qualities of these services are closely = related to the performance of bearing layers, as network failure, delay, = congestion and other abnormities will inevitably bring about service = interruption and user perception degradation. However, there is no = consensus in the industry on transmission interruption for IP/MPLS = network up to now.  This memo studies relationships between service = performance and transmission interruption duration in several scenarios, = and is intended to reach a list of requirements for these interruption = duration criteria.

 

 

Best = regards,           = ;            =           =

 

Fan = Peng

------=_NextPart_000_0374_01CD009C.86F16E80-- From davari@broadcom.com Mon Mar 12 17:16:57 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3119621E801C; Mon, 12 Mar 2012 17:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smnkVL0gODW4; Mon, 12 Mar 2012 17:16:54 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5D821E8014; Mon, 12 Mar 2012 17:16:53 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 12 Mar 2012 17:25:54 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 12 Mar 2012 17:16:45 -0700 From: "Shahram Davari" To: "tictoc@ietf.org" , "mpls@ietf.org" , "'pwe3@ietf.org'" , CCAMP Date: Mon, 12 Mar 2012 17:16:39 -0700 Thread-Topic: Updated 1588 over MPLS draf-03 Thread-Index: Ac0Aro8OkV/kLkCtTR+QbDOlyi4vGQ== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 63404B983E03632515-01-01 Content-Type: multipart/mixed; boundary=_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Subject: [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:16:57 -0000 --_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Transfer-Encoding: 7bit --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, Please find attached the latest 1588 over MPLS draft (03). Since cut-off da= te was yesterday, we will upload this after the Paris meeting. Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspect= s from each of these groups are used in this draft. We will present this draft in the relevant WGs in Paris. Regards, Shahram Davari --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

 

Please fin= d attached the latest 1588 over MPLS draft (03). Since cut-off date was yes= terday, we will upload this after the Paris meeting.

Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, sinc= e some aspects from each of these groups are used in this draft.

 

We will= present this draft in the relevant WGs in Paris.

 

Regards,

=

Shahram Davari

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_-- --_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: text/plain; name=draft-ietf-tictoc-1588overmpls-03.txt Content-Description: draft-ietf-tictoc-1588overmpls-03.txt Content-Disposition: attachment; filename=draft-ietf-tictoc-1588overmpls-03.txt; size=50993; creation-date="Mon, 12 Mar 2012 16:46:51 GMT"; modification-date="Mon, 12 Mar 2012 17:07:14 GMT" Content-Transfer-Encoding: base64 DQoNCg0KVElDVE9DIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUy4gRGF2YXJpDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIE9yZW4NCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICBCcm9hZGNvbSBDb3JwLg0K RXhwaXJlczogU2VwdGVtYmVyIDEyLCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTS4gQmhhdGlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFAuIFJvYmVydHMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNhdGVsLUx1Y2VudA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBM LiBNb250aW5pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMTIsIDIwMTENCg0KDQogICAgICAg ICAgVHJhbnNwb3J0aW5nIFBUUCBtZXNzYWdlcyAoMTU4OCkgb3ZlciBNUExTIE5ldHdvcmtzDQog ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OG92ZXJtcGxzLTAzDQoNCkFi c3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgbWV0aG9kIGZvciB0cmFuc3Bv cnRpbmcgUFRQIG1lc3NhZ2VzIChQRFVzKQ0KICAgb3ZlciBhbiBNUExTIG5ldHdvcmsuICBUaGUg bWV0aG9kIGFsbG93cyBmb3IgdGhlIGVhc3kgaWRlbnRpZmljYXRpb24NCiAgIG9mIHRoZXNlIFBE VXMgYXQgdGhlIHBvcnQgbGV2ZWwgdG8gYWxsb3cgZm9yIHBvcnQgbGV2ZWwgcHJvY2Vzc2luZyBv Zg0KICAgdGhlc2UgUERVcyBpbiBib3RoIExFUnMgYW5kIExTUnMuDQoNCiAgIFRoZSBiYXNpYyBp ZGVhIGlzIHRvIHRyYW5zcG9ydCBQVFAgbWVzc2FnZXMgaW5zaWRlIGRlZGljYXRlZCBNUExTDQog ICBMU1BzLiAgVGhlc2UgTFNQcyBvbmx5IGNhcnJ5IFBUUCBtZXNzYWdlcyBhbmQgcG9zc2libHkg Q29udHJvbCBhbmQNCiAgIE1hbmFnZW1lbnQgcGFja2V0cywgYnV0IHRoZXkgZG8gbm90IGNhcnJ5 IGN1c3RvbWVyIHRyYWZmaWMuDQoNCiAgIFR3byBtZXRob2RzIGZvciB0cmFuc3BvcnRpbmcgMTU4 OCBvdmVyIE1QTFMgYXJlIGRlZmluZWQuICBUaGUgZmlyc3QNCiAgIG1ldGhvZCBpcyB0byB0cmFu c3BvcnQgUFRQIG1lc3NhZ2VzIGRpcmVjdGx5IG92ZXIgdGhlIGRlZGljYXRlZCBNUExTDQogICBM U1AgdmlhIFVEUC9JUCBlbmNhcHN1bGF0aW9uLCB3aGljaCBpcyBzdWl0YWJsZSBmb3IgSVAvTVBM UyBuZXR3b3Jrcy4NCiAgIFRoZSBzZWNvbmQgbWV0aG9kIGlzIHRvIHRyYW5zcG9ydCBQVFAgbWVz c2FnZXMgaW5zaWRlIGEgUFcgdmlhDQogICBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uLCB3aGljaCBp cyBtb3JlIHN1aXRhYmxlIGZvciBNUExTLVRQIG5ldHdvcmtzLg0KDQpTdGF0dXMgb2YgdGhpcyBN ZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NCiAgIERyYWZ0cyBpcyBhdCBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHQgMTIsIDIwMTIuDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwu ICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAx XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJp Z2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl DQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0K ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50 cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhl IFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5 IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNClRhYmxl IG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KDQogICAyLiAgVGVybWlub2xvZ3kgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCg0KICAg My4gIFByb2JsZW0gU3RhdGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA4DQoNCiAgIDQuICAxNTg4IG92ZXIgTVBMUyBBcmNoaXRlY3R1cmUgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KDQogICA1LiAgRGVkaWNhdGVkIExTUHMg Zm9yIFBUUCBtZXNzYWdlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCg0KICAg Ni4gIDE1ODggb3ZlciBNUExTIEVuY2Fwc3VsYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDExDQogICAgIDYuMS4gIDE1ODggb3ZlciBMU1AgRW5jYXBzdWxhdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgICAgNi4yLiAgMTU4OCBvdmVyIFBXIEVu Y2Fwc3VsYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KDQogICA3LiAg MTU4OCBNZXNzYWdlIFRyYW5zcG9ydCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTQNCg0KICAgOC4gIFByb3RlY3Rpb24gYW5kIFJlZHVuZGFuY3kgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQoNCiAgIDkuICBFQ01QIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KDQogICAxMC4g T0FNLCBDb250cm9sIGFuZCBNYW5hZ2VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTgNCg0KICAgMTEuIFFvUyBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQoNCiAgIDEyLiBGQ1MgUmVjYWxjdWxhdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0KDQogICAxMy4g VURQIENoZWNrc3VtIENvcnJlY3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjENCg0KICAgMTQuIFJvdXRpbmcgZXh0ZW5zaW9ucyBmb3IgMTU4OGF3YXJlIExTUnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQogICAgIDE0LjEuIDE1ODhhd2FyZSBMaW5rIENh cGFiaWxpdHkgZm9yIE9TUEYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgICAgMTQuMi4g MTU4OGF3YXJlIExpbmsgQ2FwYWJpbGl0eSBmb3IgSVMtSVMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyMw0KDQogICAxNS4gUlNWUC1URSBFeHRlbnNpb25zIGZvciBzdXBwb3J0IG9mIDE1ODggLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUNCg0KICAgMTYuIEJlaGF2aW9yIG9mIExFUi9MU1IgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQogICAgIDE2LjEuIEJl aGF2aW9yIG9mIDE1ODgtYXdhcmUgTEVSIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjYNCiAgICAgMTYuMi4gQmVoYXZpb3Igb2YgMTU4OC1hd2FyZSBMU1IgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyNg0KICAgICAxNi4zLiBCZWhhdmlvciBvZiBub24tMTU4OC1hd2Fy ZSBMU1IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQoNCiAgIDE3LiBPdGhlciBjb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOA0K DQogICAxOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjkNCg0KMTkuIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5DQoNCiAgIDIwLiBBY2tub3dsZWRnZW1l bnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMA0KDQog ICAyMS4gSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzENCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBT ZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoN Cg0KICAgICAyMS4xLiBJQU5BIENvbnNpZGVyYXRpb25zIGZvciBPU1BGIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDMxDQogICAgIDIxLjIuIElBTkEgQ29uc2lkZXJhdGlvbnMgZm9yIElT LUlTICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzENCiAgICAgMjEuMy4gSUFOQSBDb25z aWRlcmF0aW9ucyBmb3IgUlNWUCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMQ0KDQog ICAyMi4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzINCiAgICAgMjIuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMg0KICAgICAyMi4yLiBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyDQoNCiAgIEF1 dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzNA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAg ICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoN Cg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAg ICAgICAgICBNYXJjaCAyMDEyDQoNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAg IGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDMjExOSBb UkZDMjExOV0uDQoNCiAgIFdoZW4gdXNlZCBpbiBsb3dlciBjYXNlLCB0aGVzZSB3b3JkcyBjb252 ZXkgdGhlaXIgdHlwaWNhbCB1c2UgaW4NCiAgIGNvbW1vbiBsYW5ndWFnZSwgYW5kIGFyZSBub3Qg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluDQogICBSRkMyMTE5IFtSRkMyMTE5XS4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCg0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMTINCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBvYmplY3RpdmUgb2Yg UHJlY2lzaW9uIFRpbWUgUHJvdG9jb2wgKFBUUCkgaXMgdG8gc3luY2hyb25pemUNCiAgIGluZGVw ZW5kZW50IGNsb2NrcyBydW5uaW5nIG9uIHNlcGFyYXRlIG5vZGVzIG9mIGEgZGlzdHJpYnV0ZWQg c3lzdGVtLg0KICAgW0lFRUVdIGRlZmluZXMgUFRQIG1lc3NhZ2VzIGZvciBjbG9jayBhbmQgdGlt ZSBzeW5jaHJvbml6YXRpb24uICBUaGUNCiAgIFBUUCBtZXNzYWdlcyBpbmNsdWRlIFBUUCBQRFVz IG92ZXIgVURQL0lQIChBbm5leCBEIGFuZCBFIG9mIFtJRUVFXSkNCiAgIGFuZCBQVFAgUERVcyBv dmVyIEV0aGVybmV0IChBbm5leCBGIG9mIFtJRUVFXSkuICBUaGlzIGRvY3VtZW50DQogICBkZWZp bmVzIG1hcHBpbmcgYW5kIHRyYW5zcG9ydCBvZiB0aGUgUFRQIG1lc3NhZ2VzIGRlZmluZWQgaW4g W0lFRUVdDQogICBvdmVyIE1QTFMgbmV0d29ya3MuDQoNCiAgIFBUUCBkZWZpbmVzIHNldmVyYWwg Y2xvY2sgdHlwZXM6IG9yZGluYXJ5IGNsb2NrcywgYm91bmRhcnkgY2xvY2tzLA0KICAgZW5kLXRv LWVuZCB0cmFuc3BhcmVudCBjbG9ja3MsIGFuZCBwZWVyLXRvLXBlZXIgdHJhbnNwYXJlbnQgY2xv Y2tzLg0KICAgT25lIGtleSBhdHRyaWJ1dGUgb2YgYWxsIG9mIHRoZXNlIGNsb2NrcyBpcyB0aGUg cmVjb21tZW5kYXRpb24gZm9yDQogICBQVFAgbWVzc2FnZXMgcHJvY2Vzc2luZyB0byBvY2N1ciBh cyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgYWN0dWFsDQogICB0cmFuc21pc3Npb24gYW5kIHJl Y2VwdGlvbiBhdCB0aGUgcGh5c2ljYWwgcG9ydCBpbnRlcmZhY2UuICBUaGlzDQogICB0YXJnZXRz IG9wdGltYWwgdGltZSBhbmQvb3IgZnJlcXVlbmN5IHJlY292ZXJ5IGJ5IGF2b2lkaW5nIHZhcmlh YmxlDQogICBkZWxheSBpbnRyb2R1Y2VkIGJ5IHF1ZXVlcyBpbnRlcm5hbCB0byB0aGUgY2xvY2tz LiAgVG8gZmFjaWxpdGF0ZSB0aGUNCiAgIGZhc3QgYW5kIGVmZmljaWVudCByZWNvZ25pdGlvbiBv ZiBQVFAgbWVzc2FnZXMgYXQgdGhlIHBvcnQgbGV2ZWwgd2hlbg0KICAgdGhlIFBUUCBtZXNzYWdl cyBhcmUgY2FycmllZCBvdmVyIE1QTFMgTFNQcywgdGhpcyBkb2N1bWVudCBkZWZpbmVzDQogICB0 aGUgc3BlY2lmaWMgZW5jYXBzdWxhdGlvbnMgdGhhdCBzaG91bGQgYmUgdXNlZC4gIEluIGFkZGl0 aW9uLCBpdCBjYW4NCiAgIGJlIGV4cGVjdGVkIHRoYXQgdGhlcmUgd2lsbCBleGlzdCBMU1IvTEVS cyB3aGVyZSBvbmx5IGEgc3Vic2V0IG9mIHRoZQ0KICAgcGh5c2ljYWwgcG9ydHMgd2lsbCBoYXZl IHRoZSBwb3J0IGJhc2VkIFBUUCBtZXNzYWdlIHByb2Nlc3NpbmcNCiAgIGNhcGFiaWxpdGllcy4g IEluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHRoZSBQVFAgY2FycnlpbmcgTFNQcyBhbHdheXMNCiAg IGVudGVyIGFuZCBleGl0IHBvcnRzIHdpdGggdGhpcyBjYXBhYmlsaXR5LCByb3V0aW5nIGV4dGVu c2lvbnMgYXJlDQogICBkZWZpbmVkIHRvIGFkdmVydGlzZSB0aGlzIGNhcGFiaWxpdHkgb24gYSBw b3J0IGJhc2lzIGFuZCB0byBhbGxvdyBmb3INCiAgIHRoZSBlc3RhYmxpc2htZW50IG9mIExTUHMg dGhhdCBvbmx5IHRyYW5zaXQgc3VjaCBwb3J0cy4gIFdoaWxlIHRoaXMNCiAgIHBhdGggZXN0YWJs aXNobWVudCByZXN0cmljdGlvbiBtYXkgYmUgYXBwbGllZCBvbmx5IGF0IHRoZSBMRVINCiAgIGlu Z3Jlc3MvZWdyZXNzIHBvcnRzLCBpdCBiZWNvbWVzIG1vcmUgaW1wb3J0YW50IHdoZW4gdXNpbmcN CiAgIHRyYW5zcGFyZW50IGNsb2NrIGNhcGFibGUgTFNScyBpbiB0aGUgcGF0aC4NCg0KICAgVGhl IHBvcnQgYmFzZWQgUFRQIG1lc3NhZ2UgcHJvY2Vzc2luZyBpbnZvbHZlcyBQVFAgZXZlbnQgbWVz c2FnZQ0KICAgcmVjb2duaXRpb24uICBPbmNlIHRoZSBQVFAgZXZlbnQgbWVzc2FnZXMgYXJlIHJl Y29nbml6ZWQgdGhleSBjYW4gYmUNCiAgIG1vZGlmaWVkIGJhc2VkIG9uIHRoZSByZWNlcHRpb24g b3IgdHJhbnNtaXNzaW9uIHRpbWVzdGFtcC4gIA0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVz IHR3byBtZXRob2RzIGZvciB0cmFuc3BvcnRpbmcgUFRQIG1lc3NhZ2VzIG92ZXINCiAgIE1QTFMu ICBPbmUgaXMgcHJpbmNpcGFsbHkgZm9jdXNlZCBvbiBhbiBJUC9NUExTIGVudmlyb25tZW50IGFu ZCB0aGUNCiAgIHNlY29uZCBpcyBmb2N1c2VkIG9uIHRoZSBNUExTLVRQIGVudmlyb25tZW50LiBU aGUgc29sdXRpb24gaW52b2x2ZXMgDQogIHRyYW5zcG9ydGluZyBQVFAgbWVzc2FnZXMgb3ZlciBk ZWRpY2F0ZWQgTFNQcyBjYWxsZWQgUFRQIExTUHMuIFRoZXNlDQogIExTUHMgY2FycnkgUFRQIG1l c3NhZ2VzIGFuZCBNQVkgY2FycnkgTWFuYWdlbWVudCBhbmQgY29udHJvbCBtZXNzYWdlcywNCiAg YnV0IG5vdCB1c2VyIHRyYWZmaWMuIFBUUCBMU1BzIGNhbiBiZSBlc3RhYmxpc2hlZCBzdGF0aWNh bGx5IG9yIHZpYSANCiAgc2lnbmFsaW5nLiBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGV4dGVuc2lv bnMgdG8gT1NQRiwgSVNJUyB0aGF0IGVuYWJsZSANCiAgcm91dGVycyB0byBkaXN0cmlidXRlIHRo ZWlyIDE1ODggb3ZlciBNUExTIGNhcGFiaWxpdHkgdG8gb3RoZXIgcm91dGVycy4gDQogIEl0IGFs c28gcHJvdmlkZXMgZXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBlc3RhYmxpc2hpbmcgUFRQIExT UHMuIA0KICBFeHRlbnNpb25zIGZvciBCR1AvTERQIFBXIHNpZ25hbGluZyBpcyBmb3IgZnV0dXJl IHN0dWR5IGFuZCBpcyAgDQogIHJlcXVpcmVkIG9ubHkgZm9yIGNhc2VzIHRoYXQgVHVubmVsIExh YmVsIGlzIG5vdCBhdmFpbGFibGUgKGUuZy4gUEhQKS4NCg0KICAgV2hpbGUgdGhlIHRlY2huaXF1 ZXMgaW5jbHVkZWQgaGVyZWluIGFsbG93IGZvciB0aGUgZXN0YWJsaXNobWVudCBvZg0KICAgcGF0 aHMgb3B0aW1pemVkIHRvIGluY2x1ZGUgUFRQIFRpbWUtc3RhbXBpbmcgY2FwYWJsZSBsaW5rcywg dGhlDQogICBwZXJmb3JtYW5jZSBvZiB0aGUgU2xhdmUgY2xvY2tzIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMTINCg0KDQoyLiAgVGVybWlub2xvZ3kNCg0KICAgMTU4ODogVGhlIHRpbWluZyBhbmQg c3luY2hyb25pemF0aW9uIGFzIGRlZmluZWQgYnkgSUVFRSAxNTg4LTIwMDgNCg0KICAgUFRQOiBU aGUgdGltaW5nIGFuZCBzeW5jaHJvbml6YXRpb24gcHJvdG9jb2wgdXNlZCBieSAxNTg4IChzcGVj aWZpY2FsbHkgUFRQdjIpDQoNCiAgIE1hc3RlciBDbG9jazogVGhlIHNvdXJjZSBvZiAxNTg4IHRp bWluZyB0byBhIHNldCBvZiBzbGF2ZSBjbG9ja3MuDQoNCiAgIE1hc3RlciBQb3J0OiBBIHBvcnQg b24gYSBvcmRpbmFyeSBvciBib3VuZGFyeSBjbG9jayB0aGF0IGlzIGluIE1hc3Rlcg0KICAgc3Rh dGUuICBUaGlzIGlzIHRoZSBzb3VyY2Ugb2YgdGltaW5nIHRvd2FyZCBzbGF2ZSBwb3J0cy4NCg0K ICAgU2xhdmUgQ2xvY2s6IEEgcmVjZWl2ZXIgb2YgMTU4OCB0aW1pbmcgZnJvbSBhIG1hc3RlciBj bG9jay4NCg0KICAgU2xhdmUgUG9ydDogQSBwb3J0IG9uIGEgYm91bmRhcnkgY2xvY2sgb3Igb3Jk aW5hcnkgY2xvY2sgdGhhdCBpcw0KICAgcmVjZWl2aW5nIHRpbWluZyBmcm9tIGEgbWFzdGVyIGNs b2NrLg0KDQogICBPcmRpbmFyeSBDbG9jazogQSBkZXZpY2Ugd2l0aCBhIHNpbmdsZSBQVFAgcG9y dC4NCg0KICAgVHJhbnNwYXJlbnQgQ2xvY2s6ICBBIGRldmljZSB0aGF0IG1lYXN1cmVzIHRoZSB0 aW1lIHRha2VuIGZvciBhIFBUUA0KICAgZXZlbnQgbWVzc2FnZSB0byB0cmFuc2l0IHRoZSBkZXZp Y2UgYW5kIHRoZW4gZWl0aGVyIHVwZGF0ZXMgdGhlDQogICBjb3JyZWN0aW9uIEZpZWxkIG9mIHRo ZSBtZXNzYWdlIHdpdGggdGhpcyB0cmFuc2l0IHRpbWUgKDEtc3RlcCkgb3IgIA0KICAgZ2VuZXJh dGVzIGEgZm9sbG93IHVwIG1lc3NhZ2UgdGhhdCBjb250YWlucyB0aGUgdHJhbnNpdCBkZWxheSAo Mi1TdGVwKS4NCg0KICAgQm91bmRhcnkgQ2xvY2s6IEEgZGV2aWNlIHdpdGggbW9yZSB0aGFuIG9u ZSBQVFAgcG9ydC4gIEdlbmVyYWxseQ0KICAgYm91bmRhcnkgY2xvY2tzIHdpbGwgaGF2ZSBvbmUg cG9ydCBpbiBzbGF2ZSBzdGF0ZSB0byByZWNlaXZlIHRpbWluZw0KICAgYW5kIHRoZSBvdGhlciBw b3J0cyBpbiBtYXN0ZXIgc3RhdGUgdG8gcmUtZGlzdHJpYnV0ZSB0aGUgdGltaW5nLg0KDQogICBQ VFAgTFNQOiBBbiBMU1AgZGVkaWNhdGVkIHRvIGNhcnJ5IFBUUCBtZXNzYWdlcy4NCg0KICAgUFRQ IFBXOiBBIFBXIHdpdGhpbiBhIFBUUCBMU1AgdGhhdCBpcyBkZWRpY2F0ZWQgdG8gY2FycnkgUFRQ DQogICBtZXNzYWdlcy4NCg0KICAgQ1c6IFBzZXVkb3dpcmUgQ29udHJvbCBXb3JkDQoNCg0KICAg RUNNUDogRXF1YWwgQ29zdCBNdWx0aXBhdGgNCg0KICAgQ0Y6IENvcnJlY3Rpb24gRmllbGQsIGEg ZmllbGQgaW5zaWRlIGNlcnRhaW4gUFRQIG1lc3NhZ2VzIChtZXNzYWdlDQogICB0eXBlIDAtMyl0 aGF0IGhvbGRzIHRoZSBhY2N1bXVsYXRpdmUgdHJhbnNpdCB0aW1lIGluc2lkZSBpbnRlcm1lZGlh dGUNCiAgIHN3aXRjaGVzLg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAg ICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoNCg0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDEyDQoNCg0KMy4gIFByb2JsZW0gU3RhdGVtZW50DQoNCiAgIElFRUUgMTU4 OC0yMDA4IGhhcyBkZWZpbmVkIG1ldGhvZHMgZm9yIHRyYW5zcG9ydGluZyBQVFAgbWVzc2FnZXMg b3ZlciANCiAgIEV0aGVybmV0IGFuZCBJUCBuZXR3b3Jrcy4gVGhlcmUgaXMgYSBuZWVkIHRvIHRy YW5zcG9ydCBQVFAgbWVzc2FnZXMgDQogICBvdmVyIGFuIE1QTFMgbmV0d29yayB3aGlsZSBzdXBw b3J0aW5nIHRoZSBUcmFuc3BhcmVudCBDbG9jayAoVEMpLCANCiAgIEJvdW5kYXJ5IENsb2NrIChC QykgYW5kIE9yZGluYXJ5IENsb2NrIChPQykgZnVuY3Rpb25hbGl0eSBpbiB0aGUgTEVSIA0KICAg YW5kIExTUnMgaW4gdGhlIE1QTFMgbmV0d29yay4gICANCg0KICAgVGhlcmUgYXJlIG11bHRpcGxl IHdheXMgb2YgdHJhbnNwb3J0aW5nIDE1ODggb3ZlciBNUExTLiBIb3dldmVyLCB0aGVyZQ0KICAg aXMgYSByZXF1aXJlbWVudCB0byBsaW1pdCB0aGUgcG9zc2libGUgZW5jYXBzdWxhdGlvbiBvcHRp b25zIHRvIHNpbXBsaWZ5DQogICB0aGUgUFRQIG1lc3NhZ2UgaWRlbnRpZmljYXRpb24gYW5kIHBy b2Nlc3NpbmcgcmVxdWlyZWQgYXQgdGhlIHBvcnQgbGV2ZWwuICANCg0KICAgVGhlcmUgaXMgYWxz byBhIHJlcXVpcmVtZW50IHRvIHRyYW5zcG9ydCBQVFAgbWVzc2FnZXMgYmVsb25naW5nIHRvIG1h bnkNCiAgIGRpZmZlcmVudCAxNTg4IGRvbWFpbnMgYWNyb3NzIGFuIE1QTFMgbmV0d29yayxzdWNo IGFzIHRoZSBjYXNlIGZvciB3aG9sZQ0KICAgc2FsZSAoY2Fycmllcj9zIGNhcnJpZXIgY2FzZSku DQoNCiAgIFdoZW4gMTU4OC1hd2FyZW5lc3MgaXMgbmVlZGVkLCBQVFAgbWVzc2FnZXMgc2hvdWxk IG5vdCBiZSB0cmFuc3BvcnRlZA0KICAgb3ZlciBMU1BzIG9yIFBXcyB0aGF0IGFyZSBjYXJyeWlu ZyBjdXN0b21lciB0cmFmZmljIGJlY2F1c2UgTFNScw0KICAgcGVyZm9ybSBMYWJlbCBzd2l0Y2hp bmcgYmFzZWQgb24gdGhlIHRvcCBsYWJlbCBpbiB0aGUgc3RhY2suICBUbw0KICAgZGV0ZWN0IFBU UCBtZXNzYWdlcyBpbnNpZGUgc3VjaCBMU1BzIHJlcXVpcmUgc3BlY2lhbCBoYXJkd2FyZSB0byBk bw0KICAgZGVlcCBwYWNrZXQgaW5zcGVjdGlvbiBhdCBsaW5lIHJhdGUuICBFdmVuIGlmIHN1Y2gg aGFyZHdhcmUgZXhpc3RzLA0KICAgdGhlIHBheWxvYWQgY2FuJ3QgYmUgZGV0ZXJtaW5pc3RpY2Fs bHkgaWRlbnRpZmllZCBieSBMU1JzIGJlY2F1c2UgdGhlDQogICBwYXlsb2FkIHR5cGUgaXMgYSBj b250ZXh0IG9mIHRoZSBQVyBsYWJlbCwgYW5kIHRoZSBQVyBsYWJlbCBhbmQgaXRzDQogICBjb250 ZXh0IGFyZSBvbmx5IGtub3duIHRvIHRoZSBFZGdlIHJvdXRlcnMgKFBFcy9MRVJzKTsgTFNScyBk b24ndCBrbm93DQogICB3aGF0IGlzIGEgUFcncyBwYXlsb2FkIChFdGhlcm5ldCwgQVRNLCBGUiwg Q0VTLCBldGMpLiAgRXZlbiBpZiBvbmUNCiAgIHJlc3RyaWN0cyBhbiBMU1AgdG8gb25seSBjYXJy eSBFdGhlcm5ldCBQV3MsIHRoZSBMU1JzIGRvbid0IGhhdmUgdGhlIA0KICAga25vd2xlZGdlIG9m IHdoZXRoZXIgUFcgQ29udHJvbCBXb3JkIChDVykgaXMgcHJlc2VudCBvciBub3QgYW5kIHRoZXJl Zm9yZQ0KICAgY2FuJ3QgZGV0ZXJtaW5pc3RpY2FsbHkgaWRlbnRpZnkgdGhlIHBheWxvYWQuDQoN CiAgIFRoZXJlZm9yZSBhIGdlbmVyaWMgbWV0aG9kIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dCB0aGF0IGRvZXMgbm90DQogICByZXF1aXJlIGRlZXAgcGFja2V0IGluc3BlY3Rpb24gYXQgbGlu ZSByYXRlLCBhbmQgY2FuIGRldGVybWluaXN0aWNhbGx5DQogICBpZGVudGlmeSBQVFAgbWVzc2Fn ZXMuICBUaGUgZGVmaW5lZCBtZXRob2QgaXMgYXBwbGljYWJsZSB0byBib3RoIE1QTFMNCiAgIGFu ZCBNUExTLVRQIG5ldHdvcmtzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K RGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVy IE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjQuICAxNTg4IG92ZXIgTVBM UyBBcmNoaXRlY3R1cmUNCg0KICAgMTU4OCBjb21tdW5pY2F0aW9uIGZsb3dzIG1hcCBvbnRvIE1Q TFMgbm9kZXMgYXMgZm9sbG93czogMTU4OA0KICAgbWVzc2FnZXMgYXJlIGV4Y2hhbmdlIGJldHdl ZW4gUFRQIHBvcnRzIG9uIG9yZGluYXJ5IGFuZCBib3VuZGFyeQ0KICAgY2xvY2tzLiAgVHJhbnNw YXJlbnQgY2xvY2tzIGRvIG5vdCB0ZXJtaW5hdGUgdGhlIFBUUCBtZXNzYWdlcyBidXQNCiAgIHRo ZXkgZG8gbW9kaWZ5IHRoZSBjb250ZW50cyBvZiB0aGUgUFRQIG1lc3NhZ2VzIGFzIHRoZXkgdHJh bnNpdA0KICAgYWNyb3NzIHRoZSB0cmFuc3BhcmVudCBjbG9jay4gIFNvIG9yZGluYXJ5IGFuZCBi b3VuZGFyeSBjbG9ja3Mgd291bGQNCiAgIGV4aXN0IHdpdGhpbiBMRVJzIGFzIHRoZXkgYXJlIHRo ZSB0ZXJtaW5hdGlvbiBwb2ludHMgZm9yIHRoZSBQVFANCiAgIG1lc3NhZ2VzIGNhcnJpZWQgaW4g TVBMUy4gIFRyYW5zcGFyZW50IGNsb2NrcyAob3IgYWx0ZXJuYXRpdmUgdGVjaG5pcXVlKSANCiAg IHdvdWxkIGV4aXN0IHdpdGhpbiBMU1JzIGFzIHRoZXkgZG8gbm90IHRlcm1pbmF0ZSB0aGUgUFRQ IG1lc3NhZ2UgZXhjaGFuZ2UuIA0KICAgVGhlIDE1OCBvdmVyIE1QTFMgQXJjaGl0ZWN0dXJlIGlz IHNob3duIGluIEZpZ3VyZSAxLg0KDQoNCg0KDQorLS0tLS0tLSsgICAgICstLS0tLS0tKyAgICAg Ky0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICstLS0tLS0tKw0KfCBNYXN0ZXJ8ICAgICB8ICAg ICAgIHwgICAgIHwgICAgICAgfCAgICAgfCAgICAgICB8ICAgICB8IFNsYXZlIHwNCnwgQ2xvY2sg fC0tLS0tfCAgTEVSICB8LS0tLS18ICBMU1IgIHwtLS0tLXwgIExFUiAgfC0tLS0tfCBDbG9jayB8 DQp8ICBPQyAgIHwgICAgIHwgIEJDICAgfCAgICAgfCAgVEMgICB8ICAgICB8ICBCQyAgIHwgICAg IHwgIE9DICAgfA0KKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICstLS0tLS0tKyAgICAgKy0t LS0tLS0rICAgICArLS0tLS0tLSsNCiAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBcDQorLS0tLS0tLSsgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFwgICAgICstLS0tLS0tKw0KfCAgTEVSICB8ICAgIC8gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXCAgICB8ICBMRVIgIHwNCnwgTWFzdGVyfC0tLS8gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcLS0tfCBTbGF2ZSB8DQp8IENsb2NrIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ2xvY2sgfA0K Ky0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLSsNCg0KRmlndXJlIDEgLSBEZXBsb3ltZW50IGV4YW1wbGVzIG9mIDE1ODggb3ZlciBN UExTIG5ldHdvcmsNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODgg b3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQo1LiAgRGVkaWNhdGVk IExTUHMgZm9yIFBUUCBtZXNzYWdlcw0KDQogICBNYW55IG1ldGhvZHMgd2VyZSBjb25zaWRlcmVk IGZvciBpZGVudGlmeWluZyB0aGUgMTU4OCBtZXNzYWdlcyB3aGVuDQogICB0aGV5IGFyZSBlbmNh cHN1bGF0ZWQgaW4gTVBMUyBzdWNoIGFzIGJ5IHVzaW5nIEdBTC9BQ0ggb3IgYSBuZXcNCiAgIHJl c2VydmVkIGxhYmVsLiAgVGhlc2UgbWV0aG9kcyB3ZXJlIG5vdCBhdHRyYWN0aXZlIHNpbmNlIHRo ZXkgZWl0aGVyDQogICByZXF1aXJlZCBkZWVwIHBhY2tldCBpbnNwZWN0aW9uIGFuZCBzbm9vcGlu ZyBhdCBsaW5lIHJhdGUgb3IgdGhleQ0KICAgcmVxdWlyZWQgdXNlIG9mIGEgc2NhcmNlIG5ldyBy ZXNlcnZlZCBsYWJlbC4gIEFsc28gb25lIG9mIHRoZSBnb2Fscw0KICAgd2FzIHRvIHJldXNlIGV4 aXN0aW5nIE9BTSBhbmQgcHJvdGVjdGlvbiBtZWNoYW5pc21zLg0KDQogICBUaGUgbWV0aG9kIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gYmUgdXNlZCBieSBMRVIvTFNScyB0bw0KICAgaWRl bnRpZnkgUFRQIG1lc3NhZ2VzIGluIE1QTFMgdHVubmVscyBieSB1c2luZyBkZWRpY2F0ZWQgTFNQ cyB0bw0KICAgY2FycnkgUFRQIG1lc3NhZ2VzLg0KDQogICBDb21wbGlhbnQgaW1wbGVtZW50YXRp b25zIE1VU1QgdXNlIGRlZGljYXRlZCBMU1BzIHRvIGNhcnJ5IFBUUA0KICAgbWVzc2FnZXMgb3Zl ciBNUExTLiAgVGhlc2UgTFNQcyBhcmUgaGVyZWluIHJlZmVycmVkIHRvIGFzICJQVFAgTFNQcyIN CiAgIGFuZCB0aGUgbGFiZWxzIGFzc29jaWF0ZWQgd2l0aCB0aGVzZSBMU1BzIGFzICJQVFAgbGFi ZWxzIi4gVGhlIFBUUCBMU1ANCiAgIGJldHdlZW4gYSBNYXN0ZXIgQ2xvY2sgYW5kIGEgU2xhdmUg Q2xvY2sgYW5kIHRoZSBQVFAgTFNQIGJldHdlZW4gdGhlDQogICBzYW1lIFNsYXZlIENsb2NrIGFu ZCBNYXN0ZXIgQ2xvY2sgTVVTVCBiZSBjby1yb3V0ZWQuICBBbHRlcm5hdGl2ZWx5LA0KICAgYSBz aW5nbGUgYmlkaXJlY3Rpb25hbCBjby1yb3V0ZWQgTFNQIGNhbiBiZSB1c2VkLiAgVGhlIFBUUCBM U1AgTUFZIGJlDQogICBNUExTIExTUCBvciBNUExTLVRQIExTUC4gIFRoaXMgY28tcm91dGluZyBp cyByZXF1aXJlZCB0byBsaW1pdA0KICAgZGlmZmVyZW5jZXMgaW4gdGhlIGRlbGF5cyBpbiB0aGUg TWFzdGVyIGNsb2NrIHRvIFNsYXZlIGNsb2NrDQogICBkaXJlY3Rpb24gY29tcGFyZWQgdG8gdGhl IFNsYXZlIGNsb2NrIHRvIE1hc3RlciBjbG9jayBkaXJlY3Rpb24uDQoNCiAgIFRoZSBQVFAgTFNQ cyBjb3VsZCBiZSBjb25maWd1cmVkIG9yIHNpZ25hbGVkIHZpYSBSU1ZQLVRFL0dNUExTLiAgTmV3 DQogICBSU1ZQLVRFL0dNUExTIFRMVnMgYW5kIG9iamVjdHMgYXJlIGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudCB0bw0KICAgaW5kaWNhdGUgdGhhdCB0aGVzZSBMU1BzIGFyZSBQVFAgTFNQcy4NCg0K ICAgVGhlIFBUUCBMU1BzIE1BWSBjYXJyeSBlc3NlbnRpYWwgTVBMUy9NUExTLVRQIGNvbnRyb2wg cGxhbmUgdHJhZmZpYw0KICAgc3VjaCBhcyBCRkQgYW5kIExTUCBQaW5nIGJ1dCB0aGUgTFNQIHVz ZXIgcGxhbmUgdHJhZmZpYyBNVVNUIGJlIFBUUA0KICAgb25seS4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2gg MjAxMg0KDQoNCjYuICAxNTg4IG92ZXIgTVBMUyBFbmNhcHN1bGF0aW9uDQoNCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyB0d28gbWV0aG9kcyBmb3IgY2FycnlpbmcgUFRQIG1lc3NhZ2VzIG92ZXIN CiAgIE1QTFMuICBUaGUgZmlyc3QgbWV0aG9kIGlzIGNhcnJ5aW5nIElQIGVuY2Fwc3VsYXRlZCBQ VFAgbWVzc2FnZXMgb3Zlcg0KICAgUFRQIExTUHMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBJUC9N UExTIG5ldHdvcmtzIGFuZCB0aGUgc2Vjb25kIG1ldGhvZCwgDQogICBpcyBjYXJyeWluZyBQVFAg bWVzc2FnZXMgb3ZlciBkZWRpY2F0ZWQgRXRoZXJuZXQgUFdzIChjYWxsZWQgUFRQIFBXcykgDQog ICBpbnNpZGUgUFRQIExTUHMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBNUExTIGFuZCBNUExTLVRQ IG5ldHdvcmtzLg0KDQo2LjEuICAxNTg4IG92ZXIgTFNQIEVuY2Fwc3VsYXRpb24NCg0KICAgVGhl IHNpbXBsZXN0IG1ldGhvZCBvZiB0cmFuc3BvcnRpbmcgUFRQIG1lc3NhZ2VzIG92ZXIgTVBMUyBp cyB0bw0KICAgZW5jYXBzdWxhdGUgUFRQIFBEVXMgaW4gVURQL0lQIGFuZCB0aGVuIGVuY2Fwc3Vs YXRlIHRoZW0gaW4gUFRQIExTUC4NCiAgIFRoZSAxNTg4IG92ZXIgTFNQIGZvcm1hdCBpcyBzaG93 biBpbiBGaWd1cmUgMi4NCg0KDQoNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICB8ICAgUFRQIFR1bm5lbCBMYWJlbCAgIHwNCiAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8ICAgICAgICBJUHY0LzYgICAgICAgIHwNCiAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8ICAgICAgICAgVURQICAg ICAgICAgIHwNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8 ICAgICAgICBQVFAgUERVICAgICAgIHwNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCg0KICAgRmlndXJlICgyKSAtIDE1ODggb3ZlciBMU1AgRW5jYXBzdWxhdGlvbg0KDQogICBU aGlzIGVuY2Fwc3VsYXRpb24gaXMgdmVyeSBzaW1wbGUgYW5kIGlzIHVzZWZ1bCB3aGVuIHRoZSBu ZXR3b3Jrcw0KICAgYmV0d2VlbiAxNTg4IE1hc3RlciBDbG9jayBhbmQgU2xhdmUgQ2xvY2sgYXJl IElQL01QTFMgbmV0d29ya3MuDQoNCiAgIEluIG9yZGVyIGZvciBhbiBMU1IgdG8gcHJvY2VzcyBQ VFAgbWVzc2FnZXMsIHRoZSBQVFAgTGFiZWwgbXVzdCBiZQ0KICAgdGhlIHRvcCBsYWJlbCBvZiB0 aGUgbGFiZWwgc3RhY2suDQoNCiAgIFRoZSBVRFAvSVAgZW5jYXBzdWxhdGlvbiBvZiBQVFAgTVVT VCBmb2xsb3cgQW5uZXggRCBhbmQgRSBvZiBbSUVFRV0uDQoNCjYuMi4gIDE1ODggb3ZlciBQVyBF bmNhcHN1bGF0aW9uDQoNCiAgIEFub3RoZXIgbWV0aG9kIG9mIHRyYW5zcG9ydGluZyAxNTg4IG92 ZXIgTVBMUyBuZXR3b3JrcyBpcyBieQ0KICAgZW5jYXBzdWxhdGluZyBQVFAgUERVcyBpbiBFdGhl cm5ldCBhbmQgdGhlbiB0cmFuc3BvcnRpbmcgdGhlbSBvdmVyDQogICBFdGhlcm5ldCBQVyAoUFRQ IFBXKSBhcyBkZWZpbmVkIGluIFtSRkM0NDQ4XSwgd2hpY2ggaW4gdHVybiBpcw0KICAgdHJhbnNw b3J0ZWQgb3ZlciBQVFAgTFNQcy4gIEFsdGVybmF0aXZlbHkgUFRQIFBEVXMgTUFZIGJlDQogICBl bmNhcHN1bGF0ZWQgaW4gVURQL0lQL0V0aGVybmV0IGFuZCB0aGVuIHRyYW5zcG9ydGVkIG92ZXIg RXRoZXJuZXQNCiAgIFBXLg0KDQogICBCb3RoIFJhdyBhbmQgVGFnZ2VkIG1vZGVzIGZvciBFdGhl cm5ldCBQVyBhcmUgcGVybWl0dGVkLiAgVGhlIDE1ODgNCiAgIG92ZXIgUFcgZm9ybWF0IGlzIHNo b3duIGluIEZpZ3VyZSAzLg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNo IDIwMTINCg0KDQogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAg ICAgICAgICAgICAgICB8UFRQIFR1bm5lbCBMYWJlbHwNCiAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgIHwgICAgUFcgTGFiZWwgICAgfA0K ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAg ICAgfCAgQ29udHJvbCBXb3JkICB8DQogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIEV0aGVybmV0ICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgfCAgICAgSGVhZGVyICAgICB8DQogICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgICBWTEFOcyAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIElQVjQvVjYgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgICAgVURQICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIFBU UCBQRFUgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rDQoNCiAg ICAgICAgICAgIEZpZ3VyZSAzIC0gMTU4OCBvdmVyIFBXIEVuY2Fwc3VsYXRpb24NCg0KICAgVGhl IENvbnRyb2wgV29yZCAoQ1cpIGFzIHNwZWNpZmllZCBpbiBbUkZDNDQ0OF0gU0hPVUxEIGJlIHVz ZWQgdG8NCiAgIGVuc3VyZSBhIG1vcmUgcm9idXN0IGRldGVjdGlvbiBvZiBQVFAgbWVzc2FnZXMg aW5zaWRlIHRoZSBNUExTDQogICBwYWNrZXQuICBJZiBDVyBpcyB1c2VkLCB0aGUgdXNlIG9mIFNl cXVlbmNlIE51bWJlciBpcyBvcHRpb25hbC4NCg0KICAgVGhlIHVzZSBvZiBWTEFOIGFuZCBVRFAv SVAgYXJlIG9wdGlvbmFsLiAgTm90ZSB0aGF0IDEgb3IgMiBWTEFOcyBNQVkNCiAgIGV4aXN0IGlu IHRoZSBQVyBwYXlsb2FkLg0KDQogICBJbiBvcmRlciBmb3IgYW4gTFNSIHRvIHByb2Nlc3MgUFRQ IG1lc3NhZ2VzLCB0aGUgdG9wIGxhYmVsIG9mIHRoZQ0KICAgbGFiZWwgc3RhY2sgKHRoZSBUdW5u ZWwgTGFiZWwpIE1VU1QgYmUgYSBQVFAgbGFiZWwuICBIb3dldmVyDQogICBpbiBzb21lIGFwcGxp Y2F0aW9ucyB0aGUgUFcgbGFiZWwgbWF5IGJlIHRoZSB0b3AgbGFiZWwgaW4gdGhlIHN0YWNrLA0K ICAgc3VjaCBhcyBjYXNlcyB3aGVyZSB0aGVyZSBpcyBvbmx5IG9uZS1ob3AgYmV0d2VlbiBQRXMg b3IgaW4gY2FzZSBvZg0KICAgUEhQLiAgSW4gc3VjaCBjYXNlcywgdGhlIFBXIGxhYmVsIFNIT1VM RCBiZSBhIFBUUCBMYWJlbC4NCg0KICAgSW4gb3JkZXIgdG8gZW5zdXJlIGNvbmdydWVuY3kgYmV0 d2VlbiB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgUFRQDQogICBtZXNzYWdlIGZsb3csIEVDTVAgU0hP VUxEIGJlIGF2b2lkZWQgZm9yIHRoZSBQVFAgVHVubmVscy9MU1BzLiAgDQogICBUaGVyZWZvcmUs IEVudHJvcHkgbGFiZWwgW0ktRC5pZXRmLXB3ZTMtZmF0LXB3XSBpcyBub3QgbmVjZXNzYXJ5IA0K ICAgYW5kIGl0IFNIT1VMRCBOT1QgYmUgcHJlc2VudCBpbiB0aGUgc3RhY2suDQoNCiAgIFRoZSBF dGhlcm5ldCBlbmNhcHN1bGF0aW9uIG9mIFBUUCBNVVNUIGZvbGxvdyBBbm5leCBGIG9mIFtJRUVF XSBhbmQNCiAgIHRoZSBVRFAvSVAgZW5jYXBzdWxhdGlvbiBvZiBQVFAgTVVTVCBmb2xsb3cgQW5u ZXggRCBhbmQgRSBvZiBbSUVFRV0uDQoNCiAgIEZvciAxNTg4IG92ZXIgTVBMUyBlbmNhcHN1bGF0 aW9ucyB0aGF0IGFyZSBQVyBiYXNlZCwgdGhlcmUgYXJlIHNvbWUNCiAgIGNhc2VzIGluIHdoaWNo IHRoZSBQVFAgTFNQIGxhYmVsIG1heSBub3QgYmUgcHJlc2VudDoNCg0KDQoNCkRhdmFyaSwgZXQg YWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdl IDEyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCiAgIG8gIFdoZW4gUEhQIGlzIGFwcGxpZWQg dG8gdGhlIFBUUCBMU1AsIHRoZSBmcmFtZSBpcyByZWNlaXZlZA0KICAgICAgYXQgUFcgdGVybWlu YXRpb24gcG9pbnQgd2l0aG91dCBQVFAgTFNQIGxhYmVsOw0KDQogICBvICBXaGVuIHRoZSBQVyBp cyBlc3RhYmxpc2hlZCBiZXR3ZWVuIHR3byByb3V0ZXJzIGRpcmVjdGx5IGNvbm5lY3RlZA0KICAg ICAgdG8gZWFjaCBvdGhlciB0aGUgUFRQIExTUCBpcyBub3QgbmVlZGVkLg0KDQogICBJbiBzdWNo IGNhc2VzIGl0IGlzIHJlcXVpcmVkIGZvciBhIHJvdXRlciB0byBpZGVudGlmeSB0aGVzZSBNUExT IGZyYW1lcyANCiAgIGFzIFBUUCBtZXNzYWdlcy4gIFRoaXMgd291bGQgcmVxdWlyZSB0aGUgUFcg bGFiZWwgdG8gYmUgYSBQVFAgbGFiZWwuDQoNCiAgIFNpbmNlIGJvdGggdGhlIFR1bm5lbCBMYWJl bCBhbmQgUFcgTGFiZWwgbWF5IG5lZWQgdG8gYmUgUFRQIGxhYmVscywgDQogICB0aGVyZSBpcyBh IG5lZWQgdG8gYWRkIGV4dGVuc2lvbiB0byBSU1ZQLVRFIFR1bm5lbCBMYWJlbCBkaXN0cmlidXRp b24sIA0KICAgYXMgd2VsbCBhcyBMRFAvQkdQIFBXIGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2Nv bCB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0KICAgVHVubmVsIExhYmVsIGFuZCBQVyBsYWJlbCBhcmUg UFRQIExhYmVscyByZXNwZWN0aXZlbHkuDQoNCiAgIFRoZSBQVyBtZXRob2Qgb2YgdHJhbnNwb3J0 aW5nIFBUUCBvdmVyIE1QTFMgaXMgYXBwbGljYWJsZSB0byBib3RoIElQL01QTFMNCiAgIGFuZCBN UExTLVRQIG5ldHdvcmtzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4 cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxM10NCg0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMTINCg0KDQo3LiAgMTU4OCBNZXNzYWdlIFRyYW5zcG9ydA0KDQogICAxNTg4IHByb3Rv Y29sIGNvbXByaXNlcyBvZiB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgdHlwZXM6DQoNCiAgIG8gIEFu bm91bmNlDQoNCiAgIG8gIFNZTkMNCg0KICAgbyAgRk9MTE9XIFVQDQoNCiAgIG8gIERFTEFZX1JF USAoRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgREVMQVlfUkVTUCAoRGVsYXkgUmVzcG9uc2UpDQoN CiAgIG8gIFBERUxBWV9SRVEgKFBlZXIgRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgUERFTEFZX1JF U1AgKFBlZXIgRGVsYXkgUmVzcG9uc2UpDQoNCiAgIG8gIFBERUxBWV9SRVNQX0ZPTExPV19VUCAo UGVlciBEZWxheSBSZXNwb25zZSBGb2xsb3cgdXApDQoNCiAgIG8gIE1hbmFnZW1lbnQNCg0KICAg byAgU2lnbmFsaW5nDQoNCiAgIEEgc3Vic2V0IG9mIFBUUCBtZXNzYWdlIHR5cGVzIHRoYXQgcmVx dWlyZSB0aW1lc3RhbXAgcHJvY2Vzc2luZyBhcmUNCiAgIGNhbGxlZCBFdmVudCBtZXNzYWdlczoN Cg0KICAgbyAgU1lOQw0KDQogICBvICBERUxBWV9SRVEgKERlbGF5IFJlcXVlc3QpDQoNCiAgIG8g IFBERUxBWV9SRVEgKFBlZXIgRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgUERFTEFZX1JFU1AgKFBl ZXIgRGVsYXkgUmVzcG9uc2UpDQoNCiAgIFNZTkMgYW5kIERFTEFZX1JFUSBhcmUgZXhjaGFuZ2Vk IGJldHdlZW4gTWFzdGVyIENsb2NrIGFuZCBTbGF2ZSBDbG9jaw0KICAgYW5kIE1VU1QgYmUgdHJh bnNwb3J0ZWQgb3ZlciBQVFAgTFNQcy4gIFBERUxBWV9SRVEgYW5kIFBERUxBWV9SRVNQDQogICBh cmUgZXhjaGFuZ2VkIGJldHdlZW4gYWRqYWNlbnQgUFRQIGNsb2NrcyAoaS5lLiAgb3JkaW5hcnkg aW4gTWFzdGVyIG9yIA0KICAgU2xhdmUgc3RhdGUsIGJvdW5kYXJ5LCBvciB0cmFuc3BhcmVudCBj bG9jaykgYW5kIE1BWSBiZSB0cmFuc3BvcnRlZA0KICAgb3ZlciBzaW5nbGUgaG9wIFBUUCBMU1Bz LiAgDQoNCiAgIEZvciBhIGdpdmVuIGluc3RhbmNlIG9mIDE1ODggcHJvdG9jb2wsIFNZTkMgYW5k IERFTEFZX1JFUSBNVVNUIGJlDQogICB0cmFuc3BvcnRlZCBvdmVyIHR3byBQVFAgTFNQcyB0aGF0 IGFyZSBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zLiAgVGhlc2UNCiAgIFBUUCBMU1BzLCB3aGljaCBh cmUgaW4gb3Bwb3NpdGUgZGlyZWN0aW9ucyBNVVNUIGJlIGNvbmdydWVudCBhbmQgY28tDQogICBy b3V0ZWQuICBBbHRlcm5hdGl2ZWx5LCBhIHNpbmdsZSBiaWRpcmVjdGlvbmFsIGNvLXJvdXRlZCBM U1AgY2FuIGJlDQogICB1c2VkLg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAg ICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCg0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDEyDQoNCg0KICBOb24tRXZlbnQgUFRQIG1lc3NhZ2UgdHlwZXMgZG9uJ3QgbmVl ZCB0byBiZSBwcm9jZXNzZWQgYnkgaW50ZXJtZWRpYXRlDQogIHJvdXRlcnMuSG93ZXZlciwgdGhl c2UgbWVzc2FnZSB0eXBlcyBNQVkgYmUgY2FycmllZCBpbiBQVFAgVHVubmVsIExTUHMuDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAg ICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNV0N CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAg ICAgICAgTWFyY2ggMjAxMg0KDQoNCjguICBQcm90ZWN0aW9uIGFuZCBSZWR1bmRhbmN5DQoNCiAg IEluIG9yZGVyIHRvIGVuc3VyZSBjb250aW51b3VzIHVuaW50ZXJydXB0ZWQgb3BlcmF0aW9uIG9m IHNsYXZlIGNsb2NrcywNCiAgIHVzdWFsbHkgYXMgYSBnZW5lcmFsIHByYWN0aWNlLCBzbGF2ZSBj bG9ja3MgKG9yIHBvcnRzKSB0cmFjayByZWR1bmRhbnQgDQogICBtYXN0ZXIgY2xvY2tzLg0KCQ0K ICAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBuZXR3b3JrIG9wZXJhdG9yIHRvIGVu c3VyZQ0KICAgdGhhdCBwaHlzaWNhbGx5IGRpc2pvaW50IFBUUCB0dW5uZWxzIGFyZSBlc3RhYmxp c2hlZCBiZXR3ZWVuIGEgc2xhdmUgDQogICBjbG9jayBvciBwb3J0IGFuZCByZWR1bmRhbnQgbWFz dGVycyBjbG9ja3Mgb3IgcG9ydHMuDQoNCiAgIFdoZW4gYSBzbGF2ZSBjbG9jayhvciBwb3J0KSBs aXN0ZW4gdG8gcmVkdW5kYW50IG1hc3RlciBjbG9ja3Mgb3IgcG9ydHMsIA0KICAgYW55IHByb2xv bmdlZCBQVFAgTFNQIG9yIFBUUCBQVyBvdXRhZ2Ugd2lsbCB0cmlnZ2VyIHRoZSBzbGF2ZSBjbG9j ayBvcg0KICAgcG9ydCB0byBzd2l0Y2ggdG8gYSByZWR1bmRhbnQgbWFzdGVyIGNsb2NrIG9yIHBv cnQuICBIb3dldmVyIExTUC9QVyANCiAgIHByb3RlY3Rpb24gc3VjaCBhcyBMaW5lYXIgcHJvdGVj dGlvbiBTd2l0Y2hpbmcgKDE6MSwxKzEpLCBSaW5nIA0KICAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcg b3IgTVBMUyBGYXN0IFJlcm91dGUgKEZSUikgU0hPVUxEIHN0aWxsIGJlIHVzZWQNCiAgIHRvIHBy b3ZpZGUgcmVzaWxpZW5jeSB0byBpbmRpdmlkdWFsIG5ldHdvcmsgc2VnbWVudCBmYWlsdXJlcy4N Cg0KICAgTm90ZSB0aGF0IGFueSBwcm90ZWN0aW9uIG9yIHJlcm91dGUgbWVjaGFuaXNtIHRoYXQg YWRkcyBhZGRpdGlvbmFsDQogICBsYWJlbCB0byB0aGUgbGFiZWwgc3RhY2ssIHN1Y2ggYXMgRmFj aWxpdHkgQmFja3VwIEZhc3QgUmVyb3V0ZSwgTVVTVA0KICAgZW5zdXJlIHRoYXQgdGhlIHB1c2hl ZCBsYWJlbCBpcyBhIFBUUCBMYWJlbCB0byBlbnN1cmUgcmVjb2duaXRpb24gb2YNCiAgIHRoZSBN UExTIGZyYW1lIGFzIGNvbnRhaW5pbmcgUFRQIG1lc3NhZ2VzIGFzIGl0IHRyYW5zaXRzIHRoZSBi YWNrdXANCiAgIHBhdGguDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2Vw dCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoN Cg0KOS4gIEVDTVANCg0KICAgVG8gZW5zdXJlIHRoZSBvcHRpbWFsIG9wZXJhdGlvbiBvZiBzbGF2 ZSBjbG9ja3MgYW5kIGF2b2lkIGVycm9ycw0KICAgaW50cm9kdWNlZCBieSBmb3J3YXJkIGFuZCBy ZXZlcnNlIHBhdGggZGVsYXkgYXN5bW1ldHJ5LCB0aGUgcGh5c2ljYWwNCiAgIHBhdGggZm9yIFBU UCBtZXNzYWdlcyBmcm9tIG1hc3RlciBjbG9jayB0byBzbGF2ZSBDbG9jayBhbmQgdmljZSB2ZXJz YQ0KICAgbXVzdCBiZSB0aGUgc2FtZSBmb3IgYWxsIFBUUCBtZXNzYWdlcyBsaXN0ZWQgaW4gc2Vj dGlvbiA3IGFuZCBtdXN0DQogICBub3QgY2hhbmdlIGV2ZW4gaW4gdGhlIHByZXNlbmNlIG9mIEVD TVAgaW4gdGhlIE1QTFMgbmV0d29yay4NCg0KICAgVG8gZW5zdXJlIHRoZSBmb3J3YXJkIGFuZCBy ZXZlcnNlIHBhdGhzIGFyZSB0aGUgc2FtZSBQVFAgTFNQcyBhbmQgUFdzDQogICBTSE9VTEQgTk9U IGJlIHN1YmplY3QgdG8gRUNNUC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwg ZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQ YWdlIDE3XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAg ICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQoxMC4gIE9BTSwgQ29udHJvbCBhbmQgTWFu YWdlbWVudA0KDQogICBJbiBvcmRlciB0byBtYW5hZ2UgUFRQIExTUHMgYW5kIFBUUCBQV3MsIHRo ZXkgTUFZIGNhcnJ5IE9BTSwgQ29udHJvbA0KICAgYW5kIG1hbmFnZW1lbnQgbWVzc2FnZXMuICBU aGVzZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50IG1lc3NhZ2VzIGNhbg0KICAgYmUgZGlmZmVyZW50 aWF0ZWQgZnJvbSBQVFAgbWVzc2FnZXMgdmlhIGFscmVhZHkgZGVmaW5lZCBJRVRGIG1ldGhvZHMu DQoNCiAgIEluIHBhcnRpY3VsYXIgQkZEIFtSRkM1ODgwXSwgW1JGQzU4ODRdIGFuZCBMU1AtUGlu ZyBbUkZDNDM4OV0gTUFZIHJ1bg0KICAgb3ZlciBQVFAgTFNQcyB2aWEgVURQL0lQIGVuY2Fwc3Vs YXRpb24gb3IgdmlhIEdBTC9HLUFDSC4gIFRoZXNlDQogICBNYW5hZ2VtZW50IHByb3RvY29scyBh cmUgZWFzaWx5IGlkZW50aWZpZWQgYnkgdGhlIFVEUCBEZXN0aW5hdGlvbg0KICAgUG9ydCBudW1i ZXIgb3IgYnkgR0FML0FDSCByZXNwZWN0aXZlbHkuDQoNCiAgIEFsc28gQkZELCBMU1AtUGluZyBh bmQgb3RoZXIgbWFuYWdlbWVudCBtZXNzYWdlcyBNQVkgcnVuIG92ZXIgUFRQIFBXDQogICB2aWEg b25lIG9mIHRoZSBkZWZpbmVkIFZDQ1ZzIChUeXBlIDEsIDIgb3IgMykgW1JGQzUwODVdLiAgSW4g dGhpcw0KICAgY2FzZSBHLUFDSCwgUm91dGVyIEFsZXJ0IExhYmVsIChSQUwpLCBvciBQVyBsYWJl bCAoVFRMPTEpIGFyZSB1c2VkIHRvDQogICBpZGVudGlmeSBzdWNoIG1hbmFnZW1lbnQgbWVzc2Fn ZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBT ZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTIN Cg0KDQoxMS4gIFFvUyBDb25zaWRlcmF0aW9ucw0KDQogICBJbiBuZXR3b3JrIGRlcGxveW1lbnRz IHdoZXJlIG5vdCBldmVyeSBMU1IvTEVSIGlzIFBUUC1hd2FyZSwgdGhlbiBpdA0KICAgaXMgaW1w b3J0YW50IHRvIHJlZHVjZSB0aGUgaW1wYWN0IG9mIHRoZSBub24tUFRQLWF3YXJlIExTUi9MRVJz IG9uDQogICB0aGUgdGltaW5nIHJlY292ZXJ5IGluIHRoZSBzbGF2ZSBjbG9jay4gIFRoZSBQVFAg bWVzc2FnZXMgYXJlIHRpbWUNCiAgIGNyaXRpY2FsIGFuZCBtdXN0IGJlIHRyZWF0ZWQgd2l0aCB0 aGUgaGlnaGVzdCBwcmlvcml0eS4gIFRoZXJlZm9yZQ0KICAgMTU4OCBvdmVyIE1QTFMgbWVzc2Fn ZXMgbXVzdCBiZSB0cmVhdGVkIHdpdGggdGhlIGhpZ2hlc3QgcHJpb3JpdHkgaW4NCiAgIHRoZSBy b3V0ZXJzLiAgVGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgcHJvcGVyIHNldHVwIG9mIFBUUCB0dW5u ZWxzLg0KICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgUFRQIExTUHMgYXJlIHNldHVwIGFu ZCBtYXJrZWQgcHJvcGVybHkgdG8NCiAgIGluZGljYXRlIEVGLVBIQiBbUkZDMzI0Nl1mb3IgdGhl IENvUyBhbmQgR3JlZW4gW1JGQzI2OTddIGZvciBkcm9wIA0KICAgZWxpZ2liaWxpdHkuDQoNCiAg IEluIG5ldHdvcmsgZGVwbG95bWVudHMgd2hlcmUgZXZlcnkgTFNSL0xFUiBzdXBwb3J0cyBQVFAg TFNQcywgdGhlbiBpdA0KICAgTUFZIE5PVCBiZSByZXF1aXJlZCB0byBhcHBseSB0aGUgc2FtZSBs ZXZlbCBvZiBwcmlvcml0aXphdGlvbiBhcw0KICAgc3BlY2lmaWVkIGFib3ZlLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAx NTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjEyLiAgRkNT IFJlY2FsY3VsYXRpb24NCg0KICAgRXRoZXJuZXQgRkNTIG9mIHRoZSBvdXRlciBlbmNhcHN1bGF0 aW9uIE1VU1QgYmUgcmVjYWxjdWxhdGVkIGF0IGV2ZXJ5DQogICBMU1IgdGhhdCBwZXJmb3JtcyB0 aGUgdHJhbnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZyBhbmQgRkNTIHJldGVudGlvbg0KICAgZm9y IHRoZSBwYXlsb2FkIEV0aGVybmV0IGRlc2NyaWJlZCBpbiBbUkZDNDcyMF0gTVVTVCBOT1QgYmUg dXNlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAy MF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjEzLiAgVURQIENoZWNrc3VtIENvcnJlY3Rpb24N Cg0KICAgRm9yIFVEUC9JUCBlbmNhcHN1bGF0aW9uIG1vZGUgb2YgMTU4OCBvdmVyIE1QTFMsIHRo ZSBVRFAgY2hlY2tzdW0gaXMNCiAgIG9wdGlvbmFsIHdoZW4gdXNlZCBmb3IgSVB2NCBlbmNhcHN1 bGF0aW9uIGFuZCBtYW5kYXRvcnkgaW4gY2FzZSBvZg0KICAgSVB2Ni4gIFdoZW4gSVB2NHY2IFVE UCBjaGVja3N1bSBpcyB1c2VkLCBlYWNoIDE1ODgtYXdhcmUgTFNSIG11c3QNCiAgIGVpdGhlciBp bmNyZW1lbnRhbGx5IHVwZGF0ZSB0aGUgVURQIGNoZWNrc3VtIGFmdGVyIHRoZSBDRiB1cGRhdGUg b3INCiAgIHZlcmlmeSB0aGUgVURQIGNoZWNrc3VtIG9uIHJlY2VwdGlvbiBmcm9tIHVwc3RyZWFt IGFuZA0KICAgcmVjYWxjdWxhdGUgdGhlIGNoZWNrc3VtIGNvbXBsZXRlbHkgb24gdHJhbnNtaXNz aW9uIGFmdGVyIENGIHVwZGF0ZQ0KICAgdG8gZG93bnN0cmVhbSBub2RlLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAx MiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoN CjE0LiAgUm91dGluZyBleHRlbnNpb25zIGZvciAxNTg4LWF3YXJlIExTUnMNCg0KICAgTVBMUy1U RSByb3V0aW5nIHJlbGllcyBvbiBleHRlbnNpb25zIHRvIE9TUEYgW1JGQzIzMjhdIFtSRkM1MzQw XSBhbmQNCiAgIElTLUlTIFtJU09dIFtSRkMxMTk1XSBpbiBvcmRlciB0byBhZHZlcnRpc2UgVHJh ZmZpYyBFbmdpbmVlcmluZyAoVEUpDQogICBsaW5rIGluZm9ybWF0aW9uIHVzZWQgZm9yIGNvbnN0 cmFpbnQtYmFzZWQgcm91dGluZy4NCg0KICAgSW5kZWVkLCBpdCBpcyB1c2VmdWwgdG8gYWR2ZXJ0 aXNlIGRhdGEgcGxhbmUgVEUgcm91dGVyIGxpbmsNCiAgIGNhcGFiaWxpdGllcywgc3VjaCBhcyB0 aGUgY2FwYWJpbGl0eSBmb3IgYSByb3V0ZXIgdG8gYmUgMTU4OC1hd2FyZS4NCiAgIFRoaXMgY2Fw YWJpbGl0eSBNVVNUIHRoZW4gYmUgdGFrZW4gaW50byBhY2NvdW50IGR1cmluZyBwYXRoDQogICBj b21wdXRhdGlvbiB0byBwcmVmZXIgb3IgZXZlbiByZXF1aXJlIGxpbmtzIHRoYXQgYWR2ZXJ0aXNl IHRoZW1zZWx2ZXMNCiAgIGFzIDE1ODgtYXdhcmUuICBJbiB0aGlzIHdheSB0aGUgcGF0aCBjYW4g ZW5zdXJlIHRoZSBlbnRyeSBhbmQgZXhpdA0KICAgcG9pbnRzIGludG8gdGhlIExFUnMgYW5kLCBp ZiBkZXNpcmVkLCB0aGUgbGlua3MgaW50byB0aGUgTFNScyBhcmUNCiAgIGFibGUgdG8gcGVyZm9y bSBwb3J0IGJhc2VkIHRpbWVzLXRhbXBpbmcgdGh1cyBtaW5pbWl6aW5nIHRoZWlyIGltcGFjdA0K ICAgb24gdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBzbGF2ZSBjbG9jay4NCg0KICAgRm9yIHRoaXMg cHVycG9zZSwgdGhlIGZvbGxvd2luZyBzZWN0aW9ucyBzcGVjaWZ5IGV4dGVuc2lvbnMgdG8gT1NQ Rg0KICAgYW5kIElTLUlTIGluIG9yZGVyIHRvIGFkdmVydGlzZSAxNTg4IGF3YXJlIGNhcGFiaWxp dGllcyBvZiBhIGxpbmsuDQoNCjE0LjEuICAxNTg4YXdhcmUgTGluayBDYXBhYmlsaXR5IGZvciBP U1BGDQoNCiAgIE9TUEYgdXNlcyB0aGUgTGluayBUTFYgKFR5cGUgMikgdGhhdCBpcyBpdHNlbGYg Y2FycmllZCB3aXRoaW4gZWl0aGVyDQogICB0aGUgVHJhZmZpYyBFbmdpbmVlcmluZyBMU0Egc3Bl Y2lmaWVkIGluIFtSRkMzNjMwXSBvciB0aGUgT1NQRnYzDQogICBJbnRyYS1BcmVhLVRFIExTQSAo ZnVuY3Rpb24gY29kZSAxMCkgZGVmaW5lZCBpbiBbUkZDNTMyOV0gdG8NCiAgIGFkdmVydGlzZSB0 aGUgVEUgcmVsYXRlZCBpbmZvcm1hdGlvbiBmb3IgdGhlIGxvY2FsbHkgYXR0YWNoZWQgcm91dGVy DQogICBsaW5rcy4gIEZvciBhbiBMU0EgVHlwZSAxMCwgb25lIExTQSBjYW4gY29udGFpbiBvbmUg TGluayBUTFYNCiAgIGluZm9ybWF0aW9uIGZvciBhIHNpbmdsZSBsaW5rLiAgVGhpcyBleHRlbnNp b24gZGVmaW5lcyBhIG5ldyAxNTg4LQ0KICAgYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIHRoYXQg Y2FuIGJlIGNhcnJpZWQgYXMgcGFydCBvZiB0aGUgTGluayBUTFYuDQoNCiAgIFRoZSAxNTg4LWF3 YXJlIGNhcGFiaWxpdHkgc3ViLVRMViBpcyBPUFRJT05BTCBhbmQgTVVTVCBOT1QgYXBwZWFyDQog ICBtb3JlIHRoYW4gb25jZSB3aXRoaW4gdGhlIExpbmsgVExWLiAgSWYgYSBzZWNvbmQgaW5zdGFu Y2Ugb2YgdGhlDQogICAxNTg4LWF3YXJlIGNhcGFiaWxpdHkgc3ViLVRMViBpcyBwcmVzZW50LCB0 aGUgcmVjZWl2aW5nIHN5c3RlbSBNVVNUDQogICBvbmx5IHByb2Nlc3MgdGhlIGZpcnN0IGluc3Rh bmNlIG9mIHRoZSBzdWItVExWLiAgSXQgaXMgZGVmaW5lZCBhcw0KICAgZm9sbG93czoNCg0KICAg ICAgMCAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAg ICAgICBUeXBlICAgICAgICAgICAgIHwgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgfA0K ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgIEZsYWdzICAgICB8DQogICAgICArLSstKy0rLSst Ky0rLSstKw0KDQogICAgICAgICAgICAgICAgRmlndXJlIDM6IDE1ODgtYXdhcmUgQ2FwYWJpbGl0 eSBUTFYNCg0KDQogICBXaGVyZToNCg0KICAgVHlwZSwgMTYgYml0czogMTU4OC1hd2FyZSBDYXBh YmlsaXR5IFRMViB3aGVyZSB0aGUgdmFsdWUgaXMgVEJEDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwu ICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDIy XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAg ICAgICAgICAgICBNYXJjaCAyMDEyDQoNCg0KICAgTGVuZ3RoLCAxNiBiaXRzOiBHaXZlcyB0aGUg bGVuZ3RoIG9mIHRoZSBmbGFncyBmaWVsZCBpbiBvY3RldHMsIGFuZA0KICAgaXMgY3VycmVudGx5 IHNldCB0byAxDQoNCiAgIEZsYWdzLCA4IGJpdHM6IFRoZSBiaXRzIGFyZSBkZWZpbmVkIGxlYXN0 LXNpZ25pZmljYW50LWJpdCAoTFNCKQ0KICAgZmlyc3QsIHNvIGJpdCA3IGlzIHRoZSBsZWFzdCBz aWduaWZpY2FudCBiaXQgb2YgdGhlIGZsYWdzIG9jdGV0Lg0KDQoNCiAgICAgICAwIDEgMiAzIDQg NSA2IDcNCiAgICAgICstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgUmVzZXJ2ZWQgIHxDfA0K ICAgICAgKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICBGaWd1cmUgNDogRmxhZ3MgRm9ybWF0DQoN Cg0KICAgQ29ycmVjdGlvbiAoQykgZmllbGQgVXBkYXRlIGZpZWxkLCAxIGJpdDogU2V0dGluZyB0 aGUgQyBiaXQgdG8gMQ0KICAgaW5kaWNhdGVzIHRoYXQgdGhlIGxpbmsgaXMgY2FwYWJsZSBvZiBy ZWNvZ25pemluZyB0aGUgUFRQIGV2ZW50DQogICBwYWNrZXRzIGFuZCBjYW4gY29tcGVuc2F0ZSBm b3IgcmVzaWRlbmNlIHRpbWUgYnkgdXBkYXRpbmcgdGhlIFBUUA0KICAgcGFja2V0IENvcnJlY3Rp b24gRmllbGQuICBXaGVuIHRoaXMgaXMgc2V0IHRvIDAsIGl0IG1lYW5zIHRoYXQgdGhpcw0KICAg bGluayBjYW5ub3QgcGVyZm9ybSB0aGUgcmVzaWRlbmNlIHRpbWUgY29ycmVjdGlvbiBidXQgaXMg Y2FwYWJsZSBvZg0KICAgcGVyZm9ybWluZyBNUExTIGZyYW1lIGZvcndhcmRpbmcgb2YgdGhlIGZy YW1lcyB3aXRoIFBUUCBsYWJlbHMgdXNpbmcNCiAgIGEgbWV0aG9kIHRoYXQgc3VwcG9ydCB0aGUg ZW5kIHRvIGVuZCBkZWxpdmVyeSBvZiBhY2N1cmF0ZSB0aW1pbmcuDQogICBUaGUgZXhhY3QgbWV0 aG9kIGlzIG5vdCBkZWZpbmVkIGhlcmVpbi4NCg0KICAgUmVzZXJ2ZWQsIDcgYml0czogUmVzZXJ2 ZWQgZm9yIGZ1dHVyZSB1c2UuICBUaGUgcmVzZXJ2ZWQgYml0cyBtdXN0IGJlDQogICBpZ25vcmVk IGJ5IHRoZSByZWNlaXZlci4NCg0KICAgVGhlIDE1ODgtYXdhcmUgQ2FwYWJpbGl0eSBzdWItVExW IGlzIGFwcGxpY2FibGUgdG8gYm90aCBPU1BGdjIgYW5kDQogICBPU1BGdjMuDQoNCjE0LjIuICAx NTg4YXdhcmUgTGluayBDYXBhYmlsaXR5IGZvciBJUy1JUw0KDQogICBUaGUgSVMtSVMgVHJhZmZp YyBFbmdpbmVlcmluZyBbUkZDMzc4NF0gZGVmaW5lcyB0aGUgaW50cmEtYXJlYQ0KICAgdHJhZmZp YyBlbmdpbmVlcmluZyBlbmhhbmNlbWVudHMgYW5kIHVzZXMgdGhlIEV4dGVuZGVkIElTDQogICBS ZWFjaGFiaWxpdHkgVExWIChUeXBlIDIyKSBbUkZDNTMwNV0gdG8gY2FycnkgdGhlIHBlciBsaW5r IFRFLXJlbGF0ZWQNCiAgIGluZm9ybWF0aW9uLiAgVGhpcyBleHRlbnNpb24gZGVmaW5lcyBhIG5l dyAxNTg4LWF3YXJlIGNhcGFiaWxpdHkgc3ViLQ0KICAgVExWIHRoYXQgY2FuIGJlIGNhcnJpZWQg YXMgcGFydCBvZiB0aGUgRXh0ZW5kZWQgSVMgUmVhY2hhYmlsaXR5IFRMVi4NCg0KICAgVGhlIDE1 ODgtYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIGlzIE9QVElPTkFMIGFuZCBNVVNUIE5PVCBhcHBl YXINCiAgIG1vcmUgdGhhbiBvbmNlIHdpdGhpbiB0aGUgRXh0ZW5kZWQgSVMgUmVhY2hhYmlsaXR5 IFRMViBvciB0aGUgTXVsdGktDQogICBUb3BvbG9neSAoTVQpIEludGVybWVkaWF0ZSBTeXN0ZW1z IFRMViAodHlwZSAyMjIpIHNwZWNpZmllZCBpbg0KICAgW1JGQzUxMjBdLiAgSWYgYSBzZWNvbmQg aW5zdGFuY2Ugb2YgdGhlIDE1ODgtYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWDQogICBpcyBwcmVz ZW50LCB0aGUgcmVjZWl2aW5nIHN5c3RlbSBNVVNUIG9ubHkgcHJvY2VzcyB0aGUgZmlyc3QgaW5z dGFuY2UNCiAgIG9mIHRoZSBzdWItVExWLg0KDQogICBUaGUgZm9ybWF0IG9mIHRoZSBJUy1JUyAx NTg4LWF3YXJlIHN1Yi1UTFYgaXMgaWRlbnRpY2FsIHRvIHRoZSBUTFYNCiAgIGZvcm1hdCB1c2Vk IGJ5IHRoZSBUcmFmZmljIEVuZ2luZWVyaW5nIEV4dGVuc2lvbnMgdG8gSVMtSVMgW1JGQzM3ODRd Lg0KICAgVGhhdCBpcywgdGhlIFRMViBpcyBjb21wcmlzZWQgb2YgMSBvY3RldCBmb3IgdGhlIHR5 cGUsIDEgb2N0ZXQNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNl cHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTIN Cg0KDQogICBzcGVjaWZ5aW5nIHRoZSBUTFYgbGVuZ3RoLCBhbmQgYSB2YWx1ZSBmaWVsZC4gIFRo ZSBMZW5ndGggZmllbGQNCiAgIGRlZmluZXMgdGhlIGxlbmd0aCBvZiB0aGUgdmFsdWUgcG9ydGlv biBpbiBvY3RldHMuDQoNCiAgICAgIDAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMg0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzDQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICB8ICAgICBUeXBlICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAgRmxhZ3Mg ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQoNCiAgICAgICAgICAgICBGaWd1cmUgNTogMTU4OC1hd2FyZSBDYXBhYmlsaXR5IHN1 Yi1UTFYNCg0KICAgV2hlcmU6DQoNCiAgIFR5cGUsIDggYml0czogMTU4OC1hd2FyZSBDYXBhYmls aXR5IHN1Yi1UTFYgd2hlcmUgdGhlIHZhbHVlIGlzIFRCRA0KDQogICBMZW5ndGgsIDggYml0czog R2l2ZXMgdGhlIGxlbmd0aCBvZiB0aGUgZmxhZ3MgZmllbGQgaW4gb2N0ZXRzLCBhbmQgaXMNCiAg IGN1cnJlbnRseSBzZXQgdG8gMQ0KDQogICBGbGFncywgOCBiaXRzOiBUaGUgYml0cyBhcmUgZGVm aW5lZCBsZWFzdC1zaWduaWZpY2FudC1iaXQgKExTQikNCiAgIGZpcnN0LCBzbyBiaXQgNyBpcyB0 aGUgbGVhc3Qgc2lnbmlmaWNhbnQgYml0IG9mIHRoZSBmbGFncyBvY3RldC4NCg0KDQogICAgICAg MCAxIDIgMyA0IDUgNiA3DQogICAgICArLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgIFJlc2Vy dmVkICB8Q3wNCiAgICAgICstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgRmlndXJlIDY6IEZsYWdz IEZvcm1hdA0KDQogICBDb3JyZWN0aW9uIChDKSBmaWVsZCBVcGRhdGUgZmllbGQsIDEgYml0OiBT ZXR0aW5nIHRoZSBDIGJpdCB0byAxDQogICBpbmRpY2F0ZXMgdGhhdCB0aGUgbGluayBpcyBjYXBh YmxlIG9mIHJlY29nbml6aW5nIHRoZSBQVFAgZXZlbnQNCiAgIHBhY2tldHMgYW5kIGNhbiBjb21w ZW5zYXRlIGZvciByZXNpZGVuY2UgdGltZSBieSB1cGRhdGluZyB0aGUgUFRQDQogICBwYWNrZXQg Q29ycmVjdGlvbiBGaWVsZC4gIFdoZW4gdGhpcyBpcyBzZXQgdG8gMCwgaXQgbWVhbnMgdGhhdCB0 aGlzDQogICBsaW5rIGNhbm5vdCBwZXJmb3JtIHRoZSByZXNpZGVuY2UgdGltZSBjb3JyZWN0aW9u IGJ1dCBpcyBjYXBhYmxlIG9mDQogICBwZXJmb3JtaW5nIE1QTFMgZnJhbWUgZm9yd2FyZGluZyBv ZiB0aGUgZnJhbWVzIHdpdGggUFRQIGxhYmVscyB1c2luZw0KICAgYSBtZXRob2QgdGhhdCBzdXBw b3J0IHRoZSBlbmQgdG8gZW5kIGRlbGl2ZXJ5IG9mIGFjY3VyYXRlIHRpbWluZy4NCiAgIFRoZSBl eGFjdCBtZXRob2QgaXMgbm90IGRlZmluZWQgaGVyZWluLg0KDQogICBSZXNlcnZlZCwgNyBiaXRz OiBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gIFRoZSByZXNlcnZlZCBiaXRzIG11c3QgYmUNCiAg IGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJp LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAg W1BhZ2UgMjRdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMg ICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQoxNS4gIFJTVlAtVEUgRXh0ZW5zaW9u cyBmb3Igc3VwcG9ydCBvZiAxNTg4DQoNCiAgIFJTVlAtVEUgc2lnbmFsaW5nIE1BWSBiZSB1c2Vk IHRvIHNldHVwIHRoZSBQVFAgTFNQcy4gIEEgbmV3IFJTVlANCiAgIG9iamVjdCBpcyBkZWZpbmVk IHRvIHNpZ25hbCB0aGF0IHRoaXMgaXMgYSBQVFAgTFNQLiAgVGhlIE9GRlNFVCB0bw0KICAgdGhl IHN0YXJ0IG9mIHRoZSBQVFAgbWVzc2FnZSBoZWFkZXIgTUFZIGFsc28gYmUgc2lnbmFsZWQuDQog ICBJbXBsZW1lbnRhdGlvbnMgY2FuIHRyaXZpYWxseSBsb2NhdGUgdGhlIENvcnJlY3Rpb24gRmll bGQgKENGKQ0KICAgbG9jYXRpb24gZ2l2ZW4gdGhpcyBpbmZvcm1hdGlvbi4gIFRoZSBPRkZTRVQg cG9pbnRzIHRvIHRoZSBzdGFydCBvZg0KICAgdGhlIFBUUCBoZWFkZXIgYXMgYSBub2RlIG1heSB3 YW50IHRvIGNoZWNrIHRoZSBQVFAgbWVzc2FnZSBUeXBlIGJlZm9yZQ0KICAgaXQgdG91Y2hlcyB0 aGUgY29ycmVjdGlvbiBGaWVsZCAoQ0YpLiAgVGhlIE9GRlNFVCBpcyBjb3VudGVkIGZyb20gYm90 dG9tDQogICBvZiBsYWJlbCBzdGFjay4NCg0KICAgVGhlIExTUnMgdGhhdCByZWNlaXZlIGFuZCBw cm9jZXNzIHRoZSBSU1ZQLVRFL0dNUExTIG1lc3NhZ2VzIE1BWSB1c2UNCiAgIHRoZSBPRkZTRVQg dG8gbG9jYXRlIHRoZSBzdGFydCBvZiB0aGUgUFRQIG1lc3NhZ2UgaGVhZGVyLg0KDQogICBOb3Rl IHRoYXQgdGhlIG5ldyBvYmplY3QvVExWIE1VU1QgYmUgaWdub3JlZCBieSBMU1JzIHRoYXQgYXJl IG5vdA0KICAgY29tcGxpYW50IHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KICAgVGhlIG5ldyBS U1ZQIDE1ODhfUFRQX0xTUCBvYmplY3Qgc2hvdWxkIGJlIGluY2x1ZGVkIGluIHNpZ25hbGluZyBQ VFANCiAgIExTUHMgYW5kIGlzIGRlZmluZWQgYXMgZm9sbG93czoNCg0KICAgICAgICAgICAgICAg ICAgIDAgICAgICAgICAgICAgMSAgICAgICAgICAgICAyICAgICAgICAgICAgIDMNCiAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgfCAgICAgICBMZW5ndGggKGJ5dGVzKSAgICAgIHwgIENsYXNzLU51 bSAgfCAgIEMtVHlwZSAgICB8DQogICAgICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgIHwgT2Zmc2V0IHRv IGxvY2F0ZSB0aGUgc3RhcnQgb2YgdGhlIFBUUCBtZXNzYWdlIGhlYWRlciAgfA0KICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0rDQoNCiAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA3OiBSU1ZQIDE1ODhfUFRQX0xTUCBv YmplY3QNCg0KDQogICBUaGUgaW5ncmVzcyBMU1IgTVVTVCBpbmNsdWRlIHRoaXMgb2JqZWN0IGlu IHRoZSBSU1ZQIFBBVEggTWVzc2FnZS4NCiAgIEl0IGlzIGp1c3QgYSBub3JtYWwgUlNWUCBwYXRo IHRoYXQgaXMgZXhjbHVzaXZlbHkgc2V0IHVwIGZvciBQVFANCiAgIG1lc3NhZ2VzLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDI1XQ0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDEyDQoNCg0KMTYuICBCZWhhdmlvciBvZiBMRVIvTFNSDQoNCjE2LjEuIEJlaGF2 aW9yIG9mIDE1ODgtY2FwYWJsZS9hd2FyZSBMRVINCg0KICAgQSAxNTg4LWNhcGFibGUvYXdhcmUg TEVSIGFkdmVydGlzZXMgaXQncyAxNTg4LWNhcGFiaWxpdHkgdmlhIHRoZSBPU1BGIA0KICAgb3Ig SVMtSVMgcHJvY2VkdXJlIGV4cGxhaW5lZCBpbiBlYXJsaWVyIHNlY3Rpb25zIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4gIA0KICAgVGhlIDE1ODgtY2FiYWxlL2F3YXJlIExFUiB0aGVuIHNpZ25hbHMg UFRQIExTUHMgYnkgaW5jbHVkaW5nIHRoZSANCiAgIDE1ODhfUFRQX0xTUCBvYmplY3QgaW4gdGhl IFJTVlAtVEUgc2lnbmFsaW5nLg0KDQogICBXaGVuIGEgMTU4OCBtZXNzYWdlIGlzIHJlY2VpdmVk IGZyb20gYSBub24tTVBMUyBpbnRlcmZhY2UsIHRoZSBMRVINCiAgIE1VU1QgcmVkaXJlY3QgdGhl bSB0byBhIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgUFRQIExTUC4gIFdoZW4gYSAxNTg4DQogICBv dmVyIE1QTFMgbWVzc2FnZSBpcyByZWNlaXZlZCBmcm9tIGFuIE1QTFMgaW50ZXJmYWNlLCB0aGUg cHJvY2Vzc2luZw0KICAgaXMgc2ltaWxhciB0byAxNTg4LWF3YXJlIExTUiBwcm9jZXNzaW5nLg0K DQoxNi4yLiBCZWhhdmlvciBvZiAxNTg4LWNhcGFibGUvYXdhcmUgTFNSDQoNCiAgIDE1ODgtY2Fw YWJsZS9hd2FyZSBMU1JzIGFyZSBMU1JzIHRoYXQgdW5kZXJzdGFuZCB0aGUgMTU4OF9QVFBfTFNQ IFJTVlANCiAgIG9iamVjdCBhbmQgY2FuIHBlcmZvcm0gMTU4OCBwcm9jZXNzaW5nIChlLmcudHJh bnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZykuDQoNCiAgIEEgMTU4OC1jYXBhYmxlIExTUiBhZHZl cnRpc2VzIGl0J3MgMTU4OC1jYXBhYmlsaXR5IHZpYSB0aGUgT1NQRiBvciBJUy1JUw0KICAgcHJv Y2VkdXJlIGV4cGxhaW5lZCBpbiBlYXJsaWVyIHNlY3Rpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlv bi4NCg0KICAgV2hlbiBhIDE1ODgtY2FwYWJsZS9hd2FyZSBMU1IgZGlzdHJpYnV0ZXMgYSBsYWJl bCBmb3IgUFRQIExTUCwgaXQgbWFpbnRhaW5zDQogICB0aGlzIGluZm9ybWF0aW9uLiAgV2hlbiB0 aGUgMTU4OC1jYXBhYmxlL2F3YXJlIExTUiByZWNlaXZlcyBhbiBNUExTIHBhY2tldCwNCiAgIGl0 IHBlcmZvcm1zIGEgbGFiZWwgbG9va3VwIGFuZCBpZiB0aGUgbGFiZWwgbG9va3VwIGluZGljYXRl cyBpdCBpcyBhIFBUUCANCiAgIGxhYmVsIHRoZW4gZnVydGhlciBwYXJzaW5nIG11c3QgYmUgZG9u ZSB0byBwb3NpdGl2ZWx5IGlkZW50aWZ5IHRoYXQgdGhlIA0KICAgIHBheWxvYWQgaXMgMTU4OCBh bmQgbm90IE9BTSwgQkZEIG9yIGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQuDQoNCiAgIFJ1bGluZyBv dXQgbm9uLTE1ODggbWVzc2FnZXMgY2FuIGVhc2lseSBiZSBkb25lIHdoZW4gcGFyc2luZw0KICAg aW5kaWNhdGVzIHRoZSBwcmVzZW5jZSBvZiBHQUwsIEFDSCBvciBWQ0NWIChUeXBlIDEsIDIsIDMp IG9yIHdoZW4gdGhlDQogICBVRFAgcG9ydCBudW1iZXIgZG9lcyBub3QgbWF0Y2ggb25lIG9mIHRo ZSAxNTg4IFVEUCBwb3J0IG51bWJlcnMuDQoNCiAgIEFmdGVyIGEgMTU4OCBtZXNzYWdlIGlzIHBv c2l0aXZlbHkgaWRlbnRpZmllZCBpbiBhIFBUUCBMU1AsIHRoZSBQVFANCiAgIG1lc3NhZ2UgdHlw ZSBpbmRpY2F0ZXMgd2hldGhlciBhbnkgdGltZXN0YW1wIHByb2Nlc3NpbmcgaXMgcmVxdWlyZWQu DQogICBBZnRlciAxNTg4IHByb2Nlc3NpbmcgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQgYXMgYSBu b3JtYWwgTVBMUyBwYWNrZXQNCiAgIHRvIGRvd25zdHJlYW0gbm9kZS4NCg0KMTYuMy4gQmVoYXZp b3Igb2Ygbm9uLTE1ODgtY2FwYWJsZS9hd2FyZSBMU1INCg0KICAgVGhlcmUgYXJlIHR3byB0eXBl cyBvZiBMU1JzIHRoYXQgY2FuP3QgcGFydGljaXBhdGUgaW4gcHJvY2Vzc2luZyBQVFAgDQogICBt ZXNzYWdlcyBpbiBhbiBSU1ZQLVRFIHNpZ25hbGVkIFBUUCBMU1A6DQoNCiAgIDEpIExTUnMgdGhh dCBkb24ndCBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb2Nlc3MgMTU4OCBwYWNrZXRzIChlLmcuIA0K ICAgICAgcGVyZm9ybSB0cmFuc3BhcmVudCBjbG9jayBwcm9jZXNzaW5nKS4gVGhlc2UgTFNScyBh cmUgY2FsbGVkIA0KICAgICAgbm9uLTE1ODgtY2FwYWJsZSBMU1JzLg0KDQogICAyKSBMU1JzIHRo YXQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBwcm9jZXNzIDE1ODggcGFja2V0cyAoZS5nLiANCiAg ICAgIHBlcmZvcm0gdHJhbnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZywgYnV0IGRvbid0IHVuZGVy c3RhbmQgICAgICAgdGhlIDE1ODhfUFRQX0xTUCBSU1ZQIG9iamVjdC4gVGhlc2UgTFNScyBhcmUg Y2FsbGVkIA0KICAgICAgbm9uLTE1ODgtYXdhcmUgTFNScy4NCiAgIA0KDQpEYXZhcmksIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAy Nl0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQpJdCBpcyBtb3N0IGJlbmVmaWNpYWwgdGhhdCBhbGwg TFNScyBpbiB0aGUgcGF0aCBvZiBhIFBUUCBMU1AgYmUgMTU4OC0NCiAgIENhcGFibGUgYW5kIGF3 YXJlIExTUnMuICBUaGlzIHdvdWxkIGVuc3VyZSB0aGUgaGlnaGVzdCBxdWFsaXR5IHRpbWUgDQog ICBhbmQgY2xvY2sgc3luY2hyb25pemF0aW9uIGJ5IDE1ODggU2xhdmUgQ2xvY2tzLiBIb3dldmVy LCB0aGlzIA0KICAgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYW5kYXRlIHRoYXQgYWxsIExTUnMg aW4gcGF0aCBvZiBhIFBUUCBMU1AgDQogICBiZSAxNTg4LWNhcGFibGUgYW5kIGF3YXJlLg0KDQoN CiAgIE5vbi0xNTg4LWNhYmFibGUgYW5kIG5vbi0xNTg4LWF3YXJlIExTUnMgaWdub3JlIHRoZSBS U1ZQIA0KICAgMTU4OF9QVFBfTFNQIG9iamVjdCBhbmQganVzdCBzd2l0Y2ggdGhlIE1QTFMgcGFj a2V0cyBjYXJyeWluZyAxNTg4IA0KICAgbWVzc2FnZXMgYXMgZGF0YSBwYWNrZXRzIGFuZCBkb24n dCBwZXJmb3JtIGFueSB0aW1lc3RhbXAgcmVsYXRlZCANCiAgIHByb2Nlc3NpbmcuICBIb3dldmVy IGFzIGV4cGxhaW5lZCBpbiBRb1Mgc2VjdGlvbiB0aGUgMTU4OCBvdmVyIE1QTFMgDQogICBwYWNr ZXRzIE1VU1QgYmUgc3RpbGwgYmUgdHJlYXRlZCB3aXRoIHRoZSBoaWdoZXN0IHByaW9yaXR5Lg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJl cyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDI3XQ0KDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgICBNYXJjaCAy MDEyDQoNCg0KMTcuICBPdGhlciBjb25zaWRlcmF0aW9ucw0KDQogICBUaGUgdXNlIG9mIEV4cGxp Y2l0IE51bGwgKExhYmVsPSAwIG9yIDIpIGlzIGFjY2VwdGFibGUgYXMgbG9uZyBhcw0KICAgZWl0 aGVyIHRoZSBFeHBsaWNpdCBOdWxsIGxhYmVsIGlzIHRoZSBib3R0b20gb2Ygc3RhY2sgbGFiZWwN CiAgIChhcHBsaWNhYmxlIG9ubHkgdG8gVURQL0lQIGVuY2Fwc3VsYXRpb24pIG9yIHRoZSBsYWJl bCBiZWxvdyB0aGUNCiAgIEV4cGxpY2l0IE51bGwgbGFiZWwgaXMgYSBQVFAgbGFiZWwuDQoNCiAg IFRoZSB1c2Ugb2YgUGVudWx0aW1hdGUgSG9wIFBvcCAoUEhQKSBpcyBhY2NlcHRhYmxlIGFzIGxv bmcgYXMgZWl0aGVyDQogICB0aGUgUEhQIGxhYmVsIGlzIHRoZSBib3R0b20gb2Ygc3RhY2sgbGFi ZWwgKGFwcGxpY2FibGUgb25seSB0byBVRFAvSVANCiAgIGVuY2Fwc3VsYXRpb24pIG9yIHRoZSBs YWJlbCBiZWxvdyB0aGUgUEhQIGxhYmVsIGlzIGEgUFRQIGxhYmVsLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg IDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoNCg0KMTguICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBNUExTIFBXIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGluIGdlbmVyYWwgYXJlIGRpc2N1c3NlZCBpbiBbUkZDMzk4NV0NCiAgIGFuZCBbUkZDNDQ0 N10sYW5kIHRob3NlIGNvbnNpZGVyYXRpb25zIGFsc28gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC4N Cg0KICAgQW4gZXhwZXJpbWVudGFsIHNlY3VyaXR5IHByb3RvY29sIGlzIGRlZmluZWQgaW4gW0lF RUVdLiAgVGhlIFBUUA0KICAgc2VjdXJpdHkgZXh0ZW5zaW9uIGFuZCBwcm90b2NvbCBwcm92aWRl cyBncm91cCBzb3VyY2UgYXV0aGVudGljYXRpb24sDQogICBtZXNzYWdlIGludGVncml0eSwgYW5k IHJlcGxheSBhdHRhY2sgcHJvdGVjdGlvbiBmb3IgUFRQIG1lc3NhZ2VzLg0KDQoNCjE5LiAgQXBw bGljYWJpbGl0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIDE1ODggb3ZlciBNUExTIHRyYW5zcG9ydCBt ZXRob2RzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgYXBwbGllcyB0byB0aGUgZm9s bG93aW5nIG5ldHdvcmsgRWxlbWVudHM6DQoNCiAgLSBBbiBMRVIgcmVjZWl2ZXMgSVAgb3IgRXRo ZXJuZXQgRW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBmcm9tIGEgDQogICAgbm9uLU1QTFMgaW50 ZXJmYWNlIGFuZCBmb3J3YXJkcyB0aGVtIG92ZXIgTFNQL1BXIGJ5LCB3aGlsZSBwZXJmb3JtaW5n DQogICAgVEMgZnVuY3Rpb25hbGl0eQ0KICAtIEFuIExFUiByZWNlaXZlcyBNUExTIGVuY2Fwc3Vs YXRlZCBQVFAgbWVzc2FnZXMgYW5kIGZvcndhcmRzIHRoZW0NCiAgICBhcyBJUCBvciBFdGhlcm5l dCBFbmNhcHN1bGF0ZWQgUFRQIG1lc3NhZ2VzIHRvIGEgbm9uLSAgICBNUExTIGludGVyZmFjZSwg d2hpbGUgcGVyZm9ybWluZyB0aGUgVEMgZnVuY3Rpb25hbGl0eS0gQW4gTEVSIA0KICAgIHJlY2Vp dmVzIE1QTFMgZW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBhbmQgdGVybWluYXRlcyB0aGVtLCB3 aGlsZSANCiAgICBwZXJmb3JtaW5nIHRoZSBPQyBvciBCQyBmdW5jdGlvbmFsaXR5DQogIC0gQW4g TFNSIHJlY2VpdmVzIE1QTFMgZW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBmcm9tIGFuIE1QTFMg aW50ZXJmYWNlDQogICAgYW5kIGZvcndhcmRzIHRoZW0gdG8gYW5vdGhlciBNUExTIGludGVyZmFj ZSwgd2hpbGUgcGVyZm9ybWluZyB0aGUgVEMgDQogICAgZnVuY3Rpb25hbGl0eQ0KICAtIEFuIExT UiByZWNlaXZlcyBNUExTIGVuY2Fwc3VsYXRlZCBQVFAgbWVzc2FnZXMgYW5kIHRlcm1pbmF0ZXMg dGhlbSwgDQogICAgd2hpbGUgcGVyZm9ybWluZyB0aGUgT0Mgb3IgQkMgZnVuY3Rpb25hbGl0eQ0K DQogICBUaGlzIGRvY3VtZW50IGFsc28gc3VwcG9ydHMgdGhlIGNhc2Ugd2hlcmUgbm90IGFsbCBM U1JzL0xFUnMgYXJlIDE1ODgNCiAgIG92ZXIgTVBMUyBjYXBhYmxlLiBJdCBhbHNvIHN1cHBvcnRz IHRoZSBjYXNlIHdoZXJlIG5vdCBhbGwgTEVSL0xTUiANCiAgIGludGVyZmFjZXMgYXJlIDE1ODgg b3ZlciBNUExTIGNhcGFibGUuDQoNCg0KDQogICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAg ICAgICAgICAgICAgICBbUGFnZSAyOV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAx NTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjIwLiAgQWNr bm93bGVkZ2VtZW50cw0KDQogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEx1Y2Eg TWFydGluaSwgUm9uIENvaGVuLCBZYWFrb3YNCiAgIFN0ZWluLCBUYWwgTWl6cmFoaSwgU3RlZmFu byBSdWZmaW5pLCBMdWNhIE1vbml0aSBhbmQgb3RoZXIgbWVtYmVycyANCiAgIG9mIElFVEYgZm9y IHJldmlld2luZyAgYW5kIHByb3ZpZGluZyBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0Lg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMwXQ0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFy Y2ggMjAxMg0KDQoNCjIxLiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQoyMS4xLiAgSUFOQSBDb25z aWRlcmF0aW9ucyBmb3IgT1NQRg0KDQogICBJQU5BIGhhcyBkZWZpbmVkIGEgc3ViLXJlZ2lzdHJ5 IGZvciB0aGUgc3ViLVRMVnMgY2FycmllZCBpbiBhbiBPU1BGDQogICBURSBMaW5rIFRMViAodHlw ZSAyKS4gIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBhIG5ldyBzdWItVExWDQogICBjb2Rl cG9pbnQgZm9yIHRoZSAxNTg4YXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIGNhcnJpZWQgd2l0aGlu IHRoZQ0KICAgUm91dGVyIExpbmsgVExWLg0KDQogICAgICBWYWx1ZSAgICAgICAgICAgIFN1Yi1U TFYgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlcw0KICAgICAgLS0tLS0gICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gICAgICAgICAgIC0tLS0tLS0tLS0NCiAgICAgICBUQkQgICAgICAgMTU4 OGF3YXJlIG5vZGUgc3ViLVRMViAgICAgICAgKHRoaXMgZG9jdW1lbnQpDQoNCjIxLjIuICBJQU5B IENvbnNpZGVyYXRpb25zIGZvciBJUy1JUw0KDQogICBJQU5BIGhhcyBkZWZpbmVkIGEgc3ViLXJl Z2lzdHJ5IGZvciB0aGUgc3ViLVRMVnMgY2FycmllZCBpbiB0aGUgSVMtSVMNCiAgIEV4dGVuZGVk IElTIFJlYWNhYmlsaXR5IFRMVi4gIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBhIG5ldyBz dWItDQogICBUTFYgY29kZS1wb2ludCBmb3IgdGhlIDE1ODhhd2FyZSBjYXBhYmlsaXR5IHN1Yi1U TFYgY2FycmllZCB3aXRoaW4NCiAgIHRoZSBFeHRlbmRlZCBJUyBSZWFjYWJpbGl0eSBUTFYuDQoN Cg0KICAgICAgVmFsdWUgICAgICAgICAgICBTdWItVExWICAgICAgICAgICAgICAgICAgIFJlZmVy ZW5jZXMNCiAgICAgIC0tLS0tICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAt LS0tLS0tLS0tDQogICAgICAgVEJEICAgICAgIDE1ODhhd2FyZSBub2RlIHN1Yi1UTFYgICAgICAg ICh0aGlzIGRvY3VtZW50KQ0KDQoyMS4zLiAgSUFOQSBDb25zaWRlcmF0aW9ucyBmb3IgUlNWUA0K DQogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBhc3NpZ24gYSBuZXcgQ2xhc3MgTnVtYmVyIGZvciAx NTg4IFBUUCBMU1ANCiAgIG9iamVjdCB0aGF0IGlzIHVzZWQgdG8gc2lnbmFsIFBUUCBMU1BzLg0K DQogICAxNTg4IFBUUCBMU1AgT2JqZWN0DQoNCiAgIENsYXNzLU51bSBvZiB0eXBlIDExYmJiYmJi DQoNCiAgIFN1Z2dlc3RlZCB2YWx1ZSBUQkQNCg0KICAgRGVmaW5lZCBDVHlwZTogMSAoMTU4OCBQ VFAgTFNQKQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAg ICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMxXQ0KDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDEyDQoNCg0KMjIuICBSZWZlcmVuY2VzDQoNCjIyLjEuICBOb3JtYXRpdmUg UmVmZXJlbmNlcw0KDQogICBbSUVFRV0gICAgIElFRUUgMTU4OC0yMDA4LCAiSUVFRSBTdGFuZGFy ZCBmb3IgYSBQcmVjaXNpb24gQ2xvY2sNCiAgICAgICAgICAgICAgU3luY2hyb25pemF0aW9uIFBy b3RvY29sIGZvciBOZXR3b3JrZWQgTWVhc3VyZW1lbnQgYW5kDQogICAgICAgICAgICAgIENvbnRy b2wgU3lzdGVtcyIuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMzOTg1XSAgQnJ5YW50 LCBTLiBhbmQgUC4gUGF0ZSwgIlBzZXVkbyBXaXJlIEVtdWxhdGlvbiBFZGdlLXRvLQ0KICAgICAg ICAgICAgICBFZGdlIChQV0UzKSBBcmNoaXRlY3R1cmUiLCBSRkMgMzk4NSwgTWFyY2ggMjAwNS4N Cg0KICAgW1JGQzQzODldICBUaGFsZXIsIEQuLCBUYWx3YXIsIE0uLCBhbmQgQy4gUGF0ZWwsICJO ZWlnaGJvciBEaXNjb3ZlcnkNCiAgICAgICAgICAgICAgUHJveGllcyAoTkQgUHJveHkpIiwgUkZD IDQzODksIEFwcmlsIDIwMDYuDQoNCiAgIFtSRkM0NDQ3XSAgTWFydGluaSwgTC4sIFJvc2VuLCBF LiwgRWwtQWF3YXIsIE4uLCBTbWl0aCwgVC4sIGFuZCBHLg0KICAgICAgICAgICAgICBIZXJvbiwg IlBzZXVkb3dpcmUgU2V0dXAgYW5kIE1haW50ZW5hbmNlIFVzaW5nIHRoZSBMYWJlbA0KICAgICAg ICAgICAgICBEaXN0cmlidXRpb24gUHJvdG9jb2wgKExEUCkiLCBSRkMgNDQ0NywgQXByaWwgMjAw Ni4NCg0KICAgW1JGQzQ0NDhdICBNYXJ0aW5pLCBMLiwgUm9zZW4sIEUuLCBFbC1BYXdhciwgTi4s IGFuZCBHLiBIZXJvbiwNCiAgICAgICAgICAgICAgIkVuY2Fwc3VsYXRpb24gTWV0aG9kcyBmb3Ig VHJhbnNwb3J0IG9mIEV0aGVybmV0IG92ZXIgTVBMUw0KICAgICAgICAgICAgICBOZXR3b3JrcyIs IFJGQyA0NDQ4LCBBcHJpbCAyMDA2Lg0KDQogICBbUkZDNDcyMF0gIE1hbGlzLCBBLiwgQWxsYW4s IEQuLCBhbmQgTi4gRGVsIFJlZ25vLCAiUHNldWRvd2lyZQ0KICAgICAgICAgICAgICBFbXVsYXRp b24gRWRnZS10by1FZGdlIChQV0UzKSBGcmFtZSBDaGVjayBTZXF1ZW5jZQ0KICAgICAgICAgICAg ICBSZXRlbnRpb24iLCBSRkMgNDcyMCwgTm92ZW1iZXIgMjAwNi4NCg0KICAgW1JGQzUwODVdICBO YWRlYXUsIFQuIGFuZCBDLiBQaWduYXRhcm8sICJQc2V1ZG93aXJlIFZpcnR1YWwgQ2lyY3VpdA0K ICAgICAgICAgICAgICBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChWQ0NWKTogQSBDb250cm9s IENoYW5uZWwgZm9yDQogICAgICAgICAgICAgIFBzZXVkb3dpcmVzIiwgUkZDIDUwODUsIERlY2Vt YmVyIDIwMDcuDQoNCiAgIFtSRkM1ODgwXSAgS2F0eiwgRC4gYW5kIEQuIFdhcmQsICJCaWRpcmVj dGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uDQogICAgICAgICAgICAgIChCRkQpIiwgUkZDIDU4 ODAsIEp1bmUgMjAxMC4NCg0KICAgW1JGQzU4ODRdICBBZ2dhcndhbCwgUi4sIEtvbXBlbGxhLCBL LiwgTmFkZWF1LCBULiwgYW5kIEcuIFN3YWxsb3csDQogICAgICAgICAgICAgICJCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGZvciBNUExTIExhYmVsDQogICAgICAgICAg ICAgIFN3aXRjaGVkIFBhdGhzIChMU1BzKSIsIFJGQyA1ODg0LCBKdW5lIDIwMTAuDQoNCjIyLjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJLUQuaWV0Zi1wd2UzLWZhdC1wd10NCiAg ICAgICAgICAgICAgQnJ5YW50LCBTLiwgRmlsc2ZpbHMsIEMuLCBEcmFmeiwgVS4sIEtvbXBlbGxh LCBWLiwgUmVnYW4sDQogICAgICAgICAgICAgIEouLCBhbmQgUy4gQW1hbnRlLCAiRmxvdyBBd2Fy ZSBUcmFuc3BvcnQgb2YgUHNldWRvd2lyZXMNCiAgICAgICAgICAgICAgb3ZlciBhbiBNUExTIFBh Y2tldCBTd2l0Y2hlZCBOZXR3b3JrIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZh dC1wdy0wNyAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxMS4NCg0KDQoNCg0KRGF2YXJpLCBl dCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1Bh Z2UgMzJdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCiAgIFtJU09dICAgICAgSVNPL0lFQyAx MDU4OToxOTkyLCAiSW50ZXJtZWRpYXRlIHN5c3RlbSB0byBJbnRlcm1lZGlhdGUNCiAgICAgICAg ICAgICAgc3lzdGVtIHJvdXRlaW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHByb3RvY29sIGZvciB1 c2UgaW4NCiAgICAgICAgICAgICAgY29uanVuY3Rpb24gd2l0aCB0aGUgUHJvdG9jb2wgZm9yIHBy b3ZpZGluZyB0aGUNCiAgICAgICAgICAgICAgQ29ubmVjdGlvbmxlc3MtbW9kZSBOZXR3b3JrIFNl cnZpY2UgKElTTyA4NDczKSIuDQoNCiAgIFtSRkMxMTk1XSAgQ2FsbG9uLCBSLiwgIlVzZSBvZiBP U0kgSVMtSVMgZm9yIHJvdXRpbmcgaW4gVENQL0lQIGFuZA0KICAgICAgICAgICAgICBkdWFsIGVu dmlyb25tZW50cyIsIFJGQyAxMTk1LCBEZWNlbWJlciAxOTkwLg0KDQogICBbUkZDMjMyOF0gIE1v eSwgSi4sICJPU1BGIFZlcnNpb24gMiIsIFNURCA1NCwgUkZDIDIzMjgsIEFwcmlsIDE5OTguDQoN CiAgIFtSRkMzNjMwXSAgS2F0eiwgRC4sIEtvbXBlbGxhLCBLLiwgYW5kIEQuIFlldW5nLCAiVHJh ZmZpYyBFbmdpbmVlcmluZw0KICAgICAgICAgICAgICAoVEUpIEV4dGVuc2lvbnMgdG8gT1NQRiBW ZXJzaW9uIDIiLCBSRkMgMzYzMCwNCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMuDQoNCiAg IFtSRkMzNzg0XSAgU21pdCwgSC4gYW5kIFQuIExpLCAiSW50ZXJtZWRpYXRlIFN5c3RlbSB0byBJ bnRlcm1lZGlhdGUNCiAgICAgICAgICAgICAgU3lzdGVtIChJUy1JUykgRXh0ZW5zaW9ucyBmb3Ig VHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIiwNCiAgICAgICAgICAgICAgUkZDIDM3ODQsIEp1bmUg MjAwNC4NCg0KICAgW1JGQzQ5NzBdICBMaW5kZW0sIEEuLCBTaGVuLCBOLiwgVmFzc2V1ciwgSlAu LCBBZ2dhcndhbCwgUi4sIGFuZCBTLg0KICAgICAgICAgICAgICBTaGFmZmVyLCAiRXh0ZW5zaW9u cyB0byBPU1BGIGZvciBBZHZlcnRpc2luZyBPcHRpb25hbA0KICAgICAgICAgICAgICBSb3V0ZXIg Q2FwYWJpbGl0aWVzIiwgUkZDIDQ5NzAsIEp1bHkgMjAwNy4NCg0KICAgW1JGQzQ5NzFdICBWYXNz ZXVyLCBKUC4sIFNoZW4sIE4uLCBhbmQgUi4gQWdnYXJ3YWwsICJJbnRlcm1lZGlhdGUNCiAgICAg ICAgICAgICAgU3lzdGVtIHRvIEludGVybWVkaWF0ZSBTeXN0ZW0gKElTLUlTKSBFeHRlbnNpb25z IGZvcg0KICAgICAgICAgICAgICBBZHZlcnRpc2luZyBSb3V0ZXIgSW5mb3JtYXRpb24iLCBSRkMg NDk3MSwgSnVseSAyMDA3Lg0KDQogICBbUkZDNTEyMF0gIFByenlnaWVuZGEsIFQuLCBTaGVuLCBO LiwgYW5kIE4uIFNoZXRoLCAiTS1JU0lTOiBNdWx0aQ0KICAgICAgICAgICAgICBUb3BvbG9neSAo TVQpIFJvdXRpbmcgaW4gSW50ZXJtZWRpYXRlIFN5c3RlbSB0bw0KICAgICAgICAgICAgICBJbnRl cm1lZGlhdGUgU3lzdGVtcyAoSVMtSVNzKSIsIFJGQyA1MTIwLCBGZWJydWFyeSAyMDA4Lg0KDQog ICBbUkZDNTMwNV0gIExpLCBULiBhbmQgSC4gU21pdCwgIklTLUlTIEV4dGVuc2lvbnMgZm9yIFRy YWZmaWMNCiAgICAgICAgICAgICAgRW5naW5lZXJpbmciLCBSRkMgNTMwNSwgT2N0b2JlciAyMDA4 Lg0KDQogICBbUkZDNTMyOV0gIElzaGlndXJvLCBLLiwgTWFucmFsLCBWLiwgRGF2ZXksIEEuLCBh bmQgQS4gTGluZGVtLA0KICAgICAgICAgICAgICAiVHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNp b25zIHRvIE9TUEYgVmVyc2lvbiAzIiwNCiAgICAgICAgICAgICAgUkZDIDUzMjksIFNlcHRlbWJl ciAyMDA4Lg0KDQogICBbUkZDNTM0MF0gIENvbHR1biwgUi4sIEZlcmd1c29uLCBELiwgTW95LCBK LiwgYW5kIEEuIExpbmRlbSwgIk9TUEYNCiAgICAgICAgICAgICAgZm9yIElQdjYiLCBSRkMgNTM0 MCwgSnVseSAyMDA4Lg0KDQogICBbUkZDMzI0Nl0gRGF2aWUsIGV0LiBhbC4sID9BbiBFeHBlZGl0 ZWQgRm9yd2FyZGluZyBQSEIgKFBlci1Ib3AgQmVoYXZpb3IpDQogICAgICAgICAgICAgUkZDIDMy NDYsIE1hcmNoIDIwMDINCg0KICAgW1JGQzI2OTddIEouIEhlaW5hbmVuIEouLCBHdWVyaW4sIFIu ICJBIFNpbmdsZSBSYXRlIFRocmVlIENvbG9yIE1hcmtlciwgDQogICAgICAgICAgICAgUkZDIDI2 OTcsIFNlcHRlbWJlciAxOTk5LiANCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMzXQ0KDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAg ICAgIE1hcmNoIDIwMTINCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgU2hhaHJhbSBEYXZh cmkNCiAgIEJyb2FkY29tIENvcnAuDQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0DQogICBVU0ENCg0K ICAgRW1haWw6IGRhdmFyaUBicm9hZGNvbS5jb20NCg0KDQogICBBbWl0IE9yZW4NCiAgIEJyb2Fk Y29tIENvcnAuDQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0DQogICBVU0ENCg0KICAgRW1haWw6IGFt aXRvQGJyb2FkY29tLmNvbQ0KDQoNCiAgIE1hbmF2IEJoYXRpYQ0KICAgQWxjYXRlbC1MdWNlbnQN CiAgIEJhbmdhbG9yZSwNCiAgIEluZGlhDQoNCiAgIEVtYWlsOiBtYW5hdi5iaGF0aWFAYWxjYXRl bC1sdWNlbnQuY29tDQoNCg0KICAgUGV0ZXIgUm9iZXJ0cw0KICAgQWxjYXRlbC1MdWNlbnQNCiAg IEthbmF0YSwNCiAgIENhbmFkYQ0KDQogICBFbWFpbDogcGV0ZXIucm9iZXJ0c0BhbGNhdGVsLWx1 Y2VudC5jb20NCg0KDQogICBMYXVyZW50IE1vbnRpbmkNCiAgIENpc2NvIFN5c3RlbXMNCiAgIFNh biBKb3NlIENBDQogICBVU0ENCg0KICAgRW1haWw6IGxtb250aW5pQGNpc2NvLmNvbQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEy LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDM0XQ0KDQo= --_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_-- From ping@pingpan.org Wed Mar 14 14:27:23 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF7721F8888 for ; Wed, 14 Mar 2012 14:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJhUcdhf08fg for ; Wed, 14 Mar 2012 14:27:23 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with SMTP id 6CD6621F887F for ; Wed, 14 Mar 2012 14:27:22 -0700 (PDT) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT2ENOSqfUFlBQAPRLn9eQlZHuoV8E4Vi@postini.com; Wed, 14 Mar 2012 14:27:22 PDT Received: by mail-wi0-f182.google.com with SMTP id hr14so2560921wib.5 for ; Wed, 14 Mar 2012 14:27:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=U1sXUUm92fFoMCmjAv6mCTGPZYnz7vanf3he7HC0Q1g=; b=e7vz5agq9ZXvf+Mft8Pu96K/h4I1DaA+ZeA1MzELjznpScEpOun32bP9lWaLhWj7H4 Dzdc/Vs0wVRcrPyO1Y5qprwBlBJNG2C4mLyK3wUOhr1PovKoNZJ/xATDcp+rd225RFVa DLYVaQkS8YTnjKUaot6HGqXf12hNZPgA0RWTIb8+a5CWpW76PSnBqPxXYBxQYuHnfhNs prZyTKODPKUCIj35NHEwcEhxFZH7ihlmL0iW+CkCUFlbxeToCmQZGgyX+dpI+SQ1Lwul uLvYGs2CEnMBScV2lcP514Q09d/1KZy+mG6MbFRLQM+0DNKHPXUMoFacYHNYzIwa+Ic1 TBjg== Received: by 10.50.188.138 with SMTP id ga10mr6989680igc.51.1331760441351; Wed, 14 Mar 2012 14:27:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.134.72 with HTTP; Wed, 14 Mar 2012 14:26:41 -0700 (PDT) In-Reply-To: <20120312062647.5804.6431.idtracker@ietfa.amsl.com> References: <20120312062647.5804.6431.idtracker@ietfa.amsl.com> From: Ping Pan Date: Wed, 14 Mar 2012 14:26:41 -0700 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=14dae93407f9085e4104bb3aa48d X-Gm-Message-State: ALoCoQmLEilqVM7znuSY3UxIUxUJzztFI+ZPBHjv85Q1GEar+fJQIWK25DFVnov/XNkqXIx4p5zu Subject: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:27:23 -0000 --14dae93407f9085e4104bb3aa48d Content-Type: text/plain; charset=UTF-8 Hi, Here is a draft that we have discussed in the past two IETF's and made a number of updates. As we have shown in the new revision, the problem we need to solve is very simple: we have multiple big bi-directional LSP's (say, GMPLS LSP's) between two edge nodes. The operators need to aggregate a large number of Ethernet connections over them. Each Ethernet connection is represented by two PW's: one on forwarding direction; another, reverse direction. For consistent services, we need to map PW-pairs onto the *same* bi-directional LSP. We are proposing of introducing an optional LDP extension to achieve this. Please take a look, provide the feedback and like to ask to be accepted as a WG document during IETF. (BTW, the name is perhaps misleading. This has nothing to do with MPLS-TP.) Regards, Ping ---------- Forwarded message ---------- From: Date: Sun, Mar 11, 2012 at 11:26 PM Subject: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDP extensions for Pseudowire Binding to LSP Tunnels Author(s) : Mach(Guoyi) Chen Wei Cao Attila Takacs Ping Pan Filename : draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt Pages : 15 Date : 2012-03-11 Many transport services require that user traffic, in the forms of Pseudowires (PW), to be delivered on a single co-routed bidirectional LSP or two LSPs that share the same routes. In addition, the user traffic may traverse through multiple transport networks. This document specifies an optional extension in LDP that enable the binding between PWs and the underlying LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --14dae93407f9085e4104bb3aa48d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

Here is a draft that we have discussed in the past two IETF'= s and made a number of updates.

As we have shown in the = new revision, the problem we need to solve is very simple: we have multiple= big bi-directional LSP's (say, GMPLS LSP's) between two edge nodes= . The operators need to aggregate=C2=A0a large number of Ethernet connectio= ns over them. Each Ethernet connection is represented by two PW's: one = on forwarding direction; another, reverse direction. For consistent service= s, we need to map PW-pairs onto the *same* bi-directional LSP.

We are proposing of introducing an optional LDP=C2=A0ex= tension=C2=A0to achieve this.

Please take a look, = provide the feedback and like to ask to be accepted as a WG document during= IETF.

(BTW, the name is perhaps misleading. This has nothing = to do with MPLS-TP.)

Regards,

=
Ping



---------- Forwa= rded message ----------
From: <internet-drafts@ietf.org>
= Date: Sun, Mar 11, 2012 at 11:26 PM
Subject: I-D Action: draft-cao-pwe3-= mpls-tp-pw-over-bidir-lsp-05.txt
To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : LDP = extensions for Pseudowire Binding to LSP Tunnels
=C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Mach(Guoyi) Ch= en
=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=A0Wei Cao
=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=A0Attila Takacs
=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=A0Ping Pan
=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-cao= -pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2012-03-11

=C2=A0 Many transport services require that user traffic, in the forms of<= br> =C2=A0 Pseudowires (PW), to be delivered on a single co-routed bidirection= al
=C2=A0 LSP or two LSPs that share the same routes. =C2=A0In addition, the = user
=C2=A0 traffic may traverse through multiple transport networks.

=C2=A0 This document specifies an optional extension in LDP that enable th= e
=C2=A0 binding between PWs and the underlying LSPs.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/= draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/dr= aft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--14dae93407f9085e4104bb3aa48d-- From skraza@cisco.com Wed Mar 14 15:40:50 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916511E8083 for ; Wed, 14 Mar 2012 15:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.813 X-Spam-Level: X-Spam-Status: No, score=-8.813 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZf7wMfIRkHl for ; Wed, 14 Mar 2012 15:40:46 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id EEF7B21F867F for ; Wed, 14 Mar 2012 15:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=25845; q=dns/txt; s=iport; t=1331764846; x=1332974446; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=PEKBtv6eZs8+7tgIDXD/ftD0udVy1rqkgmNmoTmRXZk=; b=HylzEz4aFDBnN/1Ae6u9QT907b/5Ptf8bt66L7iCV3iHzRjGU6RqPGzF v/eo9DnXC12qVHOsyodFs5fwEKFetIdhGv4enS/7RtG6xHwTafoBfMRxt PXb6/taQ7dpaHnsNL5sV1UEqKmvRYCJhT705Z2eEffQQpVlyvVN1O/UL6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKQdYU+tJXHB/2dsb2JhbABAA4JFsnR0gQeCCQEBAQMBAQEBCQYBKhgRCBANAQgRAwECITUoCAEBBAESCRmHYwULmx6fK41YgycEiCQzjH+LMYMPgWiDBA X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208,217";a="66545685" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2012 22:40:45 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2EMej4b004068; Wed, 14 Mar 2012 22:40:45 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 17:40:45 -0500 Received: from 10.65.77.22 ([10.65.77.22]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Mar 2012 22:40:44 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 14 Mar 2012 18:41:02 -0500 From: Kamran Raza To: Ping Pan , Message-ID: Thread-Topic: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt Thread-Index: Ac0CM4h70Zofiuir802MxFmGp15ohg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414595263_12502127" X-OriginalArrivalTime: 14 Mar 2012 22:40:45.0380 (UTC) FILETIME=[7E939040:01CD0233] Subject: Re: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 22:40:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414595263_12502127 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, I have following high level comments: 1. Need reformat of Binding TLV and its sub TLV 2. Suggest re-work procedures to withdraw such an advertised binding 3. Consider LDP Capabilities [RFC5561] to bind this new signaling with an LDP capability=20 4. Add section on =B3PW Typed Wildcard FEC=B2 intersections with this extension= . Now, the detailed comments as follow: 1. Section 2.1: PSN Tunnel Binding TLV A) This TLV is sent without any LDP capability negotiation. Should you not bind this optional info with some LDP capabilities [ LDP Capabilities [RFC5561] ]. B) Fig 3: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| PSN Tunnel Binding (TBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ PSN Tunnel Sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - U/F are both defined as 1/1. Did you mean to define them as 1/0 ? - Length is defined as 2 octets. Assuming =B3PSN Tunnel Sub TLV=B2 is an optional field of this TLV, then length is (2 + sizeof(PSN Tunnel Sub-TLV). - Flags are defined as +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be Zero |C|S|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 For consistency with other defintions, we should define them as +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|S|T| MUST be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 2) Section 2.1.1: PSN Tunnel Sub-TLV a) The format of both IPv4 and IPv6 sub TLV is same (with variable lengths). I think there is no need to define two separate sub-TLVs and define a single sub-TLV with Address Family encoded into it and the fields encoded/interpreted accordingly. b) Since this is a sub-TLV, we do not need U/F bits. c) Generally for sub-TLVs, an octect suffices for sub-LTV type, and same i= s true for sub-TLV length. d) If you are using an =B3optional=B2 field in the middle of a sub-TLV, we wil= l need some sort of flag to indicate if this field is present. I=B9d rather suggest removing the =B3optional=B2 part and make it mandatory but use some reserved value (e.g. 0) to indicate not-populated. I suggest the following new format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP PSN Tun. | Length | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Node ID (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Tunnel Number | Source LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Node ID (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Tunnel Number | Destination LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Address Family is IANA defined address family. It=B9s value must be either 1 (IPv4) or 2 (IPv6). =B3Source Node ID=B2 and =B3Destination Node ID=B2 field are IP addresses encoded according to Address Family. 3) Section 3: Theory of Operation =20 For withdrawl of Tunnel bindings, there are couple of options: 1. Send another Label Mapping without Tunnel binding TLV (specified in this doc)=20 2. Use Label Withdraw 3. Use LDP Notification Ref to #1, the receipt of a new Label mapping msg with no change in PW labe= l (but due to piggyback info change) sounds bit awkward, and hence I=B9d sugges= t to use new LDP Notification alongwith this TLV to withdraw previous advertised bindings. #2 can be used only when original PW FEC binding is also being withdrawn. I= f an LSR just needs to withdraw the PSN Tunel Binding, it sends this TLV in a Notification msg. This also means that we need to either add some kind of =B3A=B2 flag bit in the =B3PSN Tunnel Binding=B2 TLV to indicate advertise or withdraw 4) Section 4: PSN Binding Operation for SS-PW =B3.. it MUST reply a Label Release message with status code set to "Reject to use the suggested tunnel/LSPs" and the received PSN Tunnel Binding TLV.=B2 Couple of issues here: 1. If the intent is just to reject the =B3PSN Tunnel Binding=B2 but keep PW label, then Label Release is a wrong msg to sent back. 2. Label Release messages do not contain an status TLV. I suggest send a separate Notification msg just to inform reject of Tunnel binding. 5) Section 7.1.1 IANA Consideration: PSN Tunnel Sub-TLVs Where does this new requested Sub-TLV name space resides ? I suggest it should be created under =B3PW Namespaces (pew3-parameters)=B2. Rgds. -- Kamran On 12-03-14 4:26 PM, "Ping Pan" wrote: > Hi, >=20 > Here is a draft that we have discussed in the past two IETF's and made a > number of updates. >=20 > As we have shown in the new revision, the problem we need to solve is ver= y > simple: we have multiple big bi-directional LSP's (say, GMPLS LSP's) betw= een > two edge nodes. The operators need to aggregate=A0a large number of Etherne= t > connections over them. Each Ethernet connection is represented by two PW'= s: > one on forwarding direction; another, reverse direction. For consistent > services, we need to map PW-pairs onto the *same* bi-directional LSP. >=20 > We are proposing of introducing an optional LDP=A0extension=A0to achieve this= . >=20 > Please take a look, provide the feedback and like to ask to be accepted a= s a > WG document during IETF. >=20 > (BTW, the name is perhaps misleading. This has nothing to do with MPLS-TP= .) >=20 > Regards, >=20 > Ping >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Sun, Mar 11, 2012 at 11:26 PM > Subject: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt > To: i-d-announce@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : LDP extensions for Pseudowire Binding to LSP Tu= nnels > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mach(Guoyi) Chen > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wei Cao > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Attila Takacs > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ping Pan > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-11 >=20 > =A0 Many transport services require that user traffic, in the forms of > =A0 Pseudowires (PW), to be delivered on a single co-routed bidirectional > =A0 LSP or two LSPs that share the same routes. =A0In addition, the user > =A0 traffic may traverse through multiple transport networks. >=20 > =A0 This document specifies an optional extension in LDP that enable the > =A0 binding between PWs and the underlying LSPs. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-= lsp-0 > 5.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-l= sp-05 > .txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft=20 > > directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --B_3414595263_12502127 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp= -05.txt Hi,

I have following high level comments:

  1. Need reformat of Binding TLV and its sub TLV
  2. Suggest re-work procedures to withdraw such an advertise= d binding
  3. Consider LDP Capabilities [RFC5561] to bind this new sig= naling with an LDP capability
  4. Add section on “PW Typed Wildcard FEC” inter= sections with this extension.

Now, the detailed comments as follow:

1.  Section 2.1: PSN Tunnel Binding TLV

A) This TLV is sent without any LDP capability negotiation. Should you not = bind this optional info with some LDP capabilities [ LDP Capabilities [RFC55= 61] ].

B) Fig 3:

     0        &= nbsp;          1  &nb= sp;            &= nbsp;   2         &nb= sp;         3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
    |1|1| PSN Tunnel Binding (TBA)  |   =           Length  &nb= sp;         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
    |         &= nbsp;    Flag        =      |        &n= bsp;   Reserved        &nb= sp;  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
    ~         &= nbsp;            = ; PSN Tunnel Sub-TLV         &n= bsp;            = ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+


  - U/F are both defined as 1/1. Did you mean to define them as 1= /0 ?
  - Length is defined as 2 octets. Assuming “PSN Tunnel Sub= TLV” is an optional field of this TLV, then length is (2 + sizeof(PSN= Tunnel Sub-TLV).
  - Flags are defined as    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     MUST be Zero    =     |C|S|T|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  For consistency with other defintions, we should define them as=

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|S|T|     MUST be Zero   =      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  
2) Section 2.1.1: PSN Tunnel Sub-TLV

 a) The format of both IPv4 and IPv6 sub TLV is same (with variable le= ngths). I think there is no need to define two separate sub-TLVs and define = a single sub-TLV with Address Family encoded into it and the fields encoded/= interpreted accordingly.

 b) Since this is a sub-TLV, we do not need U/F bits.

 c) Generally for sub-TLVs, an octect suffices for sub-LTV type, and s= ame is true for sub-TLV length.

 d) If you are using an “optional” field in the middle of = a sub-TLV, we will need some sort of flag to indicate if this field is prese= nt. I’d rather suggest removing the “optional” part and ma= ke it mandatory but use some reserved value (e.g. 0) to indicate not-populat= ed.

 I suggest the following new format


       0      &= nbsp;            = ;1             &= nbsp;     2       &nb= sp;           3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
      | IP PSN Tun.   | Length &nbs= p;      |       =  Address Family         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
      |       &= nbsp;            = ;  Source Global ID        &nbs= p;            &n= bsp;   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
      |       &= nbsp;            = ;   Source Node ID  (variable length)    =    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Source = Tunnel Number     | Source LSP Number    =          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
      |       &= nbsp;            = ;Destination Global ID          = ;            |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
      |       &= nbsp;            = ; Destination Node ID  (variable length)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Destination Tunnel Number=   | Destination LSP Number       &n= bsp;|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+


 where Address Family is IANA defined address family. It’s value= must be either 1 (IPv4) or 2 (IPv6). “Source Node ID” and ̶= 0;Destination Node ID” field are IP addresses encoded according to Add= ress Family.

3) Section 3: Theory of Operation
 
For withdrawl of Tunnel bindings, there are couple of options:
  1. Send another Label Mapping without Tunnel bi= nding TLV (specified in this doc)
  2. <= SPAN STYLE=3D'font-size:10pt'>Use Label Withdraw
  3. <= SPAN STYLE=3D'font-size:10pt'>Use LDP Notification
=
Ref to #1, the receipt of a new Label mapping msg with no change in PW labe= l (but due to piggyback info change) sounds bit awkward, and hence I’d= suggest to use new LDP Notification alongwith this TLV to withdraw previous= advertised bindings.
#2 can be used only when original PW FEC binding is also being withdrawn. I= f an LSR just needs to withdraw the PSN Tunel Binding, it sends this TLV in = a Notification msg. This also means that we need to either add some kind of = “A” flag bit in the “PSN Tunnel Binding” TLV to indi= cate advertise or withdraw

4) Section 4: PSN Binding Operation for SS-PW

“.. it MUST reply a Label Release message with status code
   set to "Reject to use the suggested tunnel/LSPs"= ; and the received PSN
   Tunnel Binding TLV.”


Couple of issues here:

  1. If the intent is just to reject the “P= SN Tunnel Binding” but keep PW label, then Label Release is a wrong ms= g to sent back.
  2. <= SPAN STYLE=3D'font-size:10pt'>Label Release messages do not contain an status = TLV. I suggest send a separate Notification msg just to inform reject of Tun= nel binding.
=
5) Section 7.1.1 IANA Consideration: PSN Tunnel Sub-TLVs

Where does this new requested Sub-TLV name space resides ? I suggest it sho= uld be created under “PW Namespaces (pew3-parameters)”.

Rgds.
-- Kamran

On 12-03-14 4:26 PM, "Ping Pan" <pi= ng@pingpan.org> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi,

Here is a draft that we have discussed in the past two IETF's and made a nu= mber of updates.

As we have shown in the new revision, the problem we need to solve is very = simple: we have multiple big bi-directional LSP's (say, GMPLS LSP's) between= two edge nodes. The operators need to aggregate=A0a large number of Ethernet = connections over them. Each Ethernet connection is represented by two PW's: = one on forwarding direction; another, reverse direction. For consistent serv= ices, we need to map PW-pairs onto the *same* bi-directional LSP.

We are proposing of introducing an optional LDP=A0extension=A0to achieve this.<= BR>
Please take a look, provide the feedback and like to ask to be accepted as = a WG document during IETF.

(BTW, the name is perhaps misleading. This has nothing to do with MPLS-TP.)=

Regards,

Ping



---------- Forwarded message ----------
From:  <internet-drafts@ietf.org= >
Date: Sun, Mar 11, 2012 at 11:26 PM
Subject: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : LDP extensions for Pseudowire Binding to LSP= Tunnels
 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mach(Guoyi) Chen
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wei Cao
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Attila Takacs
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ping Pan
 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.= txt
 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15
 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-11

 =A0 Many transport services require that user traffic, in the forms of<= BR>  =A0 Pseudowires (PW), to be delivered on a single co-routed bidirection= al
 =A0 LSP or two LSPs that share the same routes. =A0In addition, the user<= BR>  =A0 traffic may traverse through multiple transport networks.

 =A0 This document specifies an optional extension in LDP that enable th= e
 =A0 binding between PWs and the underlying LSPs.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cao-pwe3-mpls-t= p-pw-over-bidir-lsp-05.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-= pw-over-bidir-lsp-05.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/i-d-announce
Internet-Draft <https://www.ietf.org/mailman/listinfo/i-d-announceInterne= t-Draft>  directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/i= etf/1shadow-sites.txt


___________= ____________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3

--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.co= m



--B_3414595263_12502127-- From ping@pingpan.org Wed Mar 14 16:37:16 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36D11E808A for ; Wed, 14 Mar 2012 16:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVWEy7zkEtJK for ; Wed, 14 Mar 2012 16:37:14 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with SMTP id 2D6D611E8075 for ; Wed, 14 Mar 2012 16:37:14 -0700 (PDT) Received: from mail-iy0-f178.google.com ([209.85.210.178]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT2ErqQLIhcbFC5te+hU00D5J8wzjPA/K@postini.com; Wed, 14 Mar 2012 16:37:14 PDT Received: by mail-iy0-f178.google.com with SMTP id l21so3699681iak.23 for ; Wed, 14 Mar 2012 16:37:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=aW0UbqbOhoFQHQFerMId0Y+4s2XbbuK6PRn7TpNc4PI=; b=ZG22enV9s9qnstz/9R4lt1j8pf+gkWemrWeLqRbLh4BVyqgAK1gx2JO9VrX5M1aGsi sIlvtqiSO/nCXhf3JK0CdTfDF1KLLdJ8bXH8HYZcJweH1+knt0Fzt6jCgMsY6fIVP4CR eBhAEyzsiDeqkZDoEkMVfH+MAt2M7wA+7Ykb/TRXG5gNIzJGq0S+7DJJd8Cg0FiK3y2j SsYFeDa9txeVLs3BVOLCtw1k75dteXBtURfPlhJy2TSvboV59Jclc+LtBCxEQAEPgbGs ro5aB13xkbhnhn5Qp0sD5zMhAAIJb9y06/gPrT3GWmfR1i5zCfu0KT2D/pMND25Yck4J ob2A== Received: by 10.50.188.138 with SMTP id ga10mr7256153igc.51.1331768233235; Wed, 14 Mar 2012 16:37:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.134.72 with HTTP; Wed, 14 Mar 2012 16:36:33 -0700 (PDT) In-Reply-To: References: From: Ping Pan Date: Wed, 14 Mar 2012 16:36:33 -0700 Message-ID: To: Kamran Raza Content-Type: multipart/alternative; boundary=14dae93407f977164c04bb3c74d2 X-Gm-Message-State: ALoCoQlee5Q/SgFTvF+BActSQWQINV6gMrL7G+HhL51iz3cvR4qpkutGu7AFev+90sRzrWRpJhZy Cc: pwe3@ietf.org Subject: Re: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 23:37:16 -0000 --14dae93407f977164c04bb3c74d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cool! Will make the fix accordingly. Best regards, Ping On Wed, Mar 14, 2012 at 4:41 PM, Kamran Raza wrote: > Hi, > > I have following high level comments: > > > 1. Need reformat of Binding TLV and its sub TLV > 2. Suggest re-work procedures to withdraw such an advertised binding > 3. Consider LDP Capabilities [RFC5561] to bind this new signaling with > an LDP capability > 4. Add section on =E2=80=9CPW Typed Wildcard FEC=E2=80=9D intersection= s with this > extension. > > > Now, the detailed comments as follow: > > 1. Section 2.1: PSN Tunnel Binding TLV > > A) This TLV is sent without any LDP capability negotiation. Should you no= t > bind this optional info with some LDP capabilities [ LDP Capabilities > [RFC5561] ]. > > B) Fig 3: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|1| PSN Tunnel Binding (TBA) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flag | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ PSN Tunnel Sub-TLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > - U/F are both defined as 1/1. Did you mean to define them as 1/0 ? > - Length is defined as 2 octets. Assuming =E2=80=9CPSN Tunnel Sub TLV= =E2=80=9D is an > optional field of this TLV, then length is (2 + sizeof(PSN Tunnel Sub-TLV= ). > - Flags are defined as > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MUST be Zero |C|S|T| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For consistency with other defintions, we should define them as > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C|S|T| MUST be Zero | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 2) Section 2.1.1: PSN Tunnel Sub-TLV > > a) The format of both IPv4 and IPv6 sub TLV is same (with variable > lengths). I think there is no need to define two separate sub-TLVs and > define a single sub-TLV with Address Family encoded into it and the field= s > encoded/interpreted accordingly. > > b) Since this is a sub-TLV, we do not need U/F bits. > > c) Generally for sub-TLVs, an octect suffices for sub-LTV type, and same > is true for sub-TLV length. > > d) If you are using an =E2=80=9Coptional=E2=80=9D field in the middle of= a sub-TLV, we > will need some sort of flag to indicate if this field is present. I=E2=80= =99d > rather suggest removing the =E2=80=9Coptional=E2=80=9D part and make it m= andatory but use > some reserved value (e.g. 0) to indicate not-populated. > > I suggest the following new format > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IP PSN Tun. | Length | Address Family | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Global ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Node ID (variable length) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Tunnel Number | Source LSP Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination Global ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination Node ID (variable length) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination Tunnel Number | Destination LSP Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > where Address Family is IANA defined address family. It=E2=80=99s value = must be > either 1 (IPv4) or 2 (IPv6). =E2=80=9CSource Node ID=E2=80=9D and =E2=80= =9CDestination Node ID=E2=80=9D > field are IP addresses encoded according to Address Family. > > 3) Section 3: Theory of Operation > > For withdrawl of Tunnel bindings, there are couple of options: > > 1. Send another Label Mapping without Tunnel binding TLV (specified in > this doc) > 2. Use Label Withdraw > 3. Use LDP Notification > > > Ref to #1, the receipt of a new Label mapping msg with no change in PW > label (but due to piggyback info change) sounds bit awkward, and hence I= =E2=80=99d > suggest to use new LDP Notification alongwith this TLV to withdraw previo= us > advertised bindings. > #2 can be used only when original PW FEC binding is also being withdrawn. > If an LSR just needs to withdraw the PSN Tunel Binding, it sends this TLV > in a Notification msg. This also means that we need to either add some ki= nd > of =E2=80=9CA=E2=80=9D flag bit in the =E2=80=9CPSN Tunnel Binding=E2=80= =9D TLV to indicate advertise or > withdraw > > 4) Section 4: PSN Binding Operation for SS-PW > > =E2=80=9C.. it MUST reply a Label Release message with status code > set to "Reject to use the suggested tunnel/LSPs" and the received PSN > Tunnel Binding TLV.=E2=80=9D > > > Couple of issues here: > > > 1. If the intent is just to reject the =E2=80=9CPSN Tunnel Binding=E2= =80=9D but keep > PW label, then Label Release is a wrong msg to sent back. > 2. Label Release messages do not contain an status TLV. I suggest send > a separate Notification msg just to inform reject of Tunnel binding. > > > 5) Section 7.1.1 IANA Consideration: PSN Tunnel Sub-TLVs > > Where does this new requested Sub-TLV name space resides ? I suggest it > should be created under =E2=80=9CPW Namespaces (pew3-parameters)=E2=80=9D= . > > Rgds. > -- Kamran > > On 12-03-14 4:26 PM, "Ping Pan" wrote: > > Hi, > > Here is a draft that we have discussed in the past two IETF's and made a > number of updates. > > As we have shown in the new revision, the problem we need to solve is ver= y > simple: we have multiple big bi-directional LSP's (say, GMPLS LSP's) > between two edge nodes. The operators need to aggregate a large number of > Ethernet connections over them. Each Ethernet connection is represented b= y > two PW's: one on forwarding direction; another, reverse direction. For > consistent services, we need to map PW-pairs onto the *same* bi-direction= al > LSP. > > We are proposing of introducing an optional LDP extension to achieve this= . > > Please take a look, provide the feedback and like to ask to be accepted a= s > a WG document during IETF. > > (BTW, the name is perhaps misleading. This has nothing to do with MPLS-TP= .) > > Regards, > > Ping > > > > ---------- Forwarded message ---------- > From: > Date: Sun, Mar 11, 2012 at 11:26 PM > Subject: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : LDP extensions for Pseudowire Binding to LSP > Tunnels > Author(s) : Mach(Guoyi) Chen > Wei Cao > Attila Takacs > Ping Pan > Filename : draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt > Pages : 15 > Date : 2012-03-11 > > Many transport services require that user traffic, in the forms of > Pseudowires (PW), to be delivered on a single co-routed bidirectional > LSP or two LSPs that share the same routes. In addition, the user > traffic may traverse through multiple transport networks. > > This document specifies an optional extension in LDP that enable the > binding between PWs and the underlying LSPs. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-= lsp-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-l= sp-05.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft < > https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> > directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > ------------------------------ > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > -- > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc., > Kanata, ON, K2K 3E8, Canada > Ph: +1 (613) 254-4520 > *http://www.cisco.com* > > > > --14dae93407f977164c04bb3c74d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cool! Will make the fix accordingly.=C2=A0

Best regards,=

Ping

On Wed, Ma= r 14, 2012 at 4:41 PM, Kamran Raza <skraza@cisco.com> wrote:
Hi,

I have following high level comments:

  1. Need reformat of Binding TLV and its sub TLV
  2. Suggest re-work procedures to withdraw such an= advertised binding
  3. Consider LDP Capabilities [RFC5561] to bind th= is new signaling with an LDP capability
  4. Add section on =E2=80=9CPW Typed Wildcard FEC= =E2=80=9D intersections with this extension.
<= span style=3D"font-size:11pt">
Now, the detailed comments as follow:

1. =C2=A0Section 2.1: PSN Tunnel Binding TLV

A) This TLV is sent without any LDP capability negotiation. Should you not = bind this optional info with some LDP capabilities [ LDP Capabilities [RFC5= 561] ].

B) Fig 3:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 =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=A01 =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=A02 =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=A03
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0=C2=A0=C2=A0=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0|1|1| PSN Tunnel Binding (TBA) =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=A0Length =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=C2=A0=C2=A0Flag =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=A0Reserved =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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0PSN Tunnel Sub-TLV =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- U/F are both defined as 1/1. Did you mean to define them as 1= /0 ?
=C2=A0=C2=A0- Length is defined as 2 octets. Assuming =E2=80=9CPSN Tunnel S= ub TLV=E2=80=9D is an optional field of this TLV, then length is (2 + sizeo= f(PSN Tunnel Sub-TLV).
=C2=A0=C2=A0- Flags are defined as =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=A0MUST be Zero =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0|C|S|T|
=C2=A0=C2=A0=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0
=C2=A0=C2=A0For consistency with other defintions, we should define them as=

=C2=A0=C2=A0=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0|C|S|T| =C2=A0=C2=A0=C2=A0=C2=A0MUST be Zero =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0
2) Section 2.1.1: PSN Tunnel Sub-TLV

=C2=A0a) The format of both IPv4 and IPv6 sub TLV is same (with variable le= ngths). I think there is no need to define two separate sub-TLVs and define= a single sub-TLV with Address Family encoded into it and the fields encode= d/interpreted accordingly.

=C2=A0b) Since this is a sub-TLV, we do not need U/F bits.

=C2=A0c) Generally for sub-TLVs, an octect suffices for sub-LTV type, and s= ame is true for sub-TLV length.

=C2=A0d) If you are using an =E2=80=9Coptional=E2=80=9D field in the middle= of a sub-TLV, we will need some sort of flag to indicate if this field is = present. I=E2=80=99d rather suggest removing the =E2=80=9Coptional=E2=80=9D= part and make it mandatory but use some reserved value (e.g. 0) to indicat= e not-populated.

=C2=A0I suggest the following new format


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 =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= =A01 =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=A02 =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= 3
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| IP PSN Tun. =C2=A0=C2=A0| Length =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=A0Address Family =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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Source Global ID =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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
=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=A0Source Node ID =C2=A0(variable length) =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=A0Source = Tunnel Number =C2=A0=C2=A0=C2=A0=C2=A0| Source LSP Number =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= =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= =A0Destination Global ID =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=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=A0Destination Node ID =C2=A0(variable length) =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=A0Destination Tunnel Number= =C2=A0=C2=A0| Destination LSP Number =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=A0where Address Family is IANA defined address family. It=E2=80=99s val= ue must be either 1 (IPv4) or 2 (IPv6). =E2=80=9CSource Node ID=E2=80=9D an= d =E2=80=9CDestination Node ID=E2=80=9D field are IP addresses encoded acco= rding to Address Family.

3) Section 3: Theory of Operation
=C2=A0
For withdrawl of Tunnel bindings, there are couple of options:
  1. Send another Label Mapping without Tunnel bindin= g TLV (specified in this doc)
  2. Use Label Withdraw
  3. Use LDP Notification

Ref to #1, the receipt of a new Label mapping msg with no change in PW labe= l (but due to piggyback info change) sounds bit awkward, and hence I=E2=80= =99d suggest to use new LDP Notification alongwith this TLV to withdraw pre= vious advertised bindings.
#2 can be used only when original PW FEC binding is also being withdrawn. I= f an LSR just needs to withdraw the PSN Tunel Binding, it sends this TLV in= a Notification msg. This also means that we need to either add some kind o= f =E2=80=9CA=E2=80=9D flag bit in the =E2=80=9CPSN Tunnel Binding=E2=80=9D = TLV to indicate advertise or withdraw

4) Section 4: PSN Binding Operation for SS-PW

=E2=80=9C.. it MUST reply a Label Release message with status code
=C2=A0=C2=A0=C2=A0set to "Reject to use the suggested tunnel/LSPs"= ; and the received PSN
=C2=A0=C2=A0=C2=A0Tunnel Binding TLV.=E2=80=9D


Couple of issues here:

  1. If the intent is just to reject the =E2=80=9CPSN= Tunnel Binding=E2=80=9D but keep PW label, then Label Release is a wrong m= sg to sent back.
  2. Label Release messages do not contain an status= TLV. I suggest send a separate Notification msg just to inform reject of T= unnel binding.

5) Section 7.1.1 IANA Consideration: PSN Tunnel Sub-TLVs

Where does this new requested Sub-TLV name space resides ? I suggest it sho= uld be created under =E2=80=9CPW Namespaces (pew3-parameters)=E2=80=9D.

Rgds.
-- Kamran

On 12-03-14 4:26 PM, "Ping Pan" <ping@pingpan.org> wrote:

Hi,

Here is a draft that we have discussed in the past two IETF's and made = a number of updates.

As we have shown in the new revision, the problem we need to solve is very = simple: we have multiple big bi-directional LSP's (say, GMPLS LSP's= ) between two edge nodes. The operators need to aggregate=C2=A0a large numb= er of Ethernet connections over them. Each Ethernet connection is represent= ed by two PW's: one on forwarding direction; another, reverse direction= . For consistent services, we need to map PW-pairs onto the *same* bi-direc= tional LSP.

We are proposing of introducing an optional LDP=C2=A0extension=C2=A0to achi= eve this.

Please take a look, provide the feedback and like to ask to be accepted as = a WG document during IETF.

(BTW, the name is perhaps misleading. This has nothing to do with MPLS-TP.)=

Regards,

Ping



---------- Forwarded message ----------
From: =C2=A0<internet-drafts@ietf.org>
Date: Sun, Mar 11, 2012 at 11:26 PM
Subject: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := LDP extensions for Pseudowire Binding to LSP Tunnels
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Mach(Guoy= i) Chen
=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=A0Wei Cao
=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=A0Attila Takacs
=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=A0Ping Pan
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draf= t-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 15
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 2012-03-11

=C2=A0=C2=A0 Many transport services require that user traffic, in the form= s of
=C2=A0=C2=A0 Pseudowires (PW), to be delivered on a single co-routed bidire= ctional
=C2=A0=C2=A0 LSP or two LSPs that share the same routes. =C2=A0In addition,= the user
=C2=A0=C2=A0 traffic may traverse through multiple transport networks.

=C2=A0=C2=A0 This document specifies an optional extension in LDP that enab= le the
=C2=A0=C2=A0 binding between PWs and the underlying LSPs.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/= draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/dr= aft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft <https://www.ietf.org/mailman/listinf= o/i-d-announceInternet-Draft> =C2=A0directories: http://www.ietf.org/shadow.html<= /a>
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______= ________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com




--14dae93407f977164c04bb3c74d2-- From gregimirsky@gmail.com Wed Mar 14 19:07:47 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047BB21F86D1; Wed, 14 Mar 2012 19:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMzLtOPGfIYn; Wed, 14 Mar 2012 19:07:46 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B12A421F86D0; Wed, 14 Mar 2012 19:07:45 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2892532ggm.31 for ; Wed, 14 Mar 2012 19:07:45 -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=J+MyZBV34GDYczu5F0l9tQ2V9dyZAJnroW3jyNgQ9FU=; b=UC9UFDMKOnqdy1qEQ8zpy5khTJq8NHYtrrCpjrW2Tn9ejok4ATF33pZNdBGZwrVohr MYmgM+hNafj6rb+HiWqmjHhgBCFdxgD/xORv14NQCJK+aDW3gczvxhuIavcUgHe4VS4j mpVWvYsnaoNShLChojYAo5DD09TJIpiMoD0zLungRaaplx6TxioxE+eQ3zZj8k5g58tD bd9wnFpy5CnWhUl3ltllM5yVMuBnP24H4x0ohskE2vmgAtMeWmeBR+6PuJPNW/T+iQpc zt3F0+1NQis3ullC8ZtAxfzIVdjcbQ2ukGE1HnvFiMfuLYQy8CzLddQYKO0b07+9m3jC jcmg== MIME-Version: 1.0 Received: by 10.60.4.162 with SMTP id l2mr6438142oel.3.1331777265088; Wed, 14 Mar 2012 19:07:45 -0700 (PDT) Received: by 10.182.114.98 with HTTP; Wed, 14 Mar 2012 19:07:44 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 14 Mar 2012 19:07:44 -0700 Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=e89a8ff1c5aece36f804bb3e8e44 Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:07:47 -0000 --e89a8ff1c5aece36f804bb3e8e44 Content-Type: text/plain; charset=ISO-8859-1 Dear Shahram, perhaps because of "This document provides extensions to OSPF, ISIS ..." review by OSPF and ISIS WGs should be solicited as well. Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari wrote: > Hi,**** > > ** ** > > Please find attached the latest 1588 over MPLS draft (03). Since cut-off > date was yesterday, we will upload this after the Paris meeting.**** > > Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some > aspects from each of these groups are used in this draft. **** > > ** ** > > We will present this draft in the relevant WGs in Paris.**** > > ** ** > > Regards,**** > > Shahram Davari**** > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --e89a8ff1c5aece36f804bb3e8e44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shahram,
perhaps because of "This document provides extensions= to OSPF, ISIS ..." review by OSPF and ISIS WGs should be solicited as= well.

Regards,
Greg

On Mon, Ma= r 12, 2012 at 5:16 PM, Shahram Davari <davari@broadcom.com> wrote:

Hi,

=A0

Please find attached the latest 1588 over MPLS draft= (03). Since cut-off date was yesterday, we will upload this after the Pari= s meeting.

Review is required from = TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from each of these gro= ups are used in this draft.

=A0

We will = present this draft in the relevant WGs in Paris.

=A0

Regards,<= u>

Shahram Davari


____= ___________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


--e89a8ff1c5aece36f804bb3e8e44-- From DanielC@orckit.com Thu Mar 15 05:38:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CE521F8650 for ; Thu, 15 Mar 2012 05:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2qmRh2c39si for ; Thu, 15 Mar 2012 05:38:21 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0D421F8503 for ; Thu, 15 Mar 2012 05:38:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD02A8.E3D05F1F" Date: Thu, 15 Mar 2012 14:38:18 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307670E33@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pwe3-iccp interaction with draft-pw-redundancy-bit Thread-Index: Ac0CqH/qtyJRd8+JRXuyEnS5aYeGKQ== From: "Daniel Cohn" To: Subject: [PWE3] draft-ietf-pwe3-iccp interaction with draft-pw-redundancy-bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 12:38:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD02A8.E3D05F1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi draft-ietf-pwe3-iccp authors and list at large, =20 Is there a reason why the ICCP draft does not explicit reference the pw redundancy draft? It does mention active/standby signaling for the PWs, so implicitly it seems to assume that the other endpoint is implementing draft-pw-redundancy-bit, but in that case some details are missing such as which pw redundancy mode should be used (e.g. master/slave), how PW precedence should be configured, etc. =20 Is this something you plan to add in future revisions? =20 Thanks, =20 Daniel =20 ------_=_NextPart_001_01CD02A8.E3D05F1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi draft-ietf-pwe3-iccp authors and list at = large,

 

Is there a reason why the = ICCP draft does not explicit reference the pw redundancy draft? It does = mention active/standby signaling for the PWs, so implicitly it seems to = assume that the other endpoint is implementing draft-pw-redundancy-bit, = but in that case some details are missing such as which pw redundancy = mode should be used (e.g. master/slave), how PW precedence should be = configured, etc.

 

Is this something you plan = to add in future revisions?

 

Thanks,

 

Daniel

 

------_=_NextPart_001_01CD02A8.E3D05F1F-- From ssalam@cisco.com Thu Mar 15 10:25:59 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F3A21F87BD for ; Thu, 15 Mar 2012 10:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=1.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYOczHDpq7BL for ; Thu, 15 Mar 2012 10:25:58 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B957921F87B3 for ; Thu, 15 Mar 2012 10:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssalam@cisco.com; l=4334; q=dns/txt; s=iport; t=1331832358; x=1333041958; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=bS1pN5ORS328EnmxwkFEaCERO28LgnBAT/1ZoOPNCW8=; b=JrOcIanTE+t9gAxGm3OEsu53EnET8nczX+0681fvTQy0G6GTOzUC975q Mop56GWcVz/AgsNDAZ1gpKrmX07WtRGGH0ezNq/li7wzVVrXb25/Cy6vb I/V/PydIeMkoC7vSrjKxBJoOjIGPhi+r7pmH3+XIwS4XxDv98S4Zx16db I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0JAIMlYk+rRDoJ/2dsb2JhbABDgk6yb3MCgQeCCQEBAQMBAQEBDwEqMRANAQgEaTABAQQBEiKHYwQBC51Ily0EkQcEiFeNCo4/J4FBgwc X-IronPort-AV: E=Sophos;i="4.73,592,1325462400"; d="scan'208,217";a="36290107" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 15 Mar 2012 17:25:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2FHPwPQ020471; Thu, 15 Mar 2012 17:25:58 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 10:25:58 -0700 Received: from 161.44.207.8 ([161.44.207.8]) by xmb-sjc-233.amer.cisco.com ([128.107.191.88]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Mar 2012 17:25:57 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Thu, 15 Mar 2012 10:25:56 -0800 From: Samer Salam To: Daniel Cohn , Message-ID: Thread-Topic: [PWE3] draft-ietf-pwe3-iccp interaction with draft-pw-redundancy-bit Thread-Index: Ac0CqH/qtyJRd8+JRXuyEnS5aYeGKQAKC4h9 In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307670E33@tlvmail1> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414651956_183187746" X-OriginalArrivalTime: 15 Mar 2012 17:25:58.0447 (UTC) FILETIME=[AF800BF0:01CD02D0] Subject: Re: [PWE3] draft-ietf-pwe3-iccp interaction with draft-pw-redundancy-bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 17:25:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414651956_183187746 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Daniel, The ICCP draft does assume the use of the pw-redundancy-bit draft. Section 9.1.3 describes two modes of operation (depending on configuration): - When an external AC redundancy mechanism is in use, and is being synchronized among the PEs via ICCP. In this mode, PW state is not synchronized via ICCP and the Independent Mode of operation is used for PW state signaling. This guarantees that the AC and PW states are always in sync for a given PE (to avoid deadlock). - When an external AC redundancy mechanism is not in use, then PW state is synchronized via ICCP. In this mode, either the Independent mode or the Master/Slave mode could be used for PW state signaling. We will add clarifications to that effect in a future revision. Regards, Samer On 12-03-15 4:38 AM, "Daniel Cohn" wrote: > Hi draft-ietf-pwe3-iccp authors and list at large, > > Is there a reason why the ICCP draft does not explicit reference the pw > redundancy draft? It does mention active/standby signaling for the PWs, so > implicitly it seems to assume that the other endpoint is implementing > draft-pw-redundancy-bit, but in that case some details are missing such as > which pw redundancy mode should be used (e.g. master/slave), how PW precedence > should be configured, etc. > > Is this something you plan to add in future revisions? > > Thanks, > > Daniel > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --B_3414651956_183187746 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [PWE3] draft-ietf-pwe3-iccp interaction with draft-pw-redundancy= -bit Hi Daniel,

The ICCP draft does assume the use of the pw-redundancy-bit draft. Section = 9.1.3 describes two modes of operation (depending on configuration):

- When an external AC redundancy mechanism is in use, and is being synchron= ized among the PEs via ICCP. In this mode, PW state is not synchronized via = ICCP and the Independent Mode of operation is used for PW state signaling. T= his guarantees that the AC and PW states are always in sync for a given PE (= to avoid deadlock).

- When an external AC redundancy mechanism is not in use, then PW state is = synchronized via ICCP. In this mode, either the Independent mode or the Mast= er/Slave mode could be used for PW state signaling.

We will add clarifications to that effect in a future revision.

Regards,
Samer


On 12-03-15 4:38 AM, "Daniel Cohn" <DanielC@orckit.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi draft-ietf-pwe3-iccp authors and list at larg= e,
 
Is there a reason why the ICCP draft does not explicit reference the pw red= undancy draft? It does mention active/standby signaling for the PWs, so impl= icitly it seems to assume that the other endpoint is implementing draft-pw-r= edundancy-bit, but in that case some details are missing such as which pw re= dundancy mode should be used (e.g. master/slave), how PW precedence should b= e configured, etc.
 
Is this something you plan to add in future revisions?
 
Thanks,
 
Daniel
 

__________________________= _____________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3
--B_3414651956_183187746-- From tnadeau@lucidvision.com Thu Mar 15 10:28:17 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B1A21F87D6 for ; Thu, 15 Mar 2012 10:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W5BdaHwJ36b for ; Thu, 15 Mar 2012 10:28:17 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B77E321F87C9 for ; Thu, 15 Mar 2012 10:28:16 -0700 (PDT) Received: from [10.100.69.52] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id C72071908BD; Thu, 15 Mar 2012 13:28:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_AAC0DDE3-1F94-4B58-86AF-8DB9BB3D6316" From: Thomas Nadeau In-Reply-To: Date: Thu, 15 Mar 2012 13:28:15 -0400 Message-Id: References: To: Samer Salam X-Mailer: Apple Mail (2.1257) Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-iccp interaction with draft-pw-redundancy-bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 17:28:17 -0000 --Apple-Mail=_AAC0DDE3-1F94-4B58-86AF-8DB9BB3D6316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We should probably also add a reference to the redundancy bit = draft as well. --Tom On Mar 15, 2012, at 2:25 PM, Samer Salam wrote: > Hi Daniel, >=20 > The ICCP draft does assume the use of the pw-redundancy-bit draft. = Section 9.1.3 describes two modes of operation (depending on = configuration): >=20 > - When an external AC redundancy mechanism is in use, and is being = synchronized among the PEs via ICCP. In this mode, PW state is not = synchronized via ICCP and the Independent Mode of operation is used for = PW state signaling. This guarantees that the AC and PW states are always = in sync for a given PE (to avoid deadlock). >=20 > - When an external AC redundancy mechanism is not in use, then PW = state is synchronized via ICCP. In this mode, either the Independent = mode or the Master/Slave mode could be used for PW state signaling. >=20 > We will add clarifications to that effect in a future revision. >=20 > Regards, > Samer >=20 >=20 > On 12-03-15 4:38 AM, "Daniel Cohn" wrote: >=20 >> Hi draft-ietf-pwe3-iccp authors and list at large, >> =20 >> Is there a reason why the ICCP draft does not explicit reference the = pw redundancy draft? It does mention active/standby signaling for the = PWs, so implicitly it seems to assume that the other endpoint is = implementing draft-pw-redundancy-bit, but in that case some details are = missing such as which pw redundancy mode should be used (e.g. = master/slave), how PW precedence should be configured, etc. >> =20 >> Is this something you plan to add in future revisions? >> =20 >> Thanks, >> =20 >> Daniel >> =20 >>=20 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_AAC0DDE3-1F94-4B58-86AF-8DB9BB3D6316 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

We should probably also add a reference to the redundancy bit draft as well.

--Tom


On Mar 15, 2012, at 2:25 PM, Samer Salam wrote:

Re: [PWE3] draft-ietf-pwe3-iccp interaction with draft-pw-redundancy-bit
Hi Daniel,

The ICCP draft does assume the use of the pw-redundancy-bit draft. Section 9.1.3 describes two modes of operation (depending on configuration):

- When an external AC redundancy mechanism is in use, and is being synchronized among the PEs via ICCP. In this mode, PW state is not synchronized via ICCP and the Independent Mode of operation is used for PW state signaling. This guarantees that the AC and PW states are always in sync for a given PE (to avoid deadlock).

- When an external AC redundancy mechanism is not in use, then PW state is synchronized via ICCP. In this mode, either the Independent mode or the Master/Slave mode could be used for PW state signaling.

We will add clarifications to that effect in a future revision.

Regards,
Samer


On 12-03-15 4:38 AM, "Daniel Cohn" <DanielC@orckit.com> wrote:

Hi draft-ietf-pwe3-iccp authors and list at large,
 
Is there a reason why the ICCP draft does not explicit reference the pw redundancy draft? It does mention active/standby signaling for the PWs, so implicitly it seems to assume that the other endpoint is implementing draft-pw-redundancy-bit, but in that case some details are missing such as which pw redundancy mode should be used (e.g. master/slave), how PW precedence should be configured, etc.
 
Is this something you plan to add in future revisions?
 
Thanks,
 
Daniel
 

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

--Apple-Mail=_AAC0DDE3-1F94-4B58-86AF-8DB9BB3D6316-- From davari@broadcom.com Thu Mar 15 11:45:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6621F8692; Thu, 15 Mar 2012 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU+ul-bKnHzU; Thu, 15 Mar 2012 11:45:06 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE5821F8622; Thu, 15 Mar 2012 11:45:06 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 15 Mar 2012 11:54:43 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 15 Mar 2012 11:44:55 -0700 From: "Shahram Davari" To: "Greg Mirsky" Date: Thu, 15 Mar 2012 11:44:52 -0700 Thread-Topic: [PWE3] Updated 1588 over MPLS draf-03 Thread-Index: Ac0CUHHbsZe5OTtyTdCk7/roMMK5gQAizr7w Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EE@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 637CE5794GW5121498-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_ Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:45:07 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes, agree. Thx Shahram From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Wednesday, March 14, 2012 7:08 PM To: Shahram Davari Cc: tictoc@ietf.org; mpls@ietf.org; pwe3@ietf.org; CCAMP Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 Dear Shahram, perhaps because of "This document provides extensions to OSPF, ISIS ..." re= view by OSPF and ISIS WGs should be solicited as well. Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari > wrote: Hi, Please find attached the latest 1588 over MPLS draft (03). Since cut-off da= te was yesterday, we will upload this after the Paris meeting. Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspect= s from each of these groups are used in this draft. We will present this draft in the relevant WGs in Paris. Regards, Shahram Davari _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Yes, agre= e.

 

Thx

Shahram

&n= bsp;

From: Greg Mirsky [mailt= o:gregimirsky@gmail.com]
Sent: Wednesday, March 14, 2012 7:08 PM=
To: Shahram Davari
Cc: tictoc@ietf.org; mpls@ietf.org;= pwe3@ietf.org; CCAMP
Subject: Re: [PWE3] Updated 1588 over MPLS = draf-03

 

Dear Shahram,
perh= aps because of "This document provides extensions to OSPF, ISIS ...&qu= ot; review by OSPF and ISIS WGs should be solicited as well.

Regards= ,
Greg

On Mon, Mar 12, 2012 at 5= :16 PM, Shahram Davari <davari@br= oadcom.com> wrote:

Hi,

=

 

Please find attached the latest 1588 ove= r MPLS draft (03). Since cut-off date was yesterday, we will upload this af= ter the Paris meeting.

Review is required from TICTOC,= MPLS, PWE3 and CCAMP WGs, since some aspects from each of these groups are= used in this draft.

 

We w= ill present this draft in the relevant WGs in Paris.

&= nbsp;

Regards,

Shahram Davari

=
_______________________________________________
pwe3 mailing listpwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3

&nbs= p;

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_-- From lizho.jin@gmail.com Fri Mar 16 08:03:19 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E784921F8735; Fri, 16 Mar 2012 08:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KygDOVTkmqdv; Fri, 16 Mar 2012 08:03:19 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2B21F86B2; Fri, 16 Mar 2012 08:03:18 -0700 (PDT) Received: by yenm5 with SMTP id m5so4870458yen.31 for ; Fri, 16 Mar 2012 08:03:18 -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=jemDan+3Uv2Bda6S1rHfrTbc/5+AZsWfeO/icFUAgvw=; b=nD5KP3KlyYRr+MuPbvj16sJHUeZgmPaBDYkDE0JC7OSvlyLaTRFxDe9FTLpTb0aZOT fsgSN1JyCjVvUx2bnKV8Hwo/J/RNIs7SOzYgDHcYl6Zkr/qoaPvgBBMP0E+UNlJPBmk4 VAFXi1qHPSddi1K7k54NJKJkOOGjArRv6lYwIb3YGbhVsYzsCEkw7CSaSNlIb8W2bHIs S6krDNlK1xKPMT4+lrrLe0/TRFoy3iXg84/P14nAY1hS27PBGefQvDyXGnA1XPaauPoL urKd0efRnEK7tpFdjNIh2H41VGDFIwtdPRSHmEeIkeXit7M3LlaIArpVHxq5ZDVSg9KK OdJQ== MIME-Version: 1.0 Received: by 10.60.7.7 with SMTP id f7mr3419371oea.19.1331910198325; Fri, 16 Mar 2012 08:03:18 -0700 (PDT) Received: by 10.60.39.129 with HTTP; Fri, 16 Mar 2012 08:03:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Mar 2012 23:03:17 +0800 Message-ID: From: Lizhong Jin To: ssalam@cisco.com Content-Type: multipart/alternative; boundary=e89a8fb1f2fc3e719304bb5d8262 Cc: l2vpn@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] pwe3 Digest, Vol 95, Issue 11 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:03:20 -0000 --e89a8fb1f2fc3e719304bb5d8262 Content-Type: text/plain; charset=ISO-8859-1 > > > The ICCP draft does assume the use of the pw-redundancy-bit draft. Section > 9.1.3 describes two modes of operation (depending on configuration): > > - When an external AC redundancy mechanism is in use, and is being > synchronized among the PEs via ICCP. In this mode, PW state is not > synchronized via ICCP and the Independent Mode of operation is used for PW > state signaling. This guarantees that the AC and PW states are always in > sync for a given PE (to avoid deadlock). > > - When an external AC redundancy mechanism is not in use, then PW state is > synchronized via ICCP. In this mode, either the Independent mode or the > Master/Slave mode could be used for PW state signaling. > [Lizhong] and if independent mode is applied, the the operator MUST be care to configure same high/low PW priority at two end-points of active/standby PW, otherwise, will result two standby PW. More details are in draft-liu-l2vpn-vpls-inter-domain-redundancy-02 section 5. Regards Lizhong We will add clarifications to that effect in a future revision. Regards, Samer On 12-03-15 4:38 AM, "Daniel Cohn" wrote: > Hi draft-ietf-pwe3-iccp authors and list at large, > > Is there a reason why the ICCP draft does not explicit reference the pw > redundancy draft? It does mention active/standby signaling for the PWs, so > implicitly it seems to assume that the other endpoint is implementing > draft-pw-redundancy-bit, but in that case some details are missing such as > which pw redundancy mode should be used (e.g. master/slave), how PW precedence > should be configured, etc. > > Is this something you plan to add in future revisions? > > Thanks, > > Daniel > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://www.ietf.org/mail-archive/web/pwe3/attachments/20120315/91462e58/attachment.htm > ------------------------------ --e89a8fb1f2fc3e719304bb5d8262 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The ICCP draft does assume the us= e of the pw-redundancy-bit draft. Section
9.1.3 describes two modes of o= peration (depending on configuration):

- When an external AC redundancy mechanism is in use, and is being
s= ynchronized among the PEs via ICCP. In this mode, PW state is not
synchr= onized via ICCP and the Independent Mode of operation is used for PW
state signaling. This guarantees that the AC and PW states are always insync for a given PE (to avoid deadlock).

- When an external AC redu= ndancy mechanism is not in use, then PW state is
synchronized via ICCP. = In this mode, either the Independent mode or the
Master/Slave mode could be used for PW state signaling.
[Lizhong] and if independent mode is applied, the the operator MUST be= care to=A0 configure same high/low PW priority at two end-points of active= /standby PW, otherwise, will result=A0two standby PW. More details are=A0in= draft-liu-l2vpn-vpls-inter-domain-redundancy-02 section 5.
=A0
Regards
Lizhong
=A0
=A0

We will add clarifications to that effect in a future revision.
Regards,
Samer


On 12-03-15 4:38 AM, "Daniel Cohn&qu= ot; <DanielC@orckit.com> wr= ote:

> Hi draft-ietf-pwe3-iccp authors and list at large,
>
>= Is there a reason why the ICCP draft does not explicit reference the pw> redundancy draft? It does mention active/standby signaling for the PW= s, so
> implicitly it seems to assume that the other endpoint is implementing<= br>> draft-pw-redundancy-bit, but in that case some details are missing = such as
> which pw redundancy mode should be used (e.g. master/slave)= , how PW precedence
> should be configured, etc.
>
> Is this something you plan = to add in future revisions?
>
> Thanks,
>
> Daniel<= br>>
>
>
> ___________________________________________= ____
> pwe3 mailing list
> pwe3@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/pwe3

--------= ------ next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/pwe3/attachments/2012031= 5/91462e58/attachment.htm>

------------------------------
--e89a8fb1f2fc3e719304bb5d8262-- From lizho.jin@gmail.com Fri Mar 16 08:05:14 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCBC21F879E; Fri, 16 Mar 2012 08:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyLvASEF5emj; Fri, 16 Mar 2012 08:05:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30F5621F8623; Fri, 16 Mar 2012 08:05:13 -0700 (PDT) Received: by yenm5 with SMTP id m5so4872915yen.31 for ; Fri, 16 Mar 2012 08:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dSdRdW94PGpQ5ZHjbPfbz3mYLMPSYdk+JtYQTXLdL0I=; b=rjdIAG4TfJv1uDxCo97maHvDnkq1Q39pfk4GnjEvmoTnOcgRlOuyBKjcJA+cFubvoQ Fnpi12fYOoV+cIgi2GRyJ3y6pBMbbTDDi/fy5E+mjenlPFg77k/x7uNcBUJNlwiA8P// x/1ijIbJJYlLUGoZNxCzzad8KmE9oYPIiGwGb9ufx3T+4XurzVmZh1WeZZwO2eEhbauR 3x6UnD6eOsudCVESdtSA/WAlnFUXcPFVKdyOsvS0NZ5EH5Er3LGgif50nwd5/N8R9GD8 zHsQMJ2dOMH8F+sK239PxI79sBaRblwxLQlnp1YzpNAH0X2XHDvcQVbfXohtwOpRLnsP Yn6A== MIME-Version: 1.0 Received: by 10.182.147.35 with SMTP id th3mr3435563obb.29.1331910312723; Fri, 16 Mar 2012 08:05:12 -0700 (PDT) Received: by 10.60.39.129 with HTTP; Fri, 16 Mar 2012 08:05:12 -0700 (PDT) Date: Fri, 16 Mar 2012 23:05:12 +0800 Message-ID: From: Lizhong Jin To: ssalam@cisco.com Content-Type: multipart/alternative; boundary=f46d0444005410068e04bb5d89ee Cc: l2vpn@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-iccp interaction with draft-pw-redundancy-bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:05:14 -0000 --f46d0444005410068e04bb5d89ee Content-Type: text/plain; charset=ISO-8859-1 Sorry, send again with correct mail subject. Lizhong 2012/3/16 Lizhong Jin > >> The ICCP draft does assume the use of the pw-redundancy-bit draft. Section >> 9.1.3 describes two modes of operation (depending on configuration): >> >> - When an external AC redundancy mechanism is in use, and is being >> synchronized among the PEs via ICCP. In this mode, PW state is not >> synchronized via ICCP and the Independent Mode of operation is used for PW >> state signaling. This guarantees that the AC and PW states are always in >> sync for a given PE (to avoid deadlock). >> >> - When an external AC redundancy mechanism is not in use, then PW state is >> synchronized via ICCP. In this mode, either the Independent mode or the >> Master/Slave mode could be used for PW state signaling. >> > [Lizhong] and if independent mode is applied, the the operator MUST be > care to configure same high/low PW priority at two end-points of > active/standby PW, otherwise, will result two standby PW. More details > are in draft-liu-l2vpn-vpls-inter-domain-redundancy-02 section 5. > > Regards > Lizhong > > > > We will add clarifications to that effect in a future revision. > > Regards, > Samer > > > On 12-03-15 4:38 AM, "Daniel Cohn" wrote: > > > Hi draft-ietf-pwe3-iccp authors and list at large, > > > > Is there a reason why the ICCP draft does not explicit reference the pw > > redundancy draft? It does mention active/standby signaling for the PWs, > so > > implicitly it seems to assume that the other endpoint is implementing > > draft-pw-redundancy-bit, but in that case some details are missing such > as > > which pw redundancy mode should be used (e.g. master/slave), how PW > precedence > > should be configured, etc. > > > > Is this something you plan to add in future revisions? > > > > Thanks, > > > > Daniel > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/pwe3/attachments/20120315/91462e58/attachment.htm > > > > ------------------------------ > --f46d0444005410068e04bb5d89ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry, send again with correct mail subject.
=A0
Lizhong

2012/3/16 Lizhong Jin <lizho.jin@gmail.com>

The ICCP draft does assume the us= e of the pw-redundancy-bit draft. Section
9.1.3 describes two modes of o= peration (depending on configuration):

- When an external AC redundancy mechanism is in use, and is being
s= ynchronized among the PEs via ICCP. In this mode, PW state is not
synchr= onized via ICCP and the Independent Mode of operation is used for PW
state signaling. This guarantees that the AC and PW states are always insync for a given PE (to avoid deadlock).

- When an external AC redu= ndancy mechanism is not in use, then PW state is
synchronized via ICCP. = In this mode, either the Independent mode or the
Master/Slave mode could be used for PW state signaling.
[Lizhong] and if independent mode is applied, the the operator MUST be= care to=A0 configure same high/low PW priority at two end-points of active= /standby PW, otherwise, will result=A0two standby PW. More details are=A0in= draft-liu-l2vpn-vpls-inter-domain-redundancy-02 section 5.
=A0
Regards
Lizhong
=A0
=A0

We will add clarifications to that effect in a future revision.
Regards,
Samer


On 12-03-15 4:38 AM, "Daniel Cohn&qu= ot; <DanielC@orc= kit.com> wrote:

> Hi draft-ietf-pwe3-iccp authors and list at large,
>
>= Is there a reason why the ICCP draft does not explicit reference the pw> redundancy draft? It does mention active/standby signaling for the PW= s, so
> implicitly it seems to assume that the other endpoint is implementing<= br>> draft-pw-redundancy-bit, but in that case some details are missing = such as
> which pw redundancy mode should be used (e.g. master/slave)= , how PW precedence
> should be configured, etc.
>
> Is this something you plan = to add in future revisions?
>
> Thanks,
>
> Daniel<= br>>
>
>
> ___________________________________________= ____
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3

-------------- next part --------------
An HTML attachment was scrub= bed...
URL: <http://www.iet= f.org/mail-archive/web/pwe3/attachments/20120315/91462e58/attachment.htm>

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

--f46d0444005410068e04bb5d89ee-- From david.sinicrope@ericsson.com Tue Mar 20 08:30:04 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA29221F854D for ; Tue, 20 Mar 2012 08:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7DWYaGNwjUU for ; Tue, 20 Mar 2012 08:30:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 23E8421F84FB for ; Tue, 20 Mar 2012 08:30:04 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2KFU2uq014210 for ; Tue, 20 Mar 2012 10:30:03 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.46]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 20 Mar 2012 11:29:31 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Tue, 20 Mar 2012 11:29:28 -0400 Thread-Topic: [PWE3] PWE3 IETF 83 Slot Requests Thread-Index: Ac0Grj6vHzrl0CxxTlC1BLE7xH/WlA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 IETF 83 Slot Requests X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:30:05 -0000 Hi All, Sorry for the delay. The agenda for next week's meeting is posted. (http://www.ietf.org/proceedings/83/agenda/agenda-83-pwe3.txt) Running order is subject to change at the discretion of the Chairs. Presenters, please reply to this email and send me your slides for upload. All slides must be received prior to 5pm Paris time, Wednesday, March 28 or you risk losing your slot. Thanks, Dave -----Original Message----- From: David A Sinicrope Date: Mon, 5 Mar 2012 19:29:06 -0500 To: "IETF.PWE3" Cc: David A Sinicrope Subject: Re: [PWE3] PWE3 IETF 83 Slot Requests >Hi All, >I've started to put together the Paris PWE3 agenda based on the requests >I've received to date. >Please check out:=20 >http://www.ietf.org/proceedings/83/agenda/agenda-83-pwe3.txt (running >order is subject to change) >If you have requested a slot, please make sure I've reflected it >accurately.=20 >If you need a slot and haven't yet requested one, please refer to the >email below. >If you have questions, please send them to the list. > >Thanks, >Dave=20 > > >-----Original Message----- >From: David A Sinicrope >Date: Fri, 24 Feb 2012 03:11:36 -0500 >To: "IETF.PWE3" >Subject: [PWE3] PWE3 IETF 83 Slot Requests > >>Hi All, >>If you need a presentation slot for the IETF 83 PWE3 session, please >>reply to this email (subject intact) with: >>-topic >>-draft name >>-requested duration >>-speaker >> >>Thanks, >>Dave >> >> >>On Feb 23, 2012, at 3:45 PM, "Malis, Andrew G (Andy)" >>> wrote: >> >> >> >>Cheers, >>Andy >>Sent from my Verizon DROID 3 >> >> >>-----Original Message----- >>From: "IETF Secretariat" [agenda@ietf.org] >>Sent: Thursday, February 23, 2012 03:43 PM Eastern Standard Time >>To:=20 >>matthew.bocci@alcatel-lucent.com >>Cc: pwe3-ads@tools.ietf.org; >>pwe3-chairs@tools.ietf.org; >>wlo@amsl.com >>Subject: pwe3 - Requested session has been scheduled for IETF 83 >> >> >>Dear Matthew Bocci, >> >>The sessions that you have requested have been scheduled. >>Below is the scheduled session information followed by >>the original request. >> >>pwe3 Session 1 (2.5 hours) >> Thursday, Morning Session I 0930-1130 >> Room Name: 242AB >> --------------------------------------------- >> >> >> >>Request Information: >> >>--------------------------------------------------------- >>Working Group Name: Pseudowire Emulation Edge to Edge >>Area Name: Routing Area >>Session Requester: Wanda Lo >> >>Number of Sessions: 1 >>Length of Session(s): 2.5 hours >>Number of Attendees: 120 >>Conflicts to Avoid: >> First Priority: ccamp l2vpn l3vpn mpls tictoc ancp rtgarea rtgwg >> Second Priority: intarea >> >> >> >> >>Special Requests: >> >>--------------------------------------------------------- >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www.ietf.org/mailman/listinfo/pwe3 > From gregimirsky@gmail.com Wed Mar 21 16:03:24 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A2621E800C; Wed, 21 Mar 2012 16:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkoYmn6v6sTM; Wed, 21 Mar 2012 16:03:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB02521E8026; Wed, 21 Mar 2012 16:03:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1568498ghb.31 for ; Wed, 21 Mar 2012 16:03:23 -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=m3HW88J8pssPkslubGJrpqRR/bREWK0Xe7ijmn43/qo=; b=KUU+bT+NBuUqVt2LpHAs2w1WL3la10spatwDuF7yN/ZPz+2tz7zAQmYOLV2IvB9ElM uCPAx6gjC0xj1bnvih4q0OpPIP3AYo7ON8uW49F16sMeEMm4zzmBKdl6wzIark5rcyIB BfcpuB8IhdJjqTEDq7c5I394L/5vpX0PFlUeJXCA+X69gne9DuuZbHEACh6g5iaLbI6u 38QgV1G+oACW9FPYfDxE55TkHRc6wQhLLSv9TeffpeUCYXFTO9W4LoDGCa14Om11z5JA 7Nu797MxZ5CTGwVrsixCAaCSkP15EhwYTIiY9vKtfQfYW+Cq9l/UCubTlTgx53AO7nOx A5hw== MIME-Version: 1.0 Received: by 10.182.86.200 with SMTP id r8mr7149519obz.20.1332371003453; Wed, 21 Mar 2012 16:03:23 -0700 (PDT) Received: by 10.182.114.98 with HTTP; Wed, 21 Mar 2012 16:03:23 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 21 Mar 2012 16:03:23 -0700 Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=f46d0444e9a35eb1ec04bbc8cc8f Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:03:24 -0000 --f46d0444e9a35eb1ec04bbc8cc8f Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, noticed that both TICTOC and MPLS agendas refer to -02 version of the document. Would you be presenting -02 or -03? Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari wrote: > Hi,**** > > ** ** > > Please find attached the latest 1588 over MPLS draft (03). Since cut-off > date was yesterday, we will upload this after the Paris meeting.**** > > Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some > aspects from each of these groups are used in this draft. **** > > ** ** > > We will present this draft in the relevant WGs in Paris.**** > > ** ** > > Regards,**** > > Shahram Davari**** > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --f46d0444e9a35eb1ec04bbc8cc8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shahram,
noticed that both TICTOC and MPLS agendas refer to -02 versi= on of the document. Would you be presenting -02 or -03?

Regards,
= Greg

On Mon, Mar 12, 2012 at 5:16 PM, Sha= hram Davari <da= vari@broadcom.com> wrote:

Hi,

=A0

Please find attached the latest 1588 over MPLS draft= (03). Since cut-off date was yesterday, we will upload this after the Pari= s meeting.

Review is required from = TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from each of these gro= ups are used in this draft.

=A0

We will = present this draft in the relevant WGs in Paris.

=A0

Regards,<= u>

Shahram Davari


____= ___________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


--f46d0444e9a35eb1ec04bbc8cc8f-- From davari@broadcom.com Wed Mar 21 16:52:29 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAAB21F859F; Wed, 21 Mar 2012 16:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLty1QzlZIAw; Wed, 21 Mar 2012 16:52:29 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4663D21F859A; Wed, 21 Mar 2012 16:52:29 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 21 Mar 2012 17:02:13 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 21 Mar 2012 16:52:17 -0700 From: "Shahram Davari" To: "Greg Mirsky" Date: Wed, 21 Mar 2012 16:52:13 -0700 Thread-Topic: [PWE3] Updated 1588 over MPLS draf-03 Thread-Index: Ac0Httfx7urInSjNTNy4dIZ1z14e0AABqypQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6374B38F4GW7718409-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_ Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:52:30 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I will present ver-02, since ver-03 was not completed in time. But we like = to hear all feddbacks. Thanks Shahram From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Wednesday, March 21, 2012 4:03 PM To: Shahram Davari Cc: tictoc@ietf.org; mpls@ietf.org; pwe3@ietf.org; CCAMP Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 Hi Shahram, noticed that both TICTOC and MPLS agendas refer to -02 version of the docum= ent. Would you be presenting -02 or -03? Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari > wrote: Hi, Please find attached the latest 1588 over MPLS draft (03). Since cut-off da= te was yesterday, we will upload this after the Paris meeting. Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspect= s from each of these groups are used in this draft. We will present this draft in the relevant WGs in Paris. Regards, Shahram Davari _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

I will present ver-02, since ver-03 was not comple= ted in time. But we like to hear all feddbacks.

 

Thanks

Shahram

 

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
= Sent: Wednesday, March 21, 2012 4:03 PM
To: Shahram Davari=
Cc: tictoc@ietf.org; mpls@ietf.org; pwe3@ietf.org; CCAMP
S= ubject: Re: [PWE3] Updated 1588 over MPLS draf-03

=

 

Hi Shahram,
noticed that both TICTOC and MPLS = agendas refer to -02 version of the document. Would you be presenting -02 o= r -03?

Regards,
Greg

On M= on, Mar 12, 2012 at 5:16 PM, Shahram Davari <davari@broadcom.com> wrote:

Hi,

 

Please find attache= d the latest 1588 over MPLS draft (03). Since cut-off date was yesterday, w= e will upload this after the Paris meeting.

Review is = required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from eac= h of these groups are used in this draft.

 =

We will present this draft in the relevant WGs in Paris.

 

Regards,

Shahram Davari


_______________________________________________pwe3 mailing list
pwe3@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/pwe3

 

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_-- From mustapha.aissaoui@alcatel-lucent.com Thu Mar 22 08:59:47 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1171921F85CC; Thu, 22 Mar 2012 08:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.239 X-Spam-Level: X-Spam-Status: No, score=-9.239 tagged_above=-999 required=5 tests=[AWL=1.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ2A6y3+ul4N; Thu, 22 Mar 2012 08:59:45 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6939A21F85A8; Thu, 22 Mar 2012 08:59:45 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2MFxg9j006229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 10:59:42 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2MFxdYt009698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Mar 2012 10:59:39 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 22 Mar 2012 10:59:26 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "'pwe3@ietf.org'" , Daniel Cohn Date: Thu, 22 Mar 2012 10:59:24 -0500 Thread-Topic: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Thread-Index: Acz8izeZXI9/dkIbSZqtuo9E9fuJLwAADwawAsQxoaA= Message-ID: <5DF53972F7E9134782DCE51624466FE50AD59605CD@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DF53972F7E9134782DCE51624466FE50AD59605CDUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "'draft-ietf-pwe3-redundancy-bit@tools.ietf.org'" , "'ietf@ietf.org'" , "'stbryant@cisco.com'" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:59:47 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD59605CDUSNAVSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I received comments from Daniel regarding the intended use of the optional = active PW selection mechanism in section 5.1. I pasted below the correspond= ing paragraph of Section 5.1 with the changes we agreed to underlined. He also asked if the default active PW selection mechanism should be refere= nced in Section 5.2 with the Master/Slave mode of operation. Although, it i= s not stricly required for interoperability, implementations would benefit = from a consistent behaviour. I used SHOULD in that case. The text is also p= asted below with the changes underlined. Let me know if you have any comments on this. Regards, Mustapha. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I. Changes to Section 5.1 - 3rd paragraph: " If more than one PW qualifies for the Active state, each PW endpoint MUST i= mplement a common mechanism to choose the PW for forwarding. The default me= chanism MUST be supported by all implementations and operates as follows: 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each PW in a redundant set is uniquely identified at = each PE using the following triplet: AGI::SAII::TAII. The unsigned integer = form of the concatenated word can be used in the comparison. However, the S= AII and TAII values as seen on a PE node are the mirror values of what the = peer PE node sees. To have both PE nodes compare the same value we propose = that the PE with the lowest system IP address use the unsigned integer form= of AGI::SAII::TAII while the PE with the highest system IP address use the= unsigned integer form of AGI::TAII::SAII. This way, both PEs will compare = the same values. The PW which corresponds to the minimum of the compared va= lues across all PWs in the redundant is selected. Note 1: in the case where the system IP address is not known, it is recomme= nded to implement the optional active PW selection mechanism described next= . Note 2: in the case of segmented PW, the operator needs to make sure that t= he pw-id or AGI::SAII::TAII of the redundant PWs within the first and last = segment are ordered consistently such that the same end-to-end MS-PW gets s= elected. Otherwise, it is recommended to implement the optional active PW s= election mechanism described next. The PW endpoints MAY also implement the following optional active PW select= ion mechanism. 1. If the PW endpoint is configured with the precedence parameter on ea= ch PW in the redundant set, it must select the PW with the lowest configure= d precedence value. 2. If the PW endpoint is configured with one PW as primary and one or m= ore PWs as secondary, it must select the primary PW in preference to all se= condary PWs. If a primary PW is not available, it must use the secondary PW= with the lowest precedence value. If the primary PW becomes available, a P= W endpoint must revert to it immediately or after the expiration of a confi= gurable delay. 3. This active PW selection mechanism assumes the precedence parameter = values are configured consistently at both PW endpoints and that unique val= ues are assigned to the PWs in the same redundancy set to achieve tie-break= ing using this mechanism. " II. Changes to Section 5.2 - 5th paragraph: " If more than one PW qualify for the Active state, the Master PW endpoint no= de selects one. There is no requirement to specify a default active PW sele= ction mechanism in this case but for consistency across implementations, th= e Master PW endpoint SHOULD implement the default active PW selection mecha= nism described in Section 5.1. If the Master PW endpoint implements the optional active PW selection mecha= nism based on primay/secondary and precedence parameters, it MUST follow th= e following behaviour: 1. If the PW endpoint is configured with the precedence parameter on ea= ch PW in the redundant set, it must select the PW with the lowest configure= d precedence value. 2. If the PW endpoint is configured with one PW as primary and one or m= ore PWs as secondary, it must select the primary PW in preference to all se= condary PWs. If a primary PW is not available, it must use the secondary PW= with the lowest precedence value. If the primary PW becomes available, a P= W endpoint must revert to it immediately or after the expiration of a confi= gurable delay. " =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________ From: Aissaoui, Mustapha (Mustapha) Sent: Wednesday, March 07, 2012 12:56 PM To: Andrew G. Malis Cc: stbryant@cisco.com; draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3= @ietf.org; ietf@ietf.org Subject: RE: [PWE3] Last Call: (Pse= udowire Preferential Forwarding Status Bit) to Proposed Standard makes sense Andy. Thanks, Mustapha. ________________________________ From: Andrew G. Malis [mailto:amalis@gmail.com] Sent: Wednesday, March 07, 2012 12:53 PM To: Aissaoui, Mustapha (Mustapha) Cc: stbryant@cisco.com; draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3= @ietf.org; ietf@ietf.org Subject: Re: [PWE3] Last Call: (Pse= udowire Preferential Forwarding Status Bit) to Proposed Standard Mustapha, You might want to wait for any other LC comments before updating. Thanks, Andy On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha) > wrot= e: Ooops. Thank you for pointing this out Stewart. I will make the update and = publish a new revision. Mustapha. -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org Cc: ietf@ietf.org; pwe3@ietf.org Subject: Re: Last Call: (Pseudowire= Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD revie= w and so I am picking it up as a LC comment: In section 10 you say: "This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: " This update should be recorded in the metadata (top left front page) and it= is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: > The IESG has received a request from the Pseudowire Emulation Edge to > Edge WG (pwe3) to consider the following document: > - 'Pseudowire Preferential Forwarding Status Bit' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-03-21. Exceptio= nally, comments may > be sent to iesg@ietf.org instead. In either case, p= lease retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes a mechanism for standby status signaling of > redundant pseudowires (PWs) between their termination points. A set > of redundant PWs is configured between provider edge (PE) nodes in > single-segment pseudowire (SS-PW) applications, or between > terminating provider edge (T-PE) nodes in multi-segment pseudowire > (MS-PW) applications. > > In order for the PE/T-PE nodes to indicate the preferred PW to use > for forwarding PW packets to one another, a new status bit is needed > to indicate a preferential forwarding status of Active or Standby for > each PW in a redundant set. > > In addition, a second status bit is defined to allow peer PE nodes to > coordinate a switchover operation of the PW. > > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_5DF53972F7E9134782DCE51624466FE50AD59605CDUSNAVSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
I=20 received comments from Daniel regarding the intended use of the optional ac= tive=20 PW selection mechanism in section 5.1. I pasted below the correspondin= g=20 paragraph of Section 5.1 with the changes we agreed to underlined. =20
 
He also asked if the default active PW selection= =20 mechanism should be referenced in Section 5.2 with the Master/Slave mode of= =20 operation. Although, it is not stricly required for interoperability,=20 implementations would benefit from a consistent behaviour. I used SHOULD in= that=20 case. The text is also pasted below with the changes=20 underlined.
 
Let me know if you have any comments on=20 this.
 
Regards,
Mustapha.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I. Changes to Section 5.1 - 3rd=20 paragraph:
"

If more than one PW qualifies for the A= ctive=20 state, each PW endpoint MUST implement a common mechanism to choose the PW = for=20 forwarding. The default mechanism MUST be supported by all implementations = and=20 operates as follows:

1.    =20 For FEC128 PW, the PW with = the=20 lowest pw-id value is selected.

2.    =20 For FEC129 PW, each PW in a= =20 redundant set is uniquely identified at each PE using the following triplet= :=20 AGI::SAII::TAII. The unsigned integer form of the concatenated word can be = used=20 in the comparison. However, the SAII and TAII values as seen on a PE node a= re=20 the mirror values of what the peer PE node sees. To have both PE nodes comp= are=20 the same value we propose that the PE with the lowest system IP address use= the=20 unsigned integer form of AGI::SAII::TAII while the PE with the highest syst= em IP=20 address use the unsigned integer form of AGI::TAII::SAII. This way, both PE= s=20 will compare the same values. The PW which corresponds to the minimum of th= e=20 compared values across all PWs in the redundant is=20 selected.

Note 1: in the case where the system IP= address=20 is not known, it is recommended to implement the optional active PW=20 selection mechanism described next.

Note 2: in the case of segmented PW, th= e=20 operator needs to make sure that the pw-id or AGI::SAII::TAII of the redund= ant=20 PWs within the first and last segment are ordered consistently such that th= e=20 same end-to-end MS-PW gets selected. Otherwise, it is recommended to implem= ent=20 the optional active PW selection mechanism described=20 next.

The PW endpoints MAY also implement the= =20 following optional active PW selection mechanism.=20

1.    =20 If the PW endpoint is confi= gured=20 with the precedence parameter on each PW in the redundant set, it must sele= ct=20 the PW with the lowest configured precedence value.=20

2.    =20 If the PW endpoint is confi= gured=20 with one PW as primary and one or more PWs as secondary, it must select the= =20 primary PW in preference to all secondary PWs. If a primary PW is not avail= able,=20 it must use the secondary PW with the lowest precedence value. If the prima= ry PW=20 becomes available, a PW endpoint must revert to it immediately or after the= =20 expiration of a configurable delay.

3.    =20 This active PW selection= =20 mechanism assumes the precedence parameter values are configured consistent= ly at=20 both PW endpoints and that unique values are assigned to the PWs in the sam= e=20 redundancy set to achieve tie-breaking using this=20 mechanism.

"
 
II. Changes to Section 5.2 - 5th=20 paragraph:
"

If more than one PW qualify for the Act= ive=20 state, the Master PW endpoint node selects one. There is no requirement = to=20 specify a default active PW selection mechanism in this case but for consis= tency=20 across implementations, the Master PW endpoint SHOULD implement the default= =20 active PW selection mechanism described in Section 5.1.=20

If the Master PW endpoint implements th= e=20 optional active PW selection mechanism based on primay/secondary and preced= ence=20 parameters, it MUST follow the following behaviour:=20

1.    =20 If the PW endpoint is=20 configured with the precedence parameter on each PW in the redundant s= et,=20 it must select the PW with the lowest configured precedence=20 value.

2.    =20 If the PW endpoint is=20 configured with one PW as primary and one or more PWs as secondary, it= must=20 select the primary PW in preference to all secondary PWs. If a primary= PW=20 is not available, it must use the secondary PW with the lowest precede= nce=20 value. If the primary PW becomes available, a PW endpoint must revert = to it=20 immediately or after the expiration of a configurable=20 delay.

"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: Aissaoui, Mustapha (Mustapha)=20
Sent: Wednesday, March 07, 2012 12:56 PM
To: Andrew G.= =20 Malis
Cc: stbryant@cisco.com;=20 draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3@ietf.org;=20 ietf@ietf.org
Subject: RE: [PWE3] Last Call:=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard

makes sense Andy.
 
Thanks,
Mustapha.

From: Andrew G. Malis [mailto:amalis@gm= ail.com]=20
Sent: Wednesday, March 07, 2012 12:53 PM
To: Aissaoui,= =20 Mustapha (Mustapha)
Cc: stbryant@cisco.com;=20 draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3@ietf.org;=20 ietf@ietf.org
Subject: Re: [PWE3] Last Call:=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard

Mustapha,

You might want to wait for any other LC comment= s=20 before updating.

Thanks,
Andy

On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha= =20 (Mustapha) <mustapha.aissaoui@alca= tel-lucent.com>=20 wrote:
Ooops. Thank you for pointing this out Stewart. I will = make=20 the update and publish a new revision.

Mustapha.

-----Original Message-----
From: Stewart Bryant=20 [mailto:stbryant@cisco.com]
= Sent:=20 Wednesday, March 07, 2012 12:48 PM
To: draft-ietf-= pwe3-redundancy-bit@tools.ietf.org
Cc:=20 ietf@ietf.org; pwe3@ietf.org
Subject: Re: Last Call= :=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard


Authors

The= re=20 was on point that I notice that you did not address from the AD review an= d so=20 I am picking it up as a LC comment:

In section 10 you=20 say:

   "This document makes the following update to the= =20 PwOperStatusTC
   textual convention in RFC5542 [8]:=20 "

This update should be recorded in the metadata (top left front p= age)=20 and it is usual to put a one line note in the=20 abstract.

Stewart



On 07/03/2012 17:00, The IESG=20 wrote:
> The IESG has received a request from the Pseudowire Emulat= ion=20 Edge to
> Edge WG (pwe3) to consider the following document:
>= ; -=20 'Pseudowire Preferential Forwarding Status Bit'
>  =20  <draft-ietf-pwe3-redundancy-bit-06.txt>  as a Proposed=20 Standard
>
> The IESG plans to make a decision in the next fe= w=20 weeks, and solicits
> final comments on this action. Please send=20 substantive comments to the
> ietf@ietf.org mailing lists by 2012-03-= 21.=20 Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, = please=20 retain the
> beginning of the Subject line to allow automated=20 sorting.
>
> Abstract
>
>
>     T= his=20 document describes a mechanism for standby status signaling of
> &n= bsp;=20   redundant pseudowires (PWs) between their termination points. A=20 set
>     of redundant PWs is configured between provider= edge=20 (PE) nodes in
>     single-segment pseudowire (SS-PW)=20 applications, or between
>     terminating provider edge= =20 (T-PE) nodes in multi-segment pseudowire
>     (MS-PW)=20 applications.
>
>     In order for the PE/T-PE node= s to=20 indicate the preferred PW to use
>     for forwarding PW= =20 packets to one another, a new status bit is needed
>     = to=20 indicate a preferential forwarding status of Active or Standby for
>= ;=20     each PW in a redundant set.
>
>     I= n=20 addition, a second status bit is defined to allow peer PE nodes to
>= ;=20     coordinate a switchover operation of the=20 PW.
>
>
>
>
>
>
> The file can = be=20 obtained via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundanc= y-bit/
>
>=20 IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundanc= y-bit/ballot/
>
>
>=20 No IPR declarations have been submitted directly on this=20 I-D.
>
>
>=20 _______________________________________________
> IETF-Announce mai= ling=20 list
> IETF-Announce@ietf.org
>= https://www.ietf.org/mailman/listinfo/ietf-announce>


--
For=20 corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/i= ndex.html


_______________________________________________pwe3=20 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
<= /DIV>

--_000_5DF53972F7E9134782DCE51624466FE50AD59605CDUSNAVSXCHMBSC_-- From david.sinicrope@ericsson.com Tue Mar 27 22:30:33 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF6021E8088 for ; Tue, 27 Mar 2012 22:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.049 X-Spam-Level: X-Spam-Status: No, score=-106.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7nS8Urf3NBS for ; Tue, 27 Mar 2012 22:30:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B225E21E8047 for ; Tue, 27 Mar 2012 22:30:32 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2S5UUx7032415 for ; Wed, 28 Mar 2012 00:30:31 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 28 Mar 2012 01:30:27 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Wed, 28 Mar 2012 01:30:23 -0400 Thread-Topic: [PWE3] PWE3 IETF 83 Slot Requests Thread-Index: Ac0Mo+GcQ3oYB+KNS62VgZ6JBRpIog== Message-ID: References: In-Reply-To: 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 Subject: Re: [PWE3] PWE3 IETF 83 Slot Requests X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 05:30:33 -0000 Presenters, Last day to get your presentations to me for upload. If there is an X by y= our agenda slot, I don't have a slide set. Please send them via reply to th= is email by 5pm Paris time today. Thanks! Dave On Mar 20, 2012, at 11:29 AM, "David Sinicrope" wrote: > Hi All, > Sorry for the delay. The agenda for next week's meeting is posted. > (http://www.ietf.org/proceedings/83/agenda/agenda-83-pwe3.txt) >=20 > Running order is subject to change at the discretion of the Chairs. >=20 > Presenters, please reply to this email and send me your slides for upload= . > All slides must be received prior to 5pm Paris time, Wednesday, March 28 > or you risk losing your slot. >=20 > Thanks, > Dave >=20 >=20 > -----Original Message----- > From: David A Sinicrope > Date: Mon, 5 Mar 2012 19:29:06 -0500 > To: "IETF.PWE3" > Cc: David A Sinicrope > Subject: Re: [PWE3] PWE3 IETF 83 Slot Requests >=20 >> Hi All, >> I've started to put together the Paris PWE3 agenda based on the requests >> I've received to date. >> Please check out:=20 >> http://www.ietf.org/proceedings/83/agenda/agenda-83-pwe3.txt (running >> order is subject to change) >> If you have requested a slot, please make sure I've reflected it >> accurately.=20 >> If you need a slot and haven't yet requested one, please refer to the >> email below. >> If you have questions, please send them to the list. >>=20 >> Thanks, >> Dave=20 >>=20 >>=20 >> -----Original Message----- >> From: David A Sinicrope >> Date: Fri, 24 Feb 2012 03:11:36 -0500 >> To: "IETF.PWE3" >> Subject: [PWE3] PWE3 IETF 83 Slot Requests >>=20 >>> Hi All, >>> If you need a presentation slot for the IETF 83 PWE3 session, please >>> reply to this email (subject intact) with: >>> -topic >>> -draft name >>> -requested duration >>> -speaker >>>=20 >>> Thanks, >>> Dave >>>=20 >>>=20 >>> On Feb 23, 2012, at 3:45 PM, "Malis, Andrew G (Andy)" >>> > wrote: >>>=20 >>>=20 >>>=20 >>> Cheers, >>> Andy >>> Sent from my Verizon DROID 3 >>>=20 >>>=20 >>> -----Original Message----- >>> From: "IETF Secretariat" [agenda@ietf.org] >>> Sent: Thursday, February 23, 2012 03:43 PM Eastern Standard Time >>> To:=20 >>> matthew.bocci@alcatel-lucent.com >>> Cc: pwe3-ads@tools.ietf.org; >>> pwe3-chairs@tools.ietf.org; >>> wlo@amsl.com >>> Subject: pwe3 - Requested session has been scheduled for IETF 83 >>>=20 >>>=20 >>> Dear Matthew Bocci, >>>=20 >>> The sessions that you have requested have been scheduled. >>> Below is the scheduled session information followed by >>> the original request. >>>=20 >>> pwe3 Session 1 (2.5 hours) >>> Thursday, Morning Session I 0930-1130 >>> Room Name: 242AB >>> --------------------------------------------- >>>=20 >>>=20 >>>=20 >>> Request Information: >>>=20 >>> --------------------------------------------------------- >>> Working Group Name: Pseudowire Emulation Edge to Edge >>> Area Name: Routing Area >>> Session Requester: Wanda Lo >>>=20 >>> Number of Sessions: 1 >>> Length of Session(s): 2.5 hours >>> Number of Attendees: 120 >>> Conflicts to Avoid: >>> First Priority: ccamp l2vpn l3vpn mpls tictoc ancp rtgarea rtgwg >>> Second Priority: intarea >>>=20 >>>=20 >>>=20 >>>=20 >>> Special Requests: >>>=20 >>> --------------------------------------------------------- >>>=20 >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>=20 >=20 From sriganeshkini@gmail.com Wed Mar 28 07:30:21 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8021E8097 for ; Wed, 28 Mar 2012 07:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uv5x71KL6CY for ; Wed, 28 Mar 2012 07:30:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABF621F88BB for ; Wed, 28 Mar 2012 07:30:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so849581vbb.31 for ; Wed, 28 Mar 2012 07:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=DB66Hfn3cl1xqP07w/da4XKGBCQlq8s0UFTKK66MVE0=; b=Yu1Dn6znIK9flERVbt/uwADrukFO1nYef4TJHXPvoEBlWc6zpCicwcIWbQgCOHZYXW 4wnhkbZ5OWb56CEUAQcQO83MmYYIhEzFCK0hpw8h3w2twBUB+ax0BjmLN6oej2el7tif bJa8vglQAIHkk3v6MEbDEr8m4jpTL/yLVOzUl18yxgkd9MZqrRMQJ/4HVW/dCOXnqySw aWy9H8zsSAq+8wLpX7A/WU+Ayc2qUUfJTsb+iLf8N/VC4qqLA6XP4c89si4U6KayMtKn Zx/aMEEgEk3bXk+3GGbCpDacBg+MmbmkJy9jXoKY8fFLGHrq7ycBd2epTUB9DCmWe5/L mjRw== MIME-Version: 1.0 Received: by 10.220.152.205 with SMTP id h13mr9908744vcw.12.1332945020333; Wed, 28 Mar 2012 07:30:20 -0700 (PDT) Sender: sriganeshkini@gmail.com Received: by 10.220.200.193 with HTTP; Wed, 28 Mar 2012 07:30:19 -0700 (PDT) Date: Wed, 28 Mar 2012 07:30:19 -0700 X-Google-Sender-Auth: aM8NBen0PkY40pd3tn_y5i1w-gg Message-ID: From: Sriganesh Kini To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7d0e712dcc04bc4e7243 Subject: [PWE3] Comments on draft-jc-pwe3-mpls-tp-static-checking-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:30:22 -0000 --f46d043c7d0e712dcc04bc4e7243 Content-Type: text/plain; charset=UTF-8 Comments 1. My first thought on looking at this - what is the relationship of this to a signaling protocol (LDP) ? Is this trying to replicate that functionality or provide som new functionality ? 2. Is this checking intended to be used as operator initiated or proactive checking ? 3. The term "corresponding PSN tunnel" has been used. I guess this means the PSN tunnel to which the PW is nailed to (?) However there is no receive check to ensure that the received msg is indeed on a tunnel that is carrying the PW. Even if there was, what is the need to map this to the 'corresponding' PSN tunnel ? 4. If just the in-label is sent can this be used as a label advertisement mechanism ? -- - Sri --f46d043c7d0e712dcc04bc4e7243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Comments

1. My first= thought on looking at this - what is the relationship of this to a signali= ng protocol (LDP) ? Is this trying to replicate that functionality or provi= de som new functionality ?

2. Is this checking intended to be used as operator initiated or p= roactive checking ?

3. The term "corresponding PSN tunnel" has been used. I gue= ss this means the PSN tunnel to which the PW is nailed to (?) However there= is no receive check to ensure that the received msg is indeed on a tunnel = that is carrying the PW. Even if there was, what is the need to map this to= the 'corresponding' PSN tunnel ?


4. If just the in-label is sent can this be used as a label advertise= ment mechanism ?


<= /div>

--
- Sri
--f46d043c7d0e712dcc04bc4e7243-- From KingstonS@ipinfusion.com Wed Mar 28 10:13:11 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1093321E82A8 for ; Wed, 28 Mar 2012 10:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UzJKQw5aOJf for ; Wed, 28 Mar 2012 10:13:08 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id A873321E80A4 for ; Wed, 28 Mar 2012 10:13:08 -0700 (PDT) Received: from mail87-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 17:13:07 +0000 Received: from mail87-tx2 (localhost [127.0.0.1]) by mail87-tx2-R.bigfish.com (Postfix) with ESMTP id 55B4A1E00A6; Wed, 28 Mar 2012 17:13:07 +0000 (UTC) X-SpamScore: 0 X-BigFish: PS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail87-tx2: domain of ipinfusion.com designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=KingstonS@ipinfusion.com; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail87-tx2 (localhost.localdomain [127.0.0.1]) by mail87-tx2 (MessageSwitch) id 1332954786104776_376; Wed, 28 Mar 2012 17:13:06 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.253]) by mail87-tx2.bigfish.com (Postfix) with ESMTP id 131EC1800BA; Wed, 28 Mar 2012 17:13:06 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 17:13:04 +0000 Received: from BL2PRD0510MB363.namprd05.prod.outlook.com ([169.254.3.190]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0135.002; Wed, 28 Mar 2012 17:13:04 +0000 From: Kingston Selvaraj To: "lizhong.jin@zte.com.cn" , "chen.ran@zte.com.cn" Thread-Topic: Some comments on draft-jc-pwe3-mpls-tp-static-checking-00 Thread-Index: Ac0NBgRWFYqCgs9dSqK1TdrfrFY9hg== Date: Wed, 28 Mar 2012 17:13:03 +0000 Message-ID: <4090125F3B48764B84FB3439456F00E90F9904B4@BL2PRD0510MB363.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.84.20] Content-Type: multipart/alternative; boundary="_000_4090125F3B48764B84FB3439456F00E90F9904B4BL2PRD0510MB363_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0510HT002.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0510HT002.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: "pwe3@ietf.org" Subject: [PWE3] Some comments on draft-jc-pwe3-mpls-tp-static-checking-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:13:11 -0000 --_000_4090125F3B48764B84FB3439456F00E90F9904B4BL2PRD0510MB363_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, Couple of comments and questions regarding this draft. 1. This draft doesn't cover the operational details of multi-segment = PW. 2. Draft says that, PE will start transmitting the GAP message immedi= ately after PW configuration and PSN tunnel is UP. Let us consider a scenario where in PW is configured in PE1 (of course the= PSN tunnel is UP) and not configured in other side of PE (PE2). What will happen in this scenario?. Will the GAP message will be transmitte= d only thrice and will be stopped by PE1? Or will it always be re-transmitted by PE1? Regards, S. Kingston Smiler. --_000_4090125F3B48764B84FB3439456F00E90F9904B4BL2PRD0510MB363_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

Couple of comments and questions regarding this draf= t.

 

1.     &= nbsp; This draft doesn’t cover the operational deta= ils of multi-segment PW.

 

2.     &= nbsp; Draft says that, PE will start transmitting the GAP= message immediately after PW configuration and PSN tunnel is UP.

Let us consider a scenario where in PW is con= figured in PE1  (of course the PSN tunnel is UP) and  not configu= red in other side of PE (PE2).

What will happen in this scenario?. Will the = GAP message will be transmitted only thrice and will be stopped by PE1?

Or will it always be re-t= ransmitted by PE1?

 

Regards,

S. Kingston Smiler.

--_000_4090125F3B48764B84FB3439456F00E90F9904B4BL2PRD0510MB363_-- From lizhong.jin@zte.com.cn Wed Mar 28 13:26:13 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9850F21E80A3 for ; Wed, 28 Mar 2012 13:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.599 X-Spam-Level: X-Spam-Status: No, score=-100.599 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH9EoEJvJBci for ; Wed, 28 Mar 2012 13:26:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9321E8019 for ; Wed, 28 Mar 2012 13:26:12 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 286201397396305; Thu, 29 Mar 2012 03:50:49 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 70127.1789518762; Thu, 29 Mar 2012 04:11:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2SKQ4mC032992; Thu, 29 Mar 2012 04:26:04 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <4090125F3B48764B84FB3439456F00E90F9904B4@BL2PRD0510MB363.namprd05.prod.outlook.com> To: Kingston Selvaraj MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Wed, 28 Mar 2012 21:25:47 +0100 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-29 04:26:04, Serialize complete at 2012-03-29 04:26:04 Content-Type: multipart/alternative; boundary="=_alternative 00703C5CC12579CF_=" X-MAIL: mse02.zte.com.cn q2SKQ4mC032992 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Some comments on draft-jc-pwe3-mpls-tp-static-checking-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:26:13 -0000 This is a multipart message in MIME format. --=_alternative 00703C5CC12579CF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgS2luZ3N0b24sDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cywgc2VlIGlubGluZSBiZWxv dy4NCg0KUmVnYXJkcw0KTGl6aG9uZw0KIA0KDQpLaW5nc3RvbiBTZWx2YXJhaiA8S2luZ3N0b25T QGlwaW5mdXNpb24uY29tPiB3cm90ZSAyMDEyLzAzLzI4IDE5OjEzOjAzOg0KDQo+IEhpIEF1dGhv cnMsDQo+IA0KPiBDb3VwbGUgb2YgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhp cyBkcmFmdC4NCj4gDQo+IDEuICAgICAgIFRoaXMgZHJhZnQgZG9lc26hr3QgY292ZXIgdGhlIG9w ZXJhdGlvbmFsIGRldGFpbHMgb2YgDQptdWx0aS1zZWdtZW50IFBXLg0KW0xpemhvbmddIHllcywg TVMtUFcgc2hvdWxkIGJlIGluY2x1ZGVkLCBhbmQgd2lsbCB1cGRhdGUgaW4gbmV4dCB2ZXJzaW9u Lg0KDQo+IA0KPiAyLiAgICAgICBEcmFmdCBzYXlzIHRoYXQsIFBFIHdpbGwgc3RhcnQgdHJhbnNt aXR0aW5nIHRoZSBHQVAgbWVzc2FnZQ0KPiBpbW1lZGlhdGVseSBhZnRlciBQVyBjb25maWd1cmF0 aW9uIGFuZCBQU04gdHVubmVsIGlzIFVQLiANCj4gTGV0IHVzIGNvbnNpZGVyIGEgc2NlbmFyaW8g d2hlcmUgaW4gUFcgaXMgY29uZmlndXJlZCBpbiBQRTEgIChvZiANCj4gY291cnNlIHRoZSBQU04g dHVubmVsIGlzIFVQKSBhbmQgIG5vdCBjb25maWd1cmVkIGluIG90aGVyIHNpZGUgb2YgUEUgDQoo UEUyKS4gDQo+IFdoYXQgd2lsbCBoYXBwZW4gaW4gdGhpcyBzY2VuYXJpbz8uIFdpbGwgdGhlIEdB UCBtZXNzYWdlIHdpbGwgYmUgDQo+IHRyYW5zbWl0dGVkIG9ubHkgdGhyaWNlIGFuZCB3aWxsIGJl IHN0b3BwZWQgYnkgUEUxPw0KPiBPciB3aWxsIGl0IGFsd2F5cyBiZSByZS10cmFuc21pdHRlZCBi eSBQRTE/IA0KW0xpemhvbmddIGluIHRoYXQgY2FzZSwgUEUxIHdpbGwgY29udGludWUgc2VuZGlu ZyBHQVAgbWVzc2FnZSwgdW50aWwgUEUyIA0KaXMgYWxzbyBjb25maWd1cmVkLiBBZnRlciBQRTEv UEUyIGdldHRpbmcgYm90aCBsb2NhbCBhbmQgcmVtb3RlIA0KaW5mb3JtYXRpb24sIGFuZCBmaW5p c2hlZCBjaGVja2luZywgdGhlbiBpdCB3aWxsIHNlbmQgc3VwcHJlc3MgbWVzc2FnZSB0byANCnN0 b3AgdGhlIG1lc3NhZ2UgcHJvY2VkdXJlLiBXaWxsIHJlcGhyYXNlIHRoZSBkcmFmdCB0byBtYWtl IHRoaXMgbW9yZSANCmNsZWFyLg0KDQo+IA0KPiBSZWdhcmRzLA0KPiBTLiBLaW5nc3RvbiBTbWls ZXIuDQo= --=_alternative 00703C5CC12579CF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEtpbmdzdG9uLDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB0aGUgY29t bWVudHMsIHNlZSBpbmxpbmUNCmJlbG93LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+TGl6aG9uZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5LaW5nc3RvbiBTZWx2YXJhaiAmbHQ7S2luZ3N0b25TQGlwaW5mdXNpb24uY29tJmd0Ow0K d3JvdGUgMjAxMi8wMy8yOCAxOToxMzowMzo8YnI+DQo8YnI+DQomZ3Q7IEhpIEF1dGhvcnMsPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBDb3VwbGUgb2YgY29t bWVudHMgYW5kIHF1ZXN0aW9ucw0KcmVnYXJkaW5nIHRoaXMgZHJhZnQuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAxLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBU aGlzIGRyYWZ0DQpkb2VzbqGvdCBjb3ZlciB0aGUgb3BlcmF0aW9uYWwgZGV0YWlscyBvZiBtdWx0 aS1zZWdtZW50IFBXLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ W0xpemhvbmddIHllcywgTVMtUFcgc2hvdWxkIGJlIGluY2x1ZGVkLA0KYW5kIHdpbGwgdXBkYXRl IGluIG5leHQgdmVyc2lvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7IDIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IERyYWZ0IHNheXMNCnRoYXQsIFBF IHdpbGwgc3RhcnQgdHJhbnNtaXR0aW5nIHRoZSBHQVAgbWVzc2FnZTxicj4NCiZndDsgaW1tZWRp YXRlbHkgYWZ0ZXIgUFcgY29uZmlndXJhdGlvbiBhbmQgUFNOIHR1bm5lbCBpcyBVUC4gPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IExldCB1cyBjb25zaWRl ciBhIHNjZW5hcmlvIHdoZXJlDQppbiBQVyBpcyBjb25maWd1cmVkIGluIFBFMSAmbmJzcDsob2Yg PGJyPg0KJmd0OyBjb3Vyc2UgdGhlIFBTTiB0dW5uZWwgaXMgVVApIGFuZCAmbmJzcDtub3QgY29u ZmlndXJlZCBpbiBvdGhlciBzaWRlDQpvZiBQRSAoUEUyKS4gPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFdoYXQgd2lsbCBoYXBwZW4gaW4gdGhpcyBzY2Vu YXJpbz8uDQpXaWxsIHRoZSBHQVAgbWVzc2FnZSB3aWxsIGJlIDxicj4NCiZndDsgdHJhbnNtaXR0 ZWQgb25seSB0aHJpY2UgYW5kIHdpbGwgYmUgc3RvcHBlZCBieSBQRTE/PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IE9yIHdpbGwgaXQgYWx3YXlzIGJlIHJl LXRyYW5zbWl0dGVkDQpieSBQRTE/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+W0xpemhvbmddIGluIHRoYXQgY2FzZSwgUEUxIHdpbGwgY29udGludWUNCnNlbmRp bmcgR0FQIG1lc3NhZ2UsIHVudGlsIFBFMiBpcyBhbHNvIGNvbmZpZ3VyZWQuIEFmdGVyIFBFMS9Q RTIgZ2V0dGluZw0KYm90aCBsb2NhbCBhbmQgcmVtb3RlIGluZm9ybWF0aW9uLCBhbmQgZmluaXNo ZWQgY2hlY2tpbmcsIHRoZW4gaXQgd2lsbA0Kc2VuZCBzdXBwcmVzcyBtZXNzYWdlIHRvIHN0b3Ag dGhlIG1lc3NhZ2UgcHJvY2VkdXJlLiBXaWxsIHJlcGhyYXNlIHRoZQ0KZHJhZnQgdG8gbWFrZSB0 aGlzIG1vcmUgY2xlYXIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jmd0OyBSZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jmd0OyBTLiBLaW5nc3RvbiBTbWlsZXIuPC9mb250Pg0K --=_alternative 00703C5CC12579CF_=-- From lizhong.jin@zte.com.cn Wed Mar 28 13:49:20 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8586921E8089 for ; Wed, 28 Mar 2012 13:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.451 X-Spam-Level: X-Spam-Status: No, score=-101.451 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znih9NjAXjZe for ; Wed, 28 Mar 2012 13:49:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6103021E8043 for ; Wed, 28 Mar 2012 13:49:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201397396305; Thu, 29 Mar 2012 04:13:57 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 93082.2133006739; Thu, 29 Mar 2012 04:49:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2SKnCnu030435; Thu, 29 Mar 2012 04:49:12 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: MIME-Version: 1.0 To: pwe3@ietf.org, sriganesh.kini@ericsson.com X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Wed, 28 Mar 2012 21:48:53 +0100 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-29 04:49:12, Serialize complete at 2012-03-29 04:49:12 Content-Type: multipart/alternative; boundary="=_alternative 007258FFC12579CF_=" X-MAIL: mse01.zte.com.cn q2SKnCnu030435 Subject: Re: [PWE3] Comments on draft-jc-pwe3-mpls-tp-static-checking-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:49:20 -0000 This is a multipart message in MIME format. --=_alternative 007258FFC12579CF_= Content-Type: text/plain; charset="US-ASCII" Hi Sri, See inline please. Thank you for the comments. Lizhong > ------------------------------ > > Message: 2 > Date: Wed, 28 Mar 2012 07:30:19 -0700 > From: Sriganesh Kini > To: "pwe3@ietf.org" > Subject: [PWE3] Comments on > draft-jc-pwe3-mpls-tp-static-checking-00.txt > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Comments > > 1. My first thought on looking at this - what is the relationship of this > to a signaling protocol (LDP) ? Is this trying to replicate that > functionality or provide som new functionality ? [Lizhong] this mechanism is to only check the configuration, after finished, the mechanism will be stopped. So it is a checking tool, not a signaling protocol. The checking procedure is part of same as that does in signaling protocol (LDP), but there is also exception, e.g, control word checking. > > 2. Is this checking intended to be used as operator initiated or proactive > checking ? [Lizhong] depends on the implementation. In the draft, it is suggested to be trigged basically by configuration changing. It could be also triggered by a CLI command. > > 3. The term "corresponding PSN tunnel" has been used. I guess this means > the PSN tunnel to which the PW is nailed to (?) [Lizhong] yes > However there is no receive > check to ensure that the received msg is indeed on a tunnel that is > carrying the PW. Even if there was, what is the need to map this to the > 'corresponding' PSN tunnel ? [Lizhong] GAP should carry LSP Identifier in the message, and then could check if the LSP Identifier is the corresponding PSN tunnel. The draft is lack of this content, and would be added in new version. Only when its corresponding PSN Tunnel is UP, the PW could be UP, so we use PW's underlying PSN tunnel to transmit parameters. > > > 4. If just the in-label is sent can this be used as a label advertisement > mechanism ? [Lizhong] yes, could do that, and is only used to advertise label, nothing else (e.g, status). In that case, the static PW could be configured only with in-label, to reduce configuration burden. > > > > -- > - Sri > ------------------------------ > --=_alternative 007258FFC12579CF_= Content-Type: text/html; charset="US-ASCII"
Hi Sri,
See inline please. Thank you for the comments.

Lizhong


> ------------------------------
>
> Message: 2
> Date: Wed, 28 Mar 2012 07:30:19 -0700
> From: Sriganesh Kini <sriganesh.kini@ericsson.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] Comments on
>    draft-jc-pwe3-mpls-tp-static-checking-00.txt
> Message-ID:
>    <CAOndX-uWUpdr9Pc53QvGjfunSchSMLNJsS8OOyuxghgwX8GfKQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Comments
>
> 1. My first thought on looking at this - what is the relationship of this
> to a signaling protocol (LDP) ? Is this trying to replicate that
> functionality or provide som new functionality ?
[Lizhong] this mechanism is to only check the configuration, after finished, the mechanism will be stopped. So it is a checking tool, not a signaling protocol. The checking procedure is part of same as that does in signaling protocol (LDP), but there is also exception, e.g, control word checking.

>
> 2. Is this checking intended to be used as operator initiated or proactive
> checking ?
[Lizhong] depends on the implementation. In the draft, it is suggested to be trigged basically by configuration changing. It could be also triggered by a CLI command.
>
> 3. The term "corresponding PSN tunnel" has been used. I guess this means
> the PSN tunnel to which the PW is nailed to (?)
[Lizhong] yes

> However there is no receive
> check to ensure that the received msg is indeed on a tunnel that is
> carrying the PW. Even if there was, what is the need to map this to the
> 'corresponding' PSN tunnel ?
[Lizhong] GAP should carry LSP Identifier in the message, and then could check if the LSP Identifier is the corresponding PSN tunnel. The draft is lack of this content, and would be added in new version. Only when its corresponding PSN Tunnel is UP, the PW could be UP, so we use PW's underlying PSN tunnel to transmit parameters.

>
>
> 4. If just the in-label is sent can this be used as a label advertisement
> mechanism ?
[Lizhong] yes, could do that, and is only used to advertise label, nothing else (e.g, status). In that case, the static PW could be configured only with in-label, to reduce configuration burden.

>
>
>
> --
> - Sri
> ------------------------------
> --=_alternative 007258FFC12579CF_=-- From jie.dong@huawei.com Thu Mar 29 01:30:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1421F8934 for ; Thu, 29 Mar 2012 01:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNp1xalfTjvn for ; Thu, 29 Mar 2012 01:30:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EE8F721F892F for ; Thu, 29 Mar 2012 01:30:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM13190; Thu, 29 Mar 2012 04:30:21 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 01:27:27 -0700 Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 01:27:23 -0700 Received: from LHREML514-MBX.china.huawei.com ([10.201.4.201]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 09:27:20 +0100 From: Jie Dong To: "pwe3@ietf.org" Thread-Topic: Control plane based PW LI and LB Thread-Index: Ac0Ng58qcaqQ7iZVTDCx3SEFizcByw== Date: Thu, 29 Mar 2012 08:27:19 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92723DFA598@lhreml514-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.7.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [PWE3] Control plane based PW LI and LB X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:30:23 -0000 So far there are several drafts working on control plane based MPLS-TP OAM = provisioning mechanism. And provisioning of LI and LB are quite similar to = those OAM provisionings.=20 Though we have inband/NMS based LI LB in RFC6435, it would be useful to als= o have control plane based LI and LB. The NMS based mechanism doesn't prev= ent doing that in the control plane. This is similar to other OAM configura= tions currently available in Target LDP for pseudowires.=20 Any comment on draft-dong-pwe3-mpls-tp-li-lb-00 would be more than welcome. Best regards, Jie=