From nobody Tue Jun 3 03:01:18 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE51A00E7 for ; Tue, 3 Jun 2014 03:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqLg1v4c5TPY for ; Tue, 3 Jun 2014 03:01:08 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456251A00D7 for ; Tue, 3 Jun 2014 03:01:08 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s53A10tX028554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Jun 2014 05:01:01 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s53A0eoU001444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Jun 2014 12:00:59 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 12:00:52 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Thread-Topic: Duplicate AII LDP Status Code in draft-ietf-pwe3-dynamic-ms-pw-22 Thread-Index: AQHPfxKzkhFJknSj+Eq4bNfGgZGt7Q== Date: Tue, 3 Jun 2014 10:00:52 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_CFB35B6263DCFmatthewboccialcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/LS8Us0VwDRb9xztV_rJ7m3qy1Bs Subject: [PWE3] Duplicate AII LDP Status Code in draft-ietf-pwe3-dynamic-ms-pw-22 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:01:13 -0000 --_000_CFB35B6263DCFmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Working Group, While reviewing draft-ietf-pwe3-dynamic-ms-pw-22 (RFC-to-be 7276) in during= the RFC Editor process, we found that the LDP status code =93Duplicate AII= =94 referenced in Section 4.2 does not exist in any LDP code point registri= es, does not have a proposed value, and does not have an associated reques= t for an IANA allocation. The authors understand that existing implementations are actually using "P= W Loop Detected" instead of a new status code for "Duplicate AII=94. We therefore intend to change "Duplicate AII" to =93PW Loop Detected=94 in= Section 4.2, which already has a value of 0x0000003A allocated. If we subsequently find that a more explicit status code is required to des= cribe this condition, then a new draft can be written to request such an al= location and update RFC 7276. Regards Matthew --_000_CFB35B6263DCFmatthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Working Group,

While reviewing draft-ietf-pwe3-dynamic-ms-pw-22 (RFC-to-be 7276)= in during the RFC Editor process, we found that the LDP status code =93Dup= licate AII=94 referenced in Section 4.2 does not exist in any LDP code poin= t registries, does not have a proposed value, and does not have an associated  request for an IANA allocation. = ;

The authors  understand that existing implementations are actuall= y using "PW Loop Detected" instead of a new status code for "= ;Duplicate AII=94.

We therefore intend to change "Duplicate AII" to =93PW  = ;Loop Detected=94 in Section 4.2, which already has a value of 0x0000003A allocated. 

If we subsequently find that a more explicit status code is required t= o describe this condition, then a new draft can be written to request such = an allocation and update RFC 7276.

Regards

Matthew

--_000_CFB35B6263DCFmatthewboccialcatellucentcom_-- From nobody Wed Jun 4 04:23:03 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA7B1A02CA for ; Wed, 4 Jun 2014 04:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW7sOB2lOi5S for ; Wed, 4 Jun 2014 04:22:57 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB801A01CF for ; Wed, 4 Jun 2014 04:22:57 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so6808418qaq.3 for ; Wed, 04 Jun 2014 04:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=8583cfTOIEsS/IMBEYVN5LZc3itZpVwcWzEwGt8bvZ8=; b=g0CRTQanDT6rlgYRpxCHQ/pgslZfsqLALR7yXKpCAmViwChdxPxtyyeNgAWir8sBrZ 7qIdb3Uh1m+GJHqu1R7xNh1p+wIlOKEEFNOniYw7WRu4b2wY2iW4LLqo5af/nqOX2Ukg RMBtjzkxt/fkdw31AXjh/RXyX1BnC8Au4w66nMo6x8vx801ehKSiVXWGhnuvjCqwTQG6 7URxwfeuGAJ+Gpvt4aJKzCdmLEIlvk5DEk5ouj362RG3C6KB22S8TCUWm1L4K8C47WbR Mhq2G+D8qO3FXGcj2eomAegE5HpAGJ2VvhPxkyQD+9CYEgtoZclerAmuWDmdEUs11Wmk gpSQ== X-Received: by 10.224.126.9 with SMTP id a9mr5046442qas.39.1401880970425; Wed, 04 Jun 2014 04:22:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Wed, 4 Jun 2014 04:22:30 -0700 (PDT) In-Reply-To: <15721.1401823067@sandelman.ca> References: <15721.1401823067@sandelman.ca> From: "Andrew G. Malis" Date: Wed, 4 Jun 2014 07:22:30 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2ef6e42795204fb00d973 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/8pqZOEOgTVhsFLlaqfyKcbmkJdE Subject: [PWE3] Fwd: second call: NomCom 2014-2015 Call for Volunteers X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 11:23:00 -0000 --001a11c2ef6e42795204fb00d973 Content-Type: text/plain; charset=UTF-8 Please think about volunteering for NomCom. Thanks, Andy ---------- Forwarded message ---------- From: Michael Richardson Date: Tue, Jun 3, 2014 at 3:17 PM Subject: second call: NomCom 2014-2015 Call for Volunteers To: ietf@ietf.org, WG Chairs The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). This is the second call for volunteers. (and you may have seen it more than once) If your name is on the below, then you have volunteered and are qualified. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from him, then please resend; it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 54 volunteers so far. The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: Your Full Name: __________-- Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ [] Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel DHRUV DHODY Dacheng Zhang Dapeng Liu Donald Eastlake Eric VYNCKE Fernando Gont Fred Baker Gonzalo Salgueiro Hongyu Li Hosnieh Rafiee Hugo Salgado John E Drake John Levine John Scudder Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Yong Mach Chen Mark Townsley Matt Lepinski Mehmet Ersue Melinda Shore Min Ye Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Yee Ralph Droms Ron Bonica Ross Callon Ross Finlayson Sam K. Aldrin Sanjay Mishra Sheng JIANG Shucheng Liu Stephan Friedl Stephan Wenger Stephen Kent Suhas Nandakumar Tim Wicinski Tissa Senevirathne Toerless Eckert Wassim Haddad Xiaohu XU Yuanlong Jiang -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --001a11c2ef6e42795204fb00d973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please think about volunteering for NomCom.

=
Thanks,
Andy

------= ---- Forwarded message ----------
From: Mi= chael Richardson <mcr+ietf@sandelman.ca>
Date: Tue, Jun 3, 2014 at 3:17 PM
Subject: second call: NomCom 2014-2015= Call for Volunteers
To: ietf@ietf.org<= /a>, WG Chairs <wgchairs@ietf.org>

The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,
and the IESG (including IETF Chair).

This is the second call for volunteers. (and you may have seen it more than=
once)

If your name is on the below, then you have volunteered and are qualified.<= br> If you have heard from me, but are not on the list, then there is some
problem, and you should have gotten a query from me to determine your
eligibility.
If you have volunteered and not heard from him, then please resend;
it got lost.

Ten voting members for the nomcom are selected in a verifiably random
way from a pool of volunteers. The more volunteers, the better chance we ha= ve
of choosing a random yet representative cross section of the IETF populatio= n.

Let's break the 200 volunteer mark again this year!
We are at 54 volunteers so far.

The details of the operation of the nomcom can be found in RFC 3777,
and BCP10/RFC3797 details the selection algorithm.

Volunteers must have attended 3 of the past 5 IETF meetings. =C2=A0As speci= fied in
RFC 3777, that means three out of the five past meetings up to the time thi= s
email announcement goes out to start the solicitation of volunteers.
The five meetings out of which you must have attended *three*
are IETF 85(Atlanta), =C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A086(Orlando), =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A087(Berlin), =C2=A0 =C2=A0 =C2=A0 =C2=A0 *= ** ANY THREE!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A088(Vancouver), =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A089(London) =C2=A0 =C2=A0 =C2=A0 =C2=A0/
If you qualify, please volunteer. =C2=A0 However, much as we want this, bef= ore you
decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible.

The list of people and posts whose terms end with the March 2015 IETF
meeting, and thus the positions for which this nomcom is responsible, are
IAOC:
To be confirmed

IAB:
Joel Halpern
Russ Housley
Eliot Lear
Xing Li
Andrew Sullivan
Dave Thaler

IESG:
Pete Resnick (Applications)
Ted Lemon (Internet)
Joel Jaeggli (Operations and Management)
Richard Barnes (RAI)
Adrian Farrel* (Routing)
Stephen Farrell (Security)
Spencer Dawkins (Transport)
Jari Arkko (Gen)

(names with * have publically indicated they will not serve another term)
The primary activity for this nomcom will begin in July 2014 and should be<= br> completed in January 2015. =C2=A0 The nomcom will have regularly scheduled<= br> conference calls to ensure progress. (We might dogfood WebRTC)
There will be activities to collect requirements from the community, review=
candidate questionnaires, review feedback from community members about
candidates, and talk to candidates.

Thus, being a nomcom member does require some time commitment; but it is al= so
a very rewarding experience.

It is very important that you be able to attend IETF91 to conduct interview= s.
Being at IETF90 is useful for training. =C2=A0Being at IETF92 is not essent= ial.

Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)<= br> June 22, 2013, as follows:

To: nomcom-chair-2014@ietf.or= g
Subject: Nomcom 2014-15 Volunteer

Please include the following information in the email body:

Your Full Name: __________--
Current Primary Affiliation:
=C2=A0 =C2=A0 // Typically what goes in the Company field
=C2=A0 =C2=A0 // in the IETF Registration Form
Emails: _______________
[<All email addresses used to register for the past 5 IETF meetings>]=
=C2=A0<Preferred email address first>
Telephone: _______________________
=C2=A0 =C2=A0 // For confirmation if selected

You should expect an email response from me within 3 business days stating<= br> whether or not you are qualified. =C2=A0If you don't receive this respo= nse,
please re-send your email with the tag "RESEND"" added to th= e subject line.

If you are not yet sure if you would like to volunteer, please consider
that nomcom members play a very important role in shaping the leadership of the IETF. =C2=A0Questions by email or voice are welcome.
Volunteering for the nomcom is a great way to contribute to the IETF!

You can find a detailed timeline on the nomcom web site at:
=C2=A0 =C2=A0 https://datatracker.ietf.org/nomcom/2014/

I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process,
within the next couple weeks.

Thank you!
Michael Richardson
mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org

=3D=3D=3D=3D=3D =C2=A0qualified volunteers so far, in alphabetical order by= first name
ANM Zaheduzzaman Sarker
Adam Montville
Bill VerSteeg
Carl Williams
Carlos Martinez
Charles Eckel
DHRUV DHODY
Dacheng Zhang
Dapeng Liu
Donald Eastlake
Eric VYNCKE
Fernando Gont
Fred Baker
Gonzalo Salgueiro
Hongyu Li
Hosnieh Rafiee
Hugo Salgado
John E Drake
John Levine
John Scudder
Linda Dunbar
Lingli Deng
Louis (Lou) Berger
Luca Martini
Lucy Yong
Mach Chen
Mark Townsley
Matt Lepinski
Mehmet Ersue
Melinda Shore
Min Ye
Ning Zong
Ole Troan
Pascal Thubert
Paul Hoffman
Peter Yee
Ralph Droms
Ron Bonica
Ross Callon
Ross Finlayson
Sam K. Aldrin
Sanjay Mishra
Sheng JIANG
Shucheng Liu
Stephan Friedl
Stephan Wenger
Stephen Kent
Suhas Nandakumar
Tim Wicinski
Tissa Senevirathne
Toerless Eckert
Wassim Haddad
Xiaohu XU
Yuanlong Jiang


--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-

--001a11c2ef6e42795204fb00d973-- From nobody Fri Jun 6 03:19:32 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793BB1A0457 for ; Fri, 6 Jun 2014 03:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVxUkOVtHnZh for ; Fri, 6 Jun 2014 03:19:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81BB1A0456 for ; Fri, 6 Jun 2014 03:19:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX97146; Fri, 06 Jun 2014 10:19:18 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 11:18:24 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 11:19:17 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.41]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 18:19:15 +0800 From: Jiangyuanlong To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: [PWE3] Poll for WG Adoption of draft-dong-pwe3-mpls-tp-li-lb-06 Thread-Index: AQHPdpxv9uuoHsvHR0+RcEsMmIsSkZtj9C6A Date: Fri, 6 Jun 2014 10:19:14 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A74F0ED@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/pUClGUYHaD4cohOubPBOM5ie53U Subject: Re: [PWE3] Poll for WG Adoption of draft-dong-pwe3-mpls-tp-li-lb-06 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 10:19:31 -0000 Support. Regards, Yuanlong -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matt= hew) Sent: Friday, May 23, 2014 11:34 PM To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG Adoption of draft-dong-pwe3-mpls-tp-li-lb-0= 6 All Please use this link for the draft (the link in the email below was incorrect). http://tools.ietf.org/html/draft-dong-pwe3-mpls-tp-li-lb-06 Regards Matthew On 23/05/2014 15:14, "Bocci, Matthew (Matthew)" wrote: >This email begins a two week poll to help the chairs determine if >there is consensus to adopt draft-dong-pwe3-mpls-tp-li-lb-06 as an PWE3 >working group draft. > >The draft can be found here: >http://tools.ietf.org/html/draft-dong-pwe3-mpls-tp-li-lb-06 > >Please read the draft and indicate to the list if you support >adoption, or if you do not support adoption (giving reasons). > >Please note that this is only a call for adoption. There needs to be >consensus that this draft is a good basis for the work, but it does >not need to be perfect at this stage. > >Coincidentally, we are also polling for knowledge of any IPR that >applies to this draft, to ensure that IPR has been disclosed in >compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for >more details). > >If you are listed as a document author or contributor please respond >to this email whether or not you are aware of any relevant IPR. The >draft will not be adopted until a response has been received from each >author and contributor. > >If you are on the PWE3 WG email list but are not listed as an author >or contributor, then please explicitly respond regarding IPR only if >you are aware of any IPR that has not yet been disclosed in >conformance with IETF rules. > >The poll for adoption will close in two weeks time, on Friday 6th June. > >Matthew and Andy _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Jun 10 14:07:39 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF491A02EC for ; Tue, 10 Jun 2014 14:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmpm3GswDbHt for ; Tue, 10 Jun 2014 14:07:12 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6C11A01B9 for ; Tue, 10 Jun 2014 14:07:12 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so3152001qcw.3 for ; Tue, 10 Jun 2014 14:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ZtYpy2RbxwY2zmT/D9xbpJD36KV+ii4NOJ6ytTBXbMY=; b=ITrCHcynP8zS9bdpjsJcola9mgUxf9BbQMd4EAR1YxJcyHo3TmrdOrjNCuKGkt++/5 pcX/49NZ4l8kD+W7N7n2FkQNrPBjRJe1oOnM0rFWHzjupRpqURzpJlRp77bm4sTM3MHw aJbPdwh1fh5txhKE5JgFLO2ViAB8XBa+FMq8xHl+W0fH3tFGzSEgyCCQfG+gFrzAQDWu ExY6KY2H2vW/KK1XlaJSQCEP1OS1L2ELwI2PGIS0o0miYp5vnISu0a9UT88ZngrFF3S9 fSPBNsX77+GlW6NXyx42ztZcjZp5EVDbmUHbT17gHTw31Yynd+p2a8CztuwN38TEe34l i8lQ== X-Received: by 10.224.92.144 with SMTP id r16mr47227553qam.10.1402434431203; Tue, 10 Jun 2014 14:07:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Tue, 10 Jun 2014 14:06:51 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 10 Jun 2014 17:06:51 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=089e015386a217c25d04fb81b6eb Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/jgWfVUVPVRCtERloBkcGU3gJbsQ Subject: [PWE3] Fwd: Improving and Restructuring the Routing Area X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:07:18 -0000 --089e015386a217c25d04fb81b6eb Content-Type: text/plain; charset=UTF-8 PWE3ers, I'm forwarding this for the benefit of those of you that haven't already seen this on the Routing Discussion email list. Note that all discussion of this email will be on that list, so you should join it if you want to participate. Use the following URL to join: https://www.ietf.org/mailman/listinfo/routing-discussion Cheers, Andy ---------- Forwarded message ---------- From: Alia Atlas Date: Tue, Jun 10, 2014 at 3:57 PM Subject: Improving and Restructuring the Routing Area To: routing-discussion@ietf.org To all participants in the Routing Area, Adrian and I are working on improving the quality, speed, and experience of getting work done in the IETF Routing Area. There are three initiatives that we are working: WG Draft QA, Routing Area specific WG chair training, and reorganizing the working groups in the area. First, we intend to use our Routing Directorate more proactively by introducing a Working Group Draft Quality Assurance (WG Draft QA) process where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call. The process will be documented on the Routing Area wiki (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow directorate reviews to report technical issues that can actually get fixed early in the process (equivalent of bug reports) as opposed to just noting the concerns in the drafts (equivalent of release notes). Second, as was discussed during the recent IESG retreat, in addition to the IETF-wide WG chair training, we intend to have a series of training sessions for WG Chairs in the Routing Area addressing topics such as judging consensus, project management, motivating volunteers, using the datatracker (via a sandbox version that can be played with safely), and sharing experiences between WG chairs. Third, we intend to reorganize the working groups in the Routing area. We feel that it is important to focus on areas where there is active interest in standardization and to be open and able to accept new work into the area. As you know, we have had several new working groups (nvo3, i2rs, sfc, spring) created in the last few years and we need to be open and able to handle more new work as it comes in. We would also like to improve the signal-to-noise ratio experienced by participants in the different working groups and improve the quantity and quality of discussion and reviews. It is likely that not all WGs in the Routing Area will be directly affected. Here is the time-line for reorganizing the WGs. NOW: public discussion on routing-discussion@ietf.org about how to reorganize the working groups to best meet our motivations. Additional focused discussions are expected on the rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. In Toronto: There will be meetings with the WG chairs and the Routing Directorate to get the ideas described and agreed upon. At the Routing Area Meeting in Toronto: Discuss the set of reorganized WGs and general charter content in the Routing Area meeting. September 2014: Based upon the feedback, suggestions, and discussion, Adrian and I finalize the reorganized WG charters. We start the internal IESG discussion and public reviews. October 2014: Formal rechartering process completes. In Honolulu: The new set of WGs meet. After Honolulu: Adrian and I deal with any issues and charter updates based upon a few months of experience. Here are the motivations that Adrian and I would like to be considered when coming up with ideas for how the WGs should be reorganized. 1) Move towards organizing working groups on functional responsibilities rather than scoping them to specific protocols. 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. 3) Create synergies for scattered functionality (example ideas: OAM, FRR, traffic-engineering) 4) Create a DISPATCH working group for clear new idea discussion; rtgwg serves some of this purpose but doesn't have a clear process and isn't drawing in the new ideas. 5) Focus Routing Area time on design centers rather than on far corner cases. 6) Each working group should have clear, well defined, and achievable goals. Noting that the Routing Area has inherited some of its WG structure from the sub-IP area, it is not a goal to force IP routing and MPLS routing to remain separated. The goal of this reorganization is not closing working groups. Adrian and Alia are perfectly capable of closing working groups without going through restructuring. For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion. Thanks, Alia and Adrian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --089e015386a217c25d04fb81b6eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PWE3ers,

I'm forwarding this for th= e benefit of those of you that haven't already seen this on the Routing= Discussion email list. Note that all discussion of this email will be on t= hat list, so you should join it if you want to participate. Use the followi= ng URL to join:

https://www.ietf.org/mailman/listinfo/routing-discussion<= /div>

Cheers,
Andy

---------- Forwarded message ----------
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, Jun 10, 2014 at 3:57 PM Subject: Improving and Restructuring the Routing Area
To: routing-discussion@ietf.org

To all participants in the Routing Area,

Adrian and I are working on improving the quality, speed, and
experience of getting work done in the IETF Routing Area. =C2=A0The= re are
three initiatives that we are working: WG Draft QA, Routing Area
=
specific WG chair training, and reorganizing the working groups in the=
area.

First, we intend to use our Routi= ng Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft QA)
process where the same selected routing directorate member will revie= w
a draft during WG draft adoption and during WG last call. =C2= =A0The process
will be documented on the Routing Area wiki
dir= ectorate reviews to report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release note= s).

Second, as was discussed during the recent IES= G retreat, in addition
to the IETF-wide WG chair training, we intend to have a series of
training sessions for WG Chairs in the Routing Area addressing topics=
such as judging consensus, project management, motivating volunt= eers,
using the datatracker (via a sandbox version that can be played
<= div>with safely), and sharing experiences between WG chairs.

=
Third, we intend to reorganize the working groups in the Routing= area.
We feel that it is important to focus on areas where there is active
interest in standardization and to be open and able to accept new = work
into the area. =C2=A0As you know, we have had several new wo= rking groups
(nvo3, i2rs, sfc, spring) created in the last few years and we need to=
be open and able to handle more new work as it comes in. =C2=A0W= e would
also like to improve the signal-to-noise ratio experience= d by
participants in the different working groups and improve the quantity<= /div>
and quality of discussion and reviews. =C2=A0It is likely that no= t all WGs
in the Routing Area will be directly affected.

Here is the time-line for reorganizing the WGs.
=C2=A0 =C2=A0NOW: public discussion on routing-discussion@ietf.org a= bout how to
=C2=A0 =C2=A0reorganize the working groups to best meet our motivation= s.
=C2=A0 =C2=A0Additional focused discussions are expected on the
<= div>=C2=A0 =C2=A0r= tg-chairs@ietf.org and rtg-dir@ietf.org mailing lists.

=C2=A0 =C2=A0In Toronto: There will be meetings with the WG chai= rs and the
=C2=A0 =C2=A0Routing Directorate to get the ideas desc= ribed and agreed upon.

=C2=A0 =C2=A0At the Routing= Area Meeting in Toronto: Discuss the set of
=C2=A0 =C2=A0reorganized WGs and general charter content in the Routin= g Area
=C2=A0 =C2=A0meeting.

=C2=A0 =C2= =A0September 2014: Based upon the feedback, suggestions, and
=C2= =A0 =C2=A0discussion, Adrian and I finalize the reorganized WG charters. = =C2=A0We
=C2=A0 =C2=A0start the internal IESG discussion and public reviews.

=C2=A0 =C2=A0October 2014: Formal rechartering proce= ss completes.

=C2=A0 =C2=A0In Honolulu: The new se= t of WGs meet.

=C2=A0 =C2=A0After Honolulu: Adrian and I deal with any issues a= nd charter
=C2=A0 =C2=A0updates based upon a few months of experi= ence.

Here are the motivations that Adrian and I w= ould like to be considered
when coming up with ideas for how the WGs should be reorganized.
=

=C2=A0 =C2=A01) Move towards organizing working groups = on functional
=C2=A0 =C2=A0responsibilities rather than scoping t= hem to specific protocols.

=C2=A0 =C2=A02) Split giant working groups so relevant = work is done in one place
=C2=A0 =C2=A0and there is an improved s= ignal-to-noise ratio for participants who
=C2=A0 =C2=A0are only i= nterested in a slice of the current working group's work.

=C2=A0 =C2=A03) Create synergies for scattered function= ality (example ideas:
=C2=A0 =C2=A0OAM, FRR, traffic-engineering)=

=C2=A0 =C2=A04) Create a DISPATCH working group f= or clear new idea discussion;
=C2=A0 =C2=A0rtgwg serves some of this purpose but doesn't have a = clear process
=C2=A0 =C2=A0and isn't drawing in the new ideas= .

=C2=A0 =C2=A05) Focus Routing Area time on desig= n centers rather than on far
=C2=A0 =C2=A0corner cases.

=C2=A0 =C2=A06) Ea= ch working group should have clear, well defined, and achievable goals.

Noting that the Routing Area has inherited some of it= s WG structure
from the sub-IP area, it is not a goal to force IP routing and MPLS
routing to remain separated.

The goal of t= his reorganization is not closing working groups. =C2=A0Adrian
an= d Alia are perfectly capable of closing working groups without going
through restructuring.

For those of you that = have read this far, thank you. =C2=A0Getting this 80%
right is go= ing to take some serious discussion and thought. =C2=A0We all
wor= k in the Routing Area together with different perspectives. =C2=A0Please
think carefully and help us have a highly focused discussion.

Thanks,
Alia and Adrian


_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion

--089e015386a217c25d04fb81b6eb-- From nobody Wed Jun 11 14:52:32 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C5D1B28AE for ; Wed, 11 Jun 2014 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0zt2Msq5OZq for ; Wed, 11 Jun 2014 14:52:26 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD9F1A029B for ; Wed, 11 Jun 2014 14:52: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 s5BLqO24029645; Wed, 11 Jun 2014 22:52:24 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5BLqNU0029639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jun 2014 22:52:23 +0100 From: "Adrian Farrel" To: Date: Wed, 11 Jun 2014 22:52:21 +0100 Message-ID: <01dc01cf85bf$6c8ad7c0$45a08740$@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: Ac+Fv2l5OVX70rFXTR6Kuhl0xMjYsA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20752.002 X-TM-AS-Result: No--24.626-10.0-31-10 X-imss-scan-details: No--24.626-10.0-31-10 X-TMASE-MatchedRID: J1szhq7AkrGnykMun0J1wpmug812qIbzGSqdEmeD/nW638ZUY6gSd09F k7nPaba8nmgKAPFUekbs7XQo7cZ0jNDayMIPbRSl081phgl5F/k4m0JsW63IXFSOymiJfTYXCS6 IUmxCo5H4Lis4dw3ZvaS7TCKNmlA0q5plusWPmZhhHpATwph+yGGNLTRnb5Yth/BqejSDeoIuu9 HtoCYkWOzv3vkTKSClDY48dK45B3zj0TZojSwaYQPZZctd3P4B0BciT9B07b4ifM7JMNHW65tjP SOeBAIlgO4H+8IZiluur97o4E4/Pzk6ht3Zk7sAR+GtoiXVeDFwryoe90UcsG3D6f6IpbLID+uV JiCTS+Qu0+SC4YeFCwurACoXD4u9ByTtwjUEctczSlmIs9AhOhtOWu9t8OcnaxKBbTWINAspAir kbqfbbdoS7JGidtNGCFxVRGVCqdN4K5jt3GEeGn317SsjPnPrs1hEwUD1d/LkZs+OkNvWw9JexD I72ZjsUwLe7DDVdoauzdQSyCnFaJShxRaS8Dn1w2taljzThMaAZr6hinmLqg2G3vz8l/IELqZd1 G/sK1l1xw0K4il/sTVj2AJAih8utNnJmyNIyCXTnJmLPW7bpMBSuGETd2mHncFP6l2MR7zvKECR FrXYNSkyjW4YTUnxRZGtuGBMNjWrigJURH8DNWL8FkSLppFBMZm0+sEE9mtgLDOkrn/7caqmlSh aIzb7MmG/pCrKUWjgON+rfXhRRTKfLhCrHO+VVoDlQpf4TdUF15s6prCIuw34XnXcobKr6o6lZe pFajCq4xFUReVAU8sBO8QwzJDbhhbyY5TF+t2eAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/wXTyktHpXIRKgmBQQsputbbX1Xk Cc: pwe3@ietf.org Subject: [PWE3] AD review of draft-ietf-pwe3-mspw-er X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 21:52:30 -0000 Authors, Thanks for your work on this document. I have conducted my normal AD review having received the publication request. The purpose of the review is to find issues and concerns that improve the quality of the document for readability and implementation, and to remove issues that might otherwise get found during IETF last call, directorate reviews, and IESG evaluation. I think that in general this document is fine, but I think it needs some work on clarity. Hopefully none of my points is contentious, and they can all be handled through some fairly simple edits. of course, every point is open for discussion and you can refute each and every one of them. I'll put the document into "Revised I-D Needed" state and wait to see an update and/or email from you. Thanks, Adrian === On a copyright thing... Are you sure that some of this material hadn't been lifted pretty much unchanged from RFC 3212? You might at least acknowledge that in the Acknowledgements section. --- Section 1 For 1:1 protection of MS-PWs with primary and backup paths, MS-PWs SHOULD be established through a diverse set of S-PEs (Switching Provider-Edge) nodes to avoid any single points of failure at PW level. I think s/SHOULD be/need to be/ The points are: - This is really not a case for RFC 2119 language - "should" is not really good enough for proper 1:1 protection --- Do you not think that the Introduction should discuss a little about how the path might be known? Specifically how the head-end T-PE knows what explicit route to use. It may be enough to say "In many deployments the head-end T-PE will not have a view of the topology of S-PEs and so the explicit route will need to be supplied from a management application. How that management application determines the explicit route is outside the scope of this document." --- Section 1 This draft proposes an additional mechanism Don't say "draft" say "document" because you want this text in an RFC. Don't "propose", "define" or "specify" because you want this in a protocol specification. --- Section 3.1 needs to discuss how uniqueness of "S-PE addresses" is guaranteed/arranged. I suggest you formally define the term "S-PE address" What does "format similar to" actually mean? --- Section 3.1 If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned with an S-PE address, then on receiving a Dynamic MS-PW label mapping message the S-PE MUST return a label release with the "Resources Unavailable" ( 0x00000038)" status code. It is not clear to me whether this is new normative behavior or a restatement of draft-ietf-pwe3-dynamic-ms-pw. This isn't helped by the fact that "Dynamic MS-PW label mapping message" seems to be a new term. You should probably define the term explicitly somehow with reference to what it contains that makes it such a message (not just an ordinary label mapping message) and a reference to draft-ietf-pwe3-dynamic-ms-pw. Then you need to help clarify if this is new behavior. If it is not, then you can include "As described in [ref]..." If it *is* new behavior for an existing message you have to explain how this is backward compatible with current processing of this message. If it is new behavior for a *new* message (i.e. defined in this document) then the text is very out of order and at the least you need some explanation of where this message is defined and what it does. --- Section 3 might usefully say some overview stuff like: - An explicitly routed PW is set up using a Label Mapping message that carries an ordered list of the S-PEs through which the PW is expected to run. - The ordered list is encoded as a series of ER Hop TLVs encoded in a ER TLV that is carried in the Label Mapping message. Doing this would save the reader ploughing through section 3 trying to work out what it is all about. --- If the ER Hop TLV can contain an IP address identifying an abstract node, why is it necessary for each S-PE to have a unique S-PE address formed as an AII? --- Section 3.2 Length Specifies the length of the value field in bytes. There is, of course, no "value" field, so you could be a little clearer. Unfortunately, there is currently a theme in the IESG on multi-byte integer fields that means you need to say how the integer is encoded on the wire, so you need to add "encoded in line format". BUT... Wait a minute. You are re-using 0x0800 for the ER TLV. Good. We don't need to define multiple TLVs for the same function. But why are you writing this document as though you are defining the TLV? Why is there no mention of RFC 3212? The same questions apply to the ER Hop TLV and the two of its types that you are re-using. This wouldn't take a lot of text and would allow you to delete a fair bit. Something along the lines of... The process defined in this document makes use of the ER TLV defined in [RFC3212]. This TLV can be placed in a Label Mapping message used for dynamic PW setup as described in Section 4. The ER TLV contains one or more ER Hop TLVs, each describing a hop along the desired path or the PW. The procedures described in this document allow for the use of the "IPv4 Prefix ER-Hop TLV" and the "IPv6 Prefix ER-Hop TLV" (both defined in [RFC3212]) and also the "L2 PW address of PW Switching Point" defined in this document. --- Curiously, in 3.4.1 you have IP Address A four-byte field indicating the IP Address. while in 3.4.2 you have IPv6 address A 128-bit unicast host addresses. It makes one wonder. This issue would disappear with the fix previously mentioned. --- For both the IPv4 and IPv6 hops, I think you need to think about (and document) whether you support less than fully specified IP addresses. For both of the prefix lengths you appear to allow 1-n (n = 32 or 128) yet for IPv6 you seem to say it is a unicast host address which would preclude anything other than 128. --- 3.4.3 needs some work... The section title says "ER-Hop 3: L2 PW Address" but while this may be the third ER-Hop type you support in this usage, the hop type is actually 5. I suggest you remove the numbers from all three subsection titles. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0802 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value you have used in 0x0805. But (of course) you should use TBD1 and reflect that in the IANA section. |L| Reserved | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Having to fields called "Length" makes the documentation ambiguous. Suggest you make the first one "TLV-Length" | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node. Type A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW Address, Type = 0x0805 Length Specifies the length of the value field in bytes = 18. L Bit Set to indicate Loose hop. Cleared to indicate a strict hop. PreLen Prefix Length 1-96 It is slightly curious that RFC 5003 didn't find a need for indicating the prefix length. Since it is (presumably!) your intention that the count to 96 spans the Global ID, Prefix, and AC ID fields, I think you need to make that clear here and describe its usage later. Otherwise one would rationally assume that the prefix length applies to the prefix field. L2 PW Address An AII Address as defined in [RFC5003]. Rather than say this (which is confusing because there is no such L2 PW Address field) you should say "All other fields (AII Type, Length, Global ID, Prefix, and AC ID) define the L2 PW Address and are to be set and interpreted as defined in Section 3.2 of [RFC5003]." --- 4.1 A PW Label Mapping Message containing an explicit route TLV MUST specify the next hop for a given MS-PW path. What do you mean "MUST"? Surely... A PW Label Mapping Message containing an Explicit Route TLV specifies the next hop for a given MS-PW path. --- 4.1 Selection of this next hop MAY involve a selection from a set of possible alternatives. s/MAY/may/ --- 4.1 The mechanism used to select a particular path is also outside of the scope of this document, but each node MUST attempt to determine a loop-free path. Note that such mechanisms MAY be overridden by local policy. This is ambiguous... "MUST attempt" but if it can't find one it is OK to go ahead with a loop? Local policy may override attempting to find a loop-free path? Local policy may override the mechanism to select a path (which is a local policy on account of not being part of this document)? What information does an S-PE have available to select path and determine whether there is a loop? What should an S-PE do if a path can't be selected without a loop? --- 4.1 1. The node receiving the Label Mapping Message must evaluate the first ER-Hop. This one should be "MUST", but you also need to qualify with "...that contains an ER TLV." --- 4.1 If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. And how will it make that determination? --- 4.1 If there is no first ER-Hop, the message is also in error and the node should return a "Bad Explicit Routing TLV Error" (0x04000001) status code in a Label Release Message sent to upstream node. I presume this means if there is an ER TLV that does not contain an ER Hop TLV. I presume it remains legal to have a Label Mapping message without an ER TLV per point 2 of this section. Perhaps you could clarify this. --- Section 5 This draft proposes one new TLV type: TLV Type Suggested Value Reference ------------------------------------ --------------- --------- L2 PW Address of Switching Point 0x0805 This Document I think this needs to read... IANA is requested to assign a further code point from the IETF Consensus portion of this registry as follows: TLV Type Value Reference ------------------------------------ ------- --------- L2 PW Address of Switching Point TBD1 This Document A value of 0x0805 is requested. From nobody Tue Jun 17 11:30:41 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3951A03C2 for ; Tue, 17 Jun 2014 11:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2ydLtzTJVCz for ; Tue, 17 Jun 2014 11:30:34 -0700 (PDT) Received: from nm1-vm2.bullet.mail.ne1.yahoo.com (nm1-vm2.bullet.mail.ne1.yahoo.com [98.138.91.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4E21A03B8 for ; Tue, 17 Jun 2014 11:30:34 -0700 (PDT) Received: from [98.138.101.129] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jun 2014 18:30:33 -0000 Received: from [98.138.101.169] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jun 2014 18:30:33 -0000 Received: from [127.0.0.1] by omp1080.mail.ne1.yahoo.com with NNFMP; 17 Jun 2014 18:30:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 232202.83388.bm@omp1080.mail.ne1.yahoo.com Received: (qmail 47085 invoked by uid 60001); 17 Jun 2014 18:30:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403029833; bh=6Mae77jYM5zJ9zTz0kbdu3BV48COY1wZWnV4ZZXyOiY=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=wgkKeQw1zbe4xanP2QB4udJ0lLkcyYanSB2pxJ1uEXKtxP6aV7/SQDQeAZ6AIhIkV/gW+lsg8GxVew2yV3mqAhpGNbY7Qa7HZ/9ri7CdWyXPf3XFupwraEKLzWehhPca1oD6UbnoJKLTlXeDNzEysbzQ+VSlkg/2fNAPdNKThS4= X-YMail-OSG: XhbcM1MVM1lAdRUy3bRi967d57FQOxDn3FOfcj7NbdmMPC7 .lo71T82nZUaQiZCUVqm9ewmP4bFTwn.EyURqCoOBGq8Yc_zzaFBtYFJ59IA j_h9ScW.8P4mAqWh3bKFFDmjMJ1rTHPrIHMGmIodroCLR6ZzxqwSO1L0sVX5 ATYFZY1DAAyp8u5kX0odtlyHeeD04KOigP0BYH3hpGusXUqGd8H6I9yFZViG Yv6VSeoPgHdrZwoG7AonjBj6jJaWnDewldJihtBvqHQnKY1YJ8eBwcI64gl2 4TO1h8qfGT11uj76KAa_ncn.OqIkScVfdFgRu4oxCwYM6pOq9M2bjj8S7qBX QQbqj9_.rK06IAw0Ix0OYKe4cbYzzefM.5J_SvXvWmzYCNfy5QAcr.JjX0Lm V8w1X9ey7wxU4rnNu1bccvroxgIOJdBQ7qOkcXrAwRhWoosVV9YzT3AIc7GE lf9EmvXyRE79P4Znw0Z_y4lElW88P0c_IEhJe5yaHcM.N2ZtACHCucRmwE7g J1RH2LVUrSDGwvkxnA_yKlP0HuXHxBMasJpBL0NjuBBmrxDoPAKKf Received: from [50.152.241.56] by web120305.mail.ne1.yahoo.com via HTTP; Tue, 17 Jun 2014 11:30:32 PDT X-Rocket-MIMEInfo: 002.001, SSBhbSBub3QgYXdhcmUgb2YgYW55IGZ1cnRoZXIgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLXB3ZTMtZW5kcG9pbnQtZmFzdC1wcm90ZWN0aW9uLgoKcmFodWwKCgoKRnJvbTpwd2UzIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpClNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDEwOjU0IEFNClRvOiBwd2UzQGlldGYub3JnClN1YmplY3Q6IFtQV0UzXSBJUFIgcG9sbCBhbmQgaW1wbGVtZW50YXRpb24gY2hlY2sgZm9yIGQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.190.668 References: Message-ID: <1403029832.99325.YahooMailNeo@web120305.mail.ne1.yahoo.com> Date: Tue, 17 Jun 2014 11:30:32 -0700 From: Rahul Aggarwal To: Yimin Shen , "pwe3@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1278015569-1308944510-1403029832=:99325" Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/nYKsQ3XalCKaUkx3_TqV-Bw-rXY Subject: Re: [PWE3] IPR poll and implementation check for draft-ietf-pwe3-endpoint-fast-protection-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Rahul Aggarwal List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 18:30:39 -0000 ---1278015569-1308944510-1403029832=:99325 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am not aware of any further IPR that applies to draft-ietf-pwe3-endpoint-= fast-protection.=0A=0Arahul=0A=0A=0A=0AFrom:pwe3 [mailto:pwe3-bounces@ietf.= org] On Behalf Of Bocci, Matthew (Matthew)=0ASent: Friday, May 09, 2014 10:= 54 AM=0ATo: pwe3@ietf.org=0ASubject: [PWE3] IPR poll and implementation che= ck for draft-ietf-pwe3-endpoint-fast-protection-00=0A=A0=0AThis is an IPR a= nd implementation poll for http://tools.ietf.org/html/draft-ietf-pwe3-endpo= int-fast-protection-00, which is=A0=0Acurrently in WG last call.=0A=A0=0AAr= e you aware of any further IPR that applies to draft-ietf-pwe3-endpoint-fas= t-protection?=0A=A0=0AIf so, has this IPR been disclosed in compliance with= IETF IPR rules=0A(see RFCs 3979, 4879, 3669 and 5378 for more details)? No= te that there=0Aare currently two IPR disclosures in the IETF datatracker.= =0A=A0=0AIf you are listed as a document author or contributor please respo= nd=0Ato this email regardless of whether or not you are aware of any=0Arele= vant IPR. The response needs to be sent to the PWE3 WG mailing=0Alist. The = document will not advance to the next stage until a response=0Ahas been rec= eived from each author and each contributor.=0A=A0=0AIf you are on the PWE3= WG email list but are not listed as an author=0Aor contributor, then pleas= e explicitly respond only if you are aware=0Aof any IPR that has not yet be= en disclosed in conformance with IETF=0ARules.=0A=A0=0AIn addition, the IES= G routinely asks for implementation information on=0Aa draft it is reviewin= g for publication. If you are aware of any=0Aimplementations of this draft = (yours or others), please let me know.=0AYou may respond to the list, or ju= st to me if you prefer. If you wish=0Afor any information to remain confide= ntial, let me know and I'll=0Aanonymize it in the document's IESG writeup.= =0A=A0=0A=A0=0AMatthew and Andy ---1278015569-1308944510-1403029832=:99325 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I am not aware of any= further IPR that applies to draft-ietf-p= we3-endpoint-fast-protection.

rahul


=0A
=0A
From: pwe3 [mailto:pwe3-bounces@ietf.org]=0AOn Behalf Of Bo= cci, Matthew (Matthew)
=0ASent: Friday, May 09, 20= 14 10:54 AM
=0ATo: pwe3@ietf.org
=0ASubject: [PWE3] IPR= poll and implementation check for draft-ietf-pwe3-endpoint-fast-protection= -00
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
This is an IPR and implementation po= ll for=0A=0Ahttp:= //tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-00, whic= h is 
=0A
=0A
=0A
currently in WG last call.<= /div> =0A
=0A
=0A
 
=0A
=0A
=0A
=0AAre y= ou aware of any further IPR that applies to draft-ietf-pwe3-endpoint-fast-p= rotection?
=0A
=0A
=0A
 
=0A
=0A<= div>=0A
If so, has this IPR been disclosed in compliance with IETF IPR rules
=0A
=0A
=0A
(see RFCs 3979, 4879, 3669 and 5378 for more de= tails)? Note that there
=0A
=0A
=0A
are currently two IPR= disclosures in the IETF datatracker.
=0A
=0A
=0A  =
=0A
=0A
=0A
If you are listed as a document author or co= ntributor please respond
=0A
=0A
=0A
to this email regard= less of whether or not you are aware of any
=0A
=0A
= =0A
= relevant IPR. The response needs to be sent to the PWE3 WG mailing =0A
=0A
=0A
list. The document will not advance to the next stag= e until a response
=0A
=0A
=0A
has been received from eac= h author and each contributor.
=0A
=0A
=0A
 
=0A
=0A
=0A
If you are on the PWE3 WG email list but are not l= isted as an author
=0A
=0A
=0A
or contributor, then pleas= e explicitly respond only if you are aware
=0A
=0A
= =0A
= of any IPR that has not yet been disclosed in conformance with IETF<= /div> =0A
=0A
=0A
Rules.
=0A
=0A
=0A
=0A  = ;
=0A
=0A
=0A
=0A
In addition, the IESG routinely ask= s for implementation information on
=0A
=0A
=0A
a draft i= t is reviewing for publication. If you are aware of any
=0A=0A
=0A
implementations of this draft (yours or others), please let me k= now.
=0A
=0A
=0A
You may respond to the list, or just to = me if you prefer. If you wish
=0A
=0A
=0A
for any infor= mation to remain confidential, let me know and I'll
=0A
= =0A
=0A
anonymize it in the document's IESG writeup.
=0A
= =0A
=0A
=0A
 
=0A
=0A
=0A
 
= =0A
=0A
=0A
Matthew and Andy
=0A
=0A
=0A=


---1278015569-1308944510-1403029832=:99325-- From nobody Tue Jun 17 16:28:14 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A156E1A00A3; Tue, 17 Jun 2014 16:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xSjNTok9mC3; Tue, 17 Jun 2014 16:28:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 62D7C1A00C3; Tue, 17 Jun 2014 16:28:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4697B180479; Tue, 17 Jun 2014 16:26:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140617232647.4697B180479@rfc-editor.org> Date: Tue, 17 Jun 2014 16:26:47 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/T9Gg1oif7PseMl_Rl7GHlAESh4k Cc: drafts-update-ref@iana.org, pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 7267 on Dynamic Placement of Multi-Segment Pseudowires X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 23:28:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7267 Title: Dynamic Placement of Multi-Segment Pseudowires Author: L. Martini, Ed., M. Bocci, Ed., F. Balus, Ed. Status: Standards Track Stream: IETF Date: June 2014 Mailbox: lmartini@cisco.com, matthew.bocci@alcatel-lucent.com, florin@nuagenetworks.net Pages: 24 Characters: 49414 Updates: RFC 6073 I-D Tag: draft-ietf-pwe3-dynamic-ms-pw-22.txt URL: http://www.rfc-editor.org/rfc/rfc7267.txt RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14. This document is a product of the Pseudowire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jun 20 11:01:23 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA4D1B289A; Fri, 20 Jun 2014 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpw3kChOjn2X; Fri, 20 Jun 2014 11:01:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3211B288C; Fri, 20 Jun 2014 11:01:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620180116.14622.30330.idtracker@ietfa.amsl.com> Date: Fri, 20 Jun 2014 11:01:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/o11lTg-IlluQZGVeMmj0LOvFKrg Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-10.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:01:17 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks Author(s) : F. JOUNAY, et al Filename : draft-ietf-pwe3-p2mp-pw-requirements Pages : 17 Date : 2014-06-20 This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point- to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, Point-to-Multipoint PWs can be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service). A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-requirements-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-p2mp-pw-requirements"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-06-20110116.I-D@ietf.org> --NextPart-- From nobody Fri Jun 20 11:01:25 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FA01B288C; Fri, 20 Jun 2014 11:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIHagNseuqj3; Fri, 20 Jun 2014 11:01:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1127B1B2892; Fri, 20 Jun 2014 11:01:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620180117.18305.72455.idtracker@ietfa.amsl.com> Date: Fri, 20 Jun 2014 11:01:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/nZ16llEyUcfKSSqLzuz0ghqb-nQ Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-10.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:01:19 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks Author(s) : F. JOUNAY, et al Filename : draft-ietf-pwe3-p2mp-pw-requirements Pages : 17 Date : 2014-06-20 This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point- to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, Point-to-Multipoint PWs can be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service). A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-requirements-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-p2mp-pw-requirements"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-06-20110117.I-D@ietf.org> --NextPart-- From nobody Mon Jun 23 07:05:47 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28891B2B0D; Mon, 23 Jun 2014 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa83QqpDPwRE; Mon, 23 Jun 2014 07:05:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE271B2B18; Mon, 23 Jun 2014 07:05:39 -0700 (PDT) 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: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623140539.24964.97737.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 07:05:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/4RTBrAK8SfsIfm--TnwHoE8uR4c Cc: pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Document Action: 'Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks' to Informational RFC (draft-ietf-pwe3-p2mp-pw-requirements-10.txt) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:05:43 -0000 The IESG has approved the following document: - 'Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks' (draft-ietf-pwe3-p2mp-pw-requirements-10.txt) as Informational RFC This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-p2mp-pw-requirements/ Technical Summary This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point- to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, Point-to-Multipoint PWs can be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service) as defined in the Layer 2 Virtual Private Network Working Group. Working Group Summary This draft has taken a while as it required extensive rewriting by a new editor following the previous time it was submitted to the IESG. This added quite a bit of time to the process, but has greatly improved the quality of the draft. There was a bit of controversy regarding a late IPR declaration. The result was the removal of an optional feature believed to be the sole material covered by the IPD disclosure. The IPR holder has been approached to ask whether they will consider updating the disclosure but no response has been received yet. Document Quality As this is a requirements and framework draft, there can be no implementations. Solutions work is building on these requirements. Stewart Bryant deserves special mention as the AD that resulted in the document largely being re-written, which improved its quality. Personnel Andy Malis is the Document Shepherd Adrian Farrel is the Responsible AD. RFC Editor Note Section 5 OLD: The solution SHOULD provide means to guarantee the traffic delivery to receivers (Integrity, Confidentially) NEW: The solution SHOULD provide means to protect the traffic delivered to receivers (Integrity, Confidentially, Endpoint Authentication) From nobody Mon Jun 23 10:29:40 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06321B2B96 for ; Mon, 23 Jun 2014 10:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYgOCccQiVlL for ; Mon, 23 Jun 2014 10:29:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27721B2B8B for ; Mon, 23 Jun 2014 10:29:35 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-7f-53a8128745a7 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9E.C5.27529.A8218A35; Mon, 23 Jun 2014 13:42:02 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Mon, 23 Jun 2014 13:29:24 -0400 From: David Sinicrope To: IETF.PWE3 Thread-Topic: PWE3 IETF 90 Slot Requests - Toronto Thread-Index: AQHPjwisBf9If8jL+EmGOsjvGLJRhQ== Date: Mon, 23 Jun 2014 17:29:24 +0000 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.3.1.130117 x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_CFCDBFBC13B551davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPoG6X0IpggxP/lS36Pm1hcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtOGyawF06Qr1k+ZxtTAeFu8i5GTQ0LARGL3gkY2CFtM4sK9 9WC2kMBRRonW6ZxdjFxA9nJGiekNK5hAEmxADes27mEBsUUEZCVeX78H1iAsoCtxcdt5Roi4 kcTenYdYIWw9iZsX5zKD2CwCqhLPn05gB7F5Bawkjs99CFbDKWAt8WbdUzCbEeiI76fWgO1i FhCXuPVkPhPEcQISS/acZ4awRSVePv4HVi8KNH99+26oGiWJSUvPsUL0xkuc3TCRBWKXoMTJ mU9YJjCKzEIydhaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858Biq11piYst5FmQ1Cxg5VjFy lBanluWmGxlsYgRG0DEJNt0djHteWh5iFOBgVOLhXSC5PFiINbGsuDL3EKM0B4uSOO+s2nnB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhiVun6KVZeLbLgiZan7MbwrY71HUqJnq9PzcAft fiGdzFWOHlZz5dPUZ/s5hPzhcTr+4cASz60CDxLPBotO0ks4+l+qMJkxoa5qevrD01n1S3Tc 6t9FawcIJMjf8csSvizZpCrxb2H0Y4Hddx3lZp1/E9ccqzF3VcEr5yudSQ8zg7JPzbv8UIml OCPRUIu5qDgRAIFS/QGBAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/pa-IArIiUDO0szGbbjn6qKOT9ZQ Subject: [PWE3] PWE3 IETF 90 Slot Requests - Toronto X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:29:38 -0000 --_000_CFCDBFBC13B551davidsinicropeericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, It's that time again. If you need a presentation slot for the IETF 90 PWE3 session, please reply = to this email (subject intact) completing the form below: - topic (e.g., MPLS and Ethernet OAM Interworking): - draft URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth= -oam-iwk/): - brief statement of objectives and issues that need to be discussed and re= solved via the presentation during the meeting (e.g., need to address secu= rity issues and get direction from the WG): - requested duration (norm is 10 min): - speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave --_000_CFCDBFBC13B551davidsinicropeericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7EAA5743CDD49E4C9E6C208F11DE8CB1@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi All,
MPLS and Ethernet OAM Interworking):
- brief statement of objectives and issues that need to be discussed a= nd resolved via the presentation during the meeting  (e.g., need to ad= dress security issues and get direction from the WG):  
- requested duration (norm is 10 min):  
- speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE):  
Date: Sun, 29 Jun 2014 23:44:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/eEvRyTu-T6oACK7Wo8-m3cjwFZQ Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-mpls-tp-oam-config-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 06:44:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire Authors : Fei Zhang Bo Wu Elisa Bellagamba Mach(Guoyi) Chen Filename : draft-ietf-pwe3-mpls-tp-oam-config-01.txt Pages : 23 Date : 2014-06-29 Abstract: This document specifies extensions to the Label Distribution Protocol (LDP) to configure and control proactive Operations, Administration and Maintenance (OAM) functions, which are suitable for dynamic Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS- PW). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-oam-config/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-oam-config-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pwe3-mpls-tp-oam-config-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/