From pwe3-bounces@ietf.org Tue Jan 02 17:19:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ry1-00021i-UU; Tue, 02 Jan 2007 17:18:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rxy-0001vL-7L; Tue, 02 Jan 2007 17:18:42 -0500 Received: from out001.atlarge.net ([129.41.63.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rxt-0004oX-W9; Tue, 02 Jan 2007 17:18:42 -0500 Received: from nemertes-01-ex.atlarge.net ([10.100.50.167]) by out001.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 16:16:51 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Jan 2007 16:18:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FutureNet 2007 Call For Presentations Thread-Index: AccukSytZr2ld2u9RvuHPF7uXbxFTwAA4FRQAAkWooAAAF48cA== From: "Irwin Lazar" To: , , , , X-OriginalArrivalTime: 02 Jan 2007 22:16:51.0794 (UTC) FILETIME=[B40E3320:01C72EBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mpls-ops@mplsrc.com Subject: [PWE3] FutureNet 2007 Call For Presentations X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Greetings, The "Call for Presentations" for "FutureNet 2007: MPLS, VPLS and Beyond" is now available at http://www.futurenetexpo.com/speaker/submit_pres.html FutureNet will be held at the Grand Hyatt Hotel on April 30 - May 3, 2007 in New York City. FutureNet represents the evolution of MPLScon, which for the last six years has been the premier industry conference focusing on MPLS, VPN and WAN technologies from both enterprise and service provider perspectives. =20 With this year's event we'll expand our focus to cover next generation network technologies including emerging Ethernet services, fixed/mobile convergence, rich-media service delivery, optical networking and more. As has been the tradition from past events, FutureNet will focus on end-user case studies from both enterprises and service providers providing real-world insight into challenges and lessons learned. =20 We invite you to review the Call For Presentations and submit an abstract. Please note that abstracts are due by February 2nd, 2007. Please feel free to contact me with any questions. My contact information is below. =20 Sincerely, Irwin Lazar Conference Director, FutureNet: MPLS, VPLS, and Beyond (Formerly MPLScon) http://www.futurenetexpo.com/ irwin.lazar@nemertes.com 703-468-4361 AIM/Google/Yahoo/Skype: imlazar =20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 03 21:33:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2IPJ-0002Tt-UO; Wed, 03 Jan 2007 21:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2IPJ-0002Te-5o for pwe3@ietf.org; Wed, 03 Jan 2007 21:32:41 -0500 Received: from mail.zte.ro ([202.103.147.155] helo=mx4.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2IP0-0001f0-Bi for pwe3@ietf.org; Wed, 03 Jan 2007 21:32:41 -0500 Received: from [10.30.1.239] by 10.30.1.243 with StormMail ESMTP id 91354.1397396305; Thu, 4 Jan 2007 10:33:34 +0800 (CST) To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: jin.lizhong@zte.com.cn Date: Thu, 4 Jan 2007 10:31:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2007-01-04 10:31:15, Serialize complete at 2007-01-04 10:31:15 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: hu.kan@zte.com.cn Subject: [PWE3] A case in VPLS using MS-PW X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0603171695==" Errors-To: pwe3-bounces@ietf.org This is a multipart message in MIME format. --===============0603171695== Content-Type: multipart/alternative; boundary="=_alternative 000DCD9748257259_=" This is a multipart message in MIME format. --=_alternative 000DCD9748257259_= Content-Type: text/plain; charset="US-ASCII" Hi, all We meet a question when implementing VPLS using MS-PW, pls see the following figure. CE1---T-PE1----------S-PE----------T-PE2---CE2 | CE3 Configure a static multi-segment Pseudo Wire between T-PE1 and T-PE2, consisted by S-PW1 and S-PW2. If S-PE is also a T-PE and need to setup a PW between S-PE and T-PE2, named PW3. CE1, CE2 and CE3 are in the same VPLS. Then what's the relationship between S-PW2 and PW3 ? There are two cases: 1. S-PW2 and PW3 are independent PWs, then the path from CE1 to CE3 is T-PE1->S-PE->T-PE2->S-PE. It is not the best path. And if PWs belonging to the same VPLS need same PWID. Then to identify them individually, PW need to implement certain extension, for PW identification cannot be based-upon Source+Destination+Pwid mechnism. 2. S-PW2 and PW3 are the same PW, then Multi-segment PW is not needed, hub & spoke PWs are setup between T-PE1, S-PE and T-PE2. This case can solve this problem. Which cases do you guys prefer? .............................................. Add: No.68 Zijinghua Rd,Yuhuatai District, Nanjing. P.R.China. Zip: 210012 Tel: 0086-25-52871645 Mail: jin.lizhong@zte.com.cn .............................................. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000DCD9748257259_= Content-Type: text/html; charset="US-ASCII"
Hi, all

We meet a question when implementing VPLS using MS-PW, pls see the following figure.

CE1---T-PE1----------S-PE----------T-PE2---CE2
                      |
                     CE3

Configure a static multi-segment Pseudo Wire between T-PE1 and T-PE2, consisted by S-PW1 and S-PW2. If S-PE is also a T-PE and need to setup a PW between S-PE and T-PE2, named PW3. CE1, CE2 and CE3 are in the same VPLS.

Then what's the relationship between S-PW2 and PW3 ?

There are two cases:
1. S-PW2 and PW3 are independent PWs, then the path from CE1 to CE3 is T-PE1->S-PE->T-PE2->S-PE. It is not the best path. And if PWs belonging to the same VPLS need same PWID. Then to identify them individually, PW need to implement certain extension, for PW identification cannot be based-upon Source+Destination+Pwid mechnism.
2. S-PW2 and PW3 are the same PW, then Multi-segment PW is not needed, hub & spoke PWs are setup between T-PE1, S-PE and T-PE2. This case can solve this problem.

Which cases do you guys prefer?


..............................................
Add:   No.68 Zijinghua Rd,Yuhuatai District,
      Nanjing. P.R.China.
Zip:   210012
Tel:   0086-25-52871645
Mail:  jin.lizhong@zte.com.cn
.............................................. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000DCD9748257259_=-- --===============0603171695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0603171695==-- From pwe3-bounces@ietf.org Thu Jan 04 07:39:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Rrj-0006SB-3M; Thu, 04 Jan 2007 07:38:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Rrg-0006S1-Qv for pwe3@ietf.org; Thu, 04 Jan 2007 07:38:36 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Rrf-0003HD-F8 for pwe3@ietf.org; Thu, 04 Jan 2007 07:38:36 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l04CcXYX015626 for ; Thu, 4 Jan 2007 06:38:35 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 06:38:19 -0600 Received: from INEXC1U02.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 18:08:15 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Jan 2007 18:08:13 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Inband/out-of-band TDM OAM format for MPLS PSNs Thread-Index: Accv/TMCIX7yHBJiSpWvhrD8HQ5IVA== From: "Ahluwalia, Ajit \(Ajit\)" To: X-OriginalArrivalTime: 04 Jan 2007 12:38:15.0652 (UTC) FILETIME=[3472D240:01C72FFD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [PWE3] Inband/out-of-band TDM OAM format for MPLS PSNs X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi, 1. Could anyone describe the format of inband TDM OAM format for MPLS PSNs, section D.2 of draft-ietf-pwe3-tdmoip-06 just mentions first nibble being 0001. 2. draft-ietf-pwe3-tdmoip-06.txt talks about out-of-band OAM format where forward/reverse PW labels are 16 bit each, appropriate for UDP/IP PSNs but how would this work for MPLS PSNs where more bits are required. Thanks Ajit _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 04 12:17:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WCe-00054p-1i; Thu, 04 Jan 2007 12:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WCc-00054k-Cx for pwe3@ietf.org; Thu, 04 Jan 2007 12:16:30 -0500 Received: from mx2-012.rad.co.il ([212.199.240.16] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WCZ-0003BT-PR for pwe3@ietf.org; Thu, 04 Jan 2007 12:16:30 -0500 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 04 Jan 2007 19:16:21 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] Inband/out-of-band TDM OAM format for MPLS PSNs Date: Thu, 4 Jan 2007 19:11:39 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D2C9A38@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Inband/out-of-band TDM OAM format for MPLS PSNs Thread-Index: Accv/TMCIX7yHBJiSpWvhrD8HQ5IVAAJjK2i References: From: "Yaakov Stein" To: "Ahluwalia, Ajit \(Ajit\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0783352518==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0783352518== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73024.0D2DC8CB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73024.0D2DC8CB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ajit =20 The inband format relies on VCCV, which is the reason the CW is the = PWACH one rather than the user traffic CW. VCCV based on BFD could be used for = most of the functionality, but indeed it would be better to have a full-functioned = OAM here (for example, a Y.1731 format one). =20 The out-of-band OAM format is presently limited to the UDP/IP case. There is no intent to extend it to the MPLS case, unless extending the VCCV-based approach proves impossible. Incidentally, I admit that there are advantages to the out-of-band approach for MPLS where there may be many PWs in a single MPLS tunnel -=20 but that is not the direction the WG wanted us to go. =20 Y(J)S =20 ________________________________ From: Ahluwalia, Ajit (Ajit) [mailto:ajitahlu@alcatel-lucent.com] Sent: Thu 04/01/2007 14:38 To: pwe3@ietf.org Subject: [PWE3] Inband/out-of-band TDM OAM format for MPLS PSNs Hi, 1. Could anyone describe the format of inband TDM OAM format for MPLS PSNs, section D.2 of draft-ietf-pwe3-tdmoip-06 just mentions first nibble being 0001. 2. draft-ietf-pwe3-tdmoip-06.txt talks about out-of-band OAM format where forward/reverse PW labels are 16 bit each, appropriate for UDP/IP PSNs but how would this work for MPLS PSNs where more bits are required. Thanks Ajit _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C73024.0D2DC8CB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [PWE3] Inband/out-of-band TDM OAM format = for MPLS PSNs=0A= =0A= =0A= =0A=
=0A=
Ajit
=0A=
 
=0A=
The inband format relies on = VCCV, which is the reason the CW is the PWACH one
=0A=
rather than the user traffic = CW. VCCV based on BFD could be used for most of the
=0A=
functionality, but indeed it = would be better to have a full-functioned OAM here
=0A=
(for example, a Y.1731 format = one).
=0A=
 
=0A=
The out-of-band OAM format is = presently limited to the UDP/IP case.
=0A=
There is no intent to extend = it to the MPLS case, unless extending
=0A=
the VCCV-based approach proves impossible. Incidentally, I = admit
=0A=
that there are advantages to = the out-of-band approach for MPLS
=0A=
where there may be many PWs = in a single MPLS tunnel -
=0A=
but that is not the direction = the WG wanted us to go.
=0A=
 
=0A=
Y(J)S
=0A=
 
=0A=

=0A=
=0A= From: Ahluwalia, Ajit (Ajit) = [mailto:ajitahlu@alcatel-lucent.com]
Sent: Thu 04/01/2007 = 14:38
To: pwe3@ietf.org
Subject: [PWE3] = Inband/out-of-band TDM OAM format for MPLS PSNs

=0A=
=0A=

Hi,
1. Could anyone describe the format of inband = TDM OAM format for MPLS
PSNs, section D.2 of = draft-ietf-pwe3-tdmoip-06 just mentions first
nibble being = 0001.
2. draft-ietf-pwe3-tdmoip-06.txt talks about out-of-band OAM = format
where forward/reverse PW labels are 16 bit each, appropriate = for UDP/IP
PSNs but how would this work for MPLS PSNs where more bits = are = required.

Thanks
Ajit

__________________________________= _____________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.or= g/mailman/listinfo/pwe3

------_=_NextPart_001_01C73024.0D2DC8CB-- --===============0783352518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0783352518==-- From pwe3-bounces@ietf.org Thu Jan 04 15:50:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXL-0002Bc-DL; Thu, 04 Jan 2007 15:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXH-00028k-Fa; Thu, 04 Jan 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ZXG-0003ly-Fd; Thu, 04 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 666E2328A9; Thu, 4 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2ZXG-0000eW-8h; Thu, 04 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-12.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --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 : Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-vccv-12.txt Pages : 26 Date : 2007-1-4 This document describes Virtual Circuit Connection Verification (VCCV) which provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-vccv-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-vccv-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-4143117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-vccv-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-vccv-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-4143117.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Tue Jan 09 13:43:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Lvf-0007eA-RX; Tue, 09 Jan 2007 13:42:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Lve-0007dk-Az for pwe3@ietf.org; Tue, 09 Jan 2007 13:42:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Lvd-0003d6-1X for pwe3@ietf.org; Tue, 09 Jan 2007 13:42:34 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jan 2007 19:42:33 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l09IgWAY025603; Tue, 9 Jan 2007 19:42:32 +0100 Received: from [64.103.65.227] (dhcp-gpk02-vlan300-64-103-65-227.cisco.com [64.103.65.227]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l09IgOdB012734; Tue, 9 Jan 2007 19:42:24 +0100 (MET) Message-ID: <45A3E20F.2060004@cisco.com> Date: Tue, 09 Jan 2007 18:42:23 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=435; t=1168368152; x=1169232152; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20PWE3=20Congestion |Sender:=20; bh=vsnX8zFVfpWGljv1kvlueo/ucIEDpTe7/eo6s7V+z/8=; b=OqiDMJfCr3hKlanrgjTivwFRys/2rau/l+TVZiC9HWvTy0RvOl3Z2pF/u35DfNk1OjAg/SEf dDjyTQhJpuD7PyRzEMMXs+L8VGNtHry1R+siqnU9dOiYgVtEFsnyIxHj; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Lars Eggert , Mark Townsley , Danny McPherson Subject: [PWE3] PWE3 Congestion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The PWE3 WG needs to form a consensus on whether to adopt http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt as a working group item. For my part I think congestion is a topic that, for the good of the Internet, we as a WG have a responsibility to address. So I put the question to the PWE3 WG: Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt as a working group draft? - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jan 09 13:53:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4M6L-0004L9-Gs; Tue, 09 Jan 2007 13:53:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4M6K-0004L3-PA for pwe3@ietf.org; Tue, 09 Jan 2007 13:53:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4M6J-0005EZ-HK for pwe3@ietf.org; Tue, 09 Jan 2007 13:53:36 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2007 13:53:35 -0500 X-IronPort-AV: i="4.13,164,1167627600"; d="scan'208"; a="111190027:sNHT44433836" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l09IrZDL016725; Tue, 9 Jan 2007 13:53:35 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l09IrY7f018453; Tue, 9 Jan 2007 13:53:34 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 13:53:34 -0500 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 13:53:34 -0500 Message-ID: <45A3E4AD.90609@cisco.com> Date: Tue, 09 Jan 2007 19:53:33 +0100 From: Mark Townsley User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Stewart Bryant References: <45A3E20F.2060004@cisco.com> In-Reply-To: <45A3E20F.2060004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2007 18:53:34.0264 (UTC) FILETIME=[76A71380:01C7341F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=568; t=1168368815; x=1169232815; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20PWE3=20Congestion |Sender:=20 |To:=20Stewart=20Bryant=20; bh=iUuCToEQl4tUM/CI6eVSESsVzaB2oa+Y61RY9dXgiA4=; b=zWUfrXExPzpNGQWjptQDRBZ3ZWwRDLyAXfdvxYv5a8pSZ4GQOb/wfx0rSYzyuK+Ohuysugp7 x2TtLxgEVV+M427o1qfrDDE96DN6cZTijBojVje0RrpLlmpYnPT63laj; Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Lars Eggert , pwe3 , Danny McPherson Subject: [PWE3] Re: PWE3 Congestion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart Bryant wrote: > > The PWE3 WG needs to form a consensus on whether to adopt > > http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt > > as a working group item. > > For my part I think congestion is a topic that, for the > good of the Internet, we as a WG have a responsibility > to address. And I'm certain the transport community agrees with you, Stewart. - Mark > > So I put the question to the PWE3 WG: > > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? > > - Stewart > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jan 09 14:02:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MEj-00070a-PM; Tue, 09 Jan 2007 14:02:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MEi-00070U-T0 for pwe3@ietf.org; Tue, 09 Jan 2007 14:02:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4MEf-0006oN-GV for pwe3@ietf.org; Tue, 09 Jan 2007 14:02:16 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Jan 2007 11:02:13 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l09J2CJu019028; Tue, 9 Jan 2007 11:02:12 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l09J1mJB025993; Tue, 9 Jan 2007 11:02:11 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 14:01:48 -0500 Received: from [161.44.71.236] ([161.44.71.236]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 14:01:48 -0500 In-Reply-To: <45A3E20F.2060004@cisco.com> References: <45A3E20F.2060004@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <66DACD1E-5300-46CD-8BB9-7964C4A6B0DC@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] PWE3 Congestion Date: Tue, 9 Jan 2007 14:01:46 -0500 To: Stewart Bryant X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Jan 2007 19:01:48.0047 (UTC) FILETIME=[9CF861F0:01C73420] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=699; t=1168369332; x=1169233332; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20PWE3=20Congestion |Sender:=20; bh=insHVdlqlobL7Tzh4iskwes+Rv6gOp4WKl6FB3Hs7ks=; b=pNVG1/gJwjiDGdZGQHvRyY+R9cwleTmIJncx61+AqLzQIR+ZcI4xPIuYd3s7zIw5bJdjthXA 9aeNdcDBt9PFNW1HZzFUiSafdbmr9UXMcX1WEzpJ37uQ6Cdey08hLU1U; Authentication-Results: sj-dkim-5; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Lars Eggert , Mark Townsley , pwe3 , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I think this is a great topic for the WG to pursue, at least investigate. --Tom > > The PWE3 WG needs to form a consensus on whether to adopt > > http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt > > as a working group item. > > For my part I think congestion is a topic that, for the > good of the Internet, we as a WG have a responsibility > to address. > > So I put the question to the PWE3 WG: > > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? > > - Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 10 02:44:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Y7P-0005xI-G0; Wed, 10 Jan 2007 02:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Y7O-0005vX-5V for pwe3@ietf.org; Wed, 10 Jan 2007 02:43:30 -0500 Received: from mx2-n.rad.co.il ([62.0.23.221] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Y7M-00052M-Nh for pwe3@ietf.org; Wed, 10 Jan 2007 02:43:30 -0500 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 10 Jan 2007 09:43:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] PWE3 Congestion Date: Wed, 10 Jan 2007 09:43:12 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D02E9FA83@exrad3.ad.rad.co.il> In-Reply-To: <45A3E20F.2060004@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] PWE3 Congestion Thread-Index: Acc0Hke+GwYtr4CRS2CXuPcI6RnDYQAbJjFA From: "Yaakov Stein" To: "pwe3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt as a working group draft? [YJS] Absolutely. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 10 06:17:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bRV-0004LG-QJ; Wed, 10 Jan 2007 06:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bRU-0004JU-Iz for pwe3@ietf.org; Wed, 10 Jan 2007 06:16:28 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4bRT-0005Os-BD for pwe3@ietf.org; Wed, 10 Jan 2007 06:16:28 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1168427784!14344384!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 3585 invoked from network); 10 Jan 2007 11:16:24 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-121.messagelabs.com with SMTP; 10 Jan 2007 11:16:24 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0ABGOvq010979; Wed, 10 Jan 2007 06:16:24 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0ABGIJv010935; Wed, 10 Jan 2007 06:16:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] PWE3 Congestion Date: Wed, 10 Jan 2007 05:16:18 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC80C6@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D02E9FA83@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] PWE3 Congestion Thread-Index: Acc0Hke+GwYtr4CRS2CXuPcI6RnDYQAbJjFAAAdpt5A= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Stewart Bryant" , "pwe3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? Yes. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 10 10:37:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fUY-0001Pu-QR; Wed, 10 Jan 2007 10:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fUX-0001Pd-9d for pwe3@ietf.org; Wed, 10 Jan 2007 10:35:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4fUS-0008D4-V6 for pwe3@ietf.org; Wed, 10 Jan 2007 10:35:53 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2007 16:35:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0AFZmIW013973; Wed, 10 Jan 2007 16:35:48 +0100 Received: from [64.103.65.227] (dhcp-gpk02-vlan300-64-103-65-227.cisco.com [64.103.65.227]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0AFZmdB018593; Wed, 10 Jan 2007 16:35:48 +0100 (MET) Message-ID: <45A507D4.6060501@cisco.com> Date: Wed, 10 Jan 2007 15:35:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: magnus.westerlund@ericsson.com, lars.eggert@nokia.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=294; t=1168443348; x=1169307348; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Transport=20Area=20review=20request=20-=20draft-ietf-pwe3-fc- encap-02.txt |Sender:=20; bh=5hwr13TP5b49OmvoM+sj3fg6VqT50465Not7ww6AcmY=; b=RIt4IXc74R0GxdhTj69QWaivH5LhxftA6Kn/PKr/FHeWcgc0cabRDWSRtijwDQEk0LrZX6U7 Max5ZTim0xvfV9rwyDWavgUbsQe8k4R1xFw1bax4jI8sSH2DSKKkIWvZ; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: pwe3 Subject: [PWE3] Transport Area review request - draft-ietf-pwe3-fc-encap-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Please can the IETF PWE3 formally ask for a Transport Area review of our Fiber Channel draft. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-02.txt We would request that feedback be available for us to resolve any issues at or before the next IETF. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 10 11:18:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4g8y-0008OP-Hi; Wed, 10 Jan 2007 11:17:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4g8w-0008O1-8U for pwe3@ietf.org; Wed, 10 Jan 2007 11:17:38 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4g8s-0006NL-SW for pwe3@ietf.org; Wed, 10 Jan 2007 11:17:38 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 16:17:33 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Jan 2007 16:17:32 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1168445850819; Wed, 10 Jan 2007 16:17:30 +0000 Received: from mut.jungle.bt.co.uk ([10.215.131.59]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l0AGHSac029307; Wed, 10 Jan 2007 16:17:30 GMT Message-Id: <5.2.1.1.2.20070110161706.04901868@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 10 Jan 2007 16:17:31 +0000 To: Stewart Bryant From: Bob Briscoe Subject: Re: [PWE3] PWE3 Congestion In-Reply-To: <45A3E20F.2060004@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Jan 2007 16:17:32.0266 (UTC) FILETIME=[D4E14CA0:01C734D2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Lars Eggert , Mark Townsley , pwe3 , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, At 18:42 09/01/2007, Stewart Bryant wrote: >Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt >as a working group draft? Yup Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 10 12:54:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4he0-0005da-1X; Wed, 10 Jan 2007 12:53:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hdy-0005bC-T7 for pwe3@ietf.org; Wed, 10 Jan 2007 12:53:46 -0500 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hdn-0001Fw-MD for pwe3@ietf.org; Wed, 10 Jan 2007 12:53:46 -0500 Received: by nz-out-0506.google.com with SMTP id z6so152959nzd for ; Wed, 10 Jan 2007 09:53:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=oXGlkh//xc+2R9PFntSsBDLfc8uT08neK7Ja+UkWG+nOPYdiP6WhUhXQQaCfa7dvLQ7ryZSrB4ohGA+3d/eeMHd8IuuflbyuQF25Z23q/Swc9NmE7JZoJsOa+/Djc2OD8enBCPR1CdmQ4zEBK+1R5/VYvhRl3wt5DwAHITS1jvs= Received: by 10.65.100.14 with SMTP id c14mr824918qbm.1168451614715; Wed, 10 Jan 2007 09:53:34 -0800 (PST) Received: by 10.65.236.15 with HTTP; Wed, 10 Jan 2007 09:53:34 -0800 (PST) Message-ID: <60f30b010701100953q236a0e87wc6f595ce4ef45fd6@mail.gmail.com> Date: Wed, 10 Jan 2007 12:53:34 -0500 From: "Craig White" To: "Stewart Bryant" Subject: Re: [PWE3] PWE3 Congestion In-Reply-To: <45A3E20F.2060004@cisco.com> MIME-Version: 1.0 References: <45A3E20F.2060004@cisco.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Lars Eggert , Mark Townsley , pwe3 , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1467605479==" Errors-To: pwe3-bounces@ietf.org --===============1467605479== Content-Type: multipart/alternative; boundary="----=_Part_12351_16800534.1168451614605" ------=_Part_12351_16800534.1168451614605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Stewart, et al., I have no problem with this working group discussing this issue, as we have since the bofs, and during our presentations to other WG's (for example, I first presented my draft in the RTP WG.) However, this issue is not one that I feel needs to be (or even can be) solved by this working group. As presented, this draft lays out many issues confronting us (by this us I mean the IETF, not PWE3 in particular) regarding congestion control. The issue of TCP friendly behavior has/been and will continue to be an issue for several areas of IETF work, including but not limited to L2TP, RTP, L2VPN, and even MPLS. Because TCP also has issues that need to be addressed, some may be helped by additional congestion profiles within DCCP, but other are still not yet being addressed. Such as the those related to chronic link (under)utilization. Also, given Sally Floyd's recent work on fairness, it may not be feasible to even define what TCP friendly is without some sort of a priori knowledge of the traffic and what it is competing with. And lastly, perhaps it is TCP itself that is problem. Perhaps this is simply a case of we have a "congestion avoidance hammer" (TCP), but this problem is best solved with a screwdriver ("other not specified congestion avoidance mechanism") that work independent of the higher level protocol and may even in effect "neuter" TCP's mechanisms. In any case, I think this problem is an issue for a larger audience than PWE3 and that this message needs to be communicated upward to the AD's, the IESG, and the IAB. This issue should not be used to "hold up" (selected) works of this group. IIt seems that the Transport area has certainly taken this stance with some of the latest (higher speed) profiles within RTP and that same position should be taken here. The drafts advanced by this working group were designed with as much concern for congession as can be reasonably be solved and/or expected. As was also noted in this draft, the PWE3 architecture does include all the necessary features to provide for the avoidance/control of congestion, each PW type defined what was needed for each protocol, and in most case these are people with significant experience in the deployment or planned deployments of these protocols. I would also like to point out that several of these protocols have been deployed for 2+ years. IMHO -craig On 1/9/07, Stewart Bryant wrote: > > > The PWE3 WG needs to form a consensus on whether to adopt > > http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt > > as a working group item. > > For my part I think congestion is a topic that, for the > good of the Internet, we as a WG have a responsibility > to address. > > So I put the question to the PWE3 WG: > > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? > > - Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------=_Part_12351_16800534.1168451614605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Stewart, et al.,

I have no problem with this working group discussing this issue, as we have since the bofs, and during our presentations to other WG's (for example, I first presented my draft in the RTP WG.) However, this issue is not one that I feel needs to be (or even can be) solved by this working group.

As presented, this draft lays out many issues confronting us (by this us I mean the IETF, not PWE3 in particular) regarding congestion control.

The issue of TCP friendly behavior has/been and will continue to be an issue for several areas of IETF work, including but not limited to L2TP, RTP, L2VPN, and even MPLS.

Because TCP also has issues that need to be addressed, some may be helped by additional congestion profiles within DCCP, but other are still not yet being addressed. Such as the those related to chronic link (under)utilization.

Also, given Sally Floyd's recent work on fairness, it may not be feasible to even define what TCP friendly is without some sort of a priori knowledge of the traffic and what it is competing with.

And lastly, perhaps it is TCP itself that is problem. Perhaps this is simply a case of we have a "congestion avoidance hammer" (TCP), but this problem is best solved with a screwdriver ("other not specified congestion avoidance mechanism") that work independent of the higher level protocol and may even in effect "neuter" TCP's mechanisms.

In any case, I think this problem is an issue for a larger audience than PWE3 and that this message needs to be communicated upward to the AD's, the IESG, and the IAB. This issue should not be used to "hold up" (selected) works of this group. IIt seems that the Transport area has certainly taken this stance with some of the latest (higher speed) profiles within RTP and that same position should be taken here.

The drafts advanced by this working group were designed with as much concern for congession as can be reasonably be solved and/or expected. As was also noted in this draft, the PWE3 architecture does include all the necessary features to provide for the avoidance/control of congestion, each PW type defined what was needed for each protocol, and in most case these are people with significant experience in the deployment or planned deployments of these protocols. I would also like to point out that several of these protocols have been deployed for 2+ years.

IMHO
-craig


On 1/9/07, Stewart Bryant <stbryant@cisco.com> wrote:

The PWE3 WG needs to form a consensus on whether to adopt

http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt

as a working group item.

For my part I think congestion is a topic that, for the
good of the Internet, we as a WG have a responsibility
to address.

So I put the question to the PWE3 WG:

Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt
as a working group draft?

- Stewart


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

------=_Part_12351_16800534.1168451614605-- --===============1467605479== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1467605479==-- From pwe3-bounces@ietf.org Thu Jan 11 13:02:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Ex-0001vM-Q3; Thu, 11 Jan 2007 13:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Ew-0001vA-He for pwe3@ietf.org; Thu, 11 Jan 2007 13:01:26 -0500 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54Ei-0005aL-LU for pwe3@ietf.org; Thu, 11 Jan 2007 13:01:26 -0500 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l0BI12Io001055; Thu, 11 Jan 2007 13:01:02 -0500 Received: from solananetworks.com (ottawa-hs-64-26-128-202.s-ip.magma.ca [64.26.128.202]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l0BI0xTZ014961; Thu, 11 Jan 2007 13:01:02 -0500 Message-ID: <45A67B5B.60105@solananetworks.com> Date: Thu, 11 Jan 2007 13:00:59 -0500 From: Nabil Seddigh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Bryant Subject: Re: [PWE3] PWE3 Congestion References: <45A3E20F.2060004@cisco.com> In-Reply-To: <45A3E20F.2060004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Lars Eggert , Mark Townsley , pwe3 , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, I would agree with adopting "pwe congestion control framework" as a WG item. As long as this particular draft is seen only as a starting point, I am ok with its adoption as a WG item. Also, I'm not so sure whether the WG needs to take the next step of defining actual congestion control mechanisms for pwe. There has been lots of prior/related work in this area including TCP trunking and I wonder if it can be left to vendors to adopt specific techniques. I get worried when I see things resembling ATM rate control etc. --- Best, Nabil Seddigh nseddigh@solananetworks.com http://www.solananetworks.com > > The PWE3 WG needs to form a consensus on whether to adopt > > http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt > > as a working group item. > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 11 13:54:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54yU-0003Mv-HF; Thu, 11 Jan 2007 13:48:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54yR-0003JO-PA for pwe3@ietf.org; Thu, 11 Jan 2007 13:48:27 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54uf-0007jO-M1 for pwe3@ietf.org; Thu, 11 Jan 2007 13:44:50 -0500 Received: from ATL1VEXC010.usdom003.tco.tc ([10.158.7.19]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 13:44:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jan 2007 13:45:01 -0500 Message-ID: <941E166DB8C7F543B1FDDE0D8CAF2949048EDEA8@ATL1VEXC010.usdom003.tco.tc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PWE3 Congestion Thread-Index: Acc1qpLvFnyApZXLT0KUfI+18m4OuQABcFHg References: From: "Ken Young" To: X-OriginalArrivalTime: 11 Jan 2007 18:44:30.0381 (UTC) FILETIME=[874C9DD0:01C735B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [PWE3] Re: PWE3 Congestion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? Yes, I believe this should be adopted as a working group item. Cheers, Ken _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 11 15:18:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56NS-000444-Ix; Thu, 11 Jan 2007 15:18:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56NP-00043E-AU; Thu, 11 Jan 2007 15:18:19 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56NO-0008Bn-1k; Thu, 11 Jan 2007 15:18:19 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B2D5326F05; Thu, 11 Jan 2007 19:57:15 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H5631-0000Yp-Hd; Thu, 11 Jan 2007 14:57:15 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 11 Jan 2007 14:57:15 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Internet Architecture Board , pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Document Action: 'TDM over IP' to Informational RFC X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The IESG has approved the following document: - 'TDM over IP ' as an Informational RFC This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-06.txt Technical Summary This draft extends the work described in RFC4553 by describing structure-aware methods of encapsulating Time Division Multiplexed (TDM) signals as pseudo-wires over packet-switching networks (PSN). The use of a structure-aware method of emulating TDM circuits make it possible to safeguard TDM structure during transport over the PSN, thus making possible to effectively withstand network degradations such as packet loss events. TDM signaling also becomes visible, facilitating mechanisms that maintain or exploit this. Finally, by taking advantage of TDM signaling and/or voice activity detection, structure-aware TDM transport makes bandwidth conservation possible. Two structure-aware methods described in this draft. One uses a structure-indication mechanism which is derived from the mechanism used in ATM AAL1, and is best used when the channel allocation is static. The other uses a structure-reassembly mechanism based on the mechanism used in ATM AAL2, and may be used to conserve bandwidth when the channel allocation is dynamic. The methods described in this draft have been widely implemented, and in particular are compatible with methods described in ITU-T Recommendations Y.1413, Y.1414, Y.1452 and Y.1453. Working Group Summary Although the Working Group was able to reach consensus on the unstructured TDM emulation method (SAToP/RFC4553), it could not reach consensus on the best method of emulating a structured service. The PWE3 WG therefore decided to pursue two methods as informational RFCs(draft-ietf-pwe3-cesopsn-07.txt and draft-ietf-pwe3-tdmoip-05.txt) and to gain operational experience with the technology before recommending a standards track approach. Protocol Quality There are a number of implementations of this protocol, and it is in operational service. This document was reviewed by Mark Townsley. Note to RFC Editor Please process this draft and draft-ietf-pwe3-cesopsn (Informational) together, resulting in close RFC numbers and completion dates if possible. OLD: When MPLS is the PSN, PW-specific security mechanisms will generally be required, while for IP-based PSNs IPsec MAY be used. TDMoIP using L2TPv3 is subject to the security considerations discussed in section 4.1.3 of [RFC3931]. NEW: When MPLS is the PSN, PW-specific security mechanisms MAY be required, while for IP-based PSNs IPsec [RFC4301] MAY be used. TDMoIP using L2TPv3 is subject to the security considerations discussed in section 8 of [RFC3931]. OLD (In TOC and Headline): 4.1 UDP/IPv4 NEW: 4.1 UDP/IP OLD: When using L2TPv3, randomly selected cookies MAY be used to validate circuit origin. NEW: When using L2TPv3, a cryptographically random [RFC4086] Cookie SHOULD be used to protect against off-path packet insertion attacks, and a 64-bit Cookie is RECOMMENDED for protection against brute-force, blind, insertion attacks. Please add informational references for [RFC4301] and [RFC4086] _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 11 16:38:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57cU-0001iE-MC; Thu, 11 Jan 2007 16:37:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57cT-0001i6-FM for pwe3@ietf.org; Thu, 11 Jan 2007 16:37:57 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57cQ-00030r-L7 for pwe3@ietf.org; Thu, 11 Jan 2007 16:37:57 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l0BLxmog022477; Thu, 11 Jan 2007 15:59:49 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 15:37:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] PWE3 Congestion Date: Thu, 11 Jan 2007 15:37:49 -0600 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF76E00E@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <45A3E20F.2060004@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] PWE3 Congestion Thread-Index: Acc0HkmADHc8K6ItTVWoADzzmyXsdwBqmwXA From: "Eric Gray \(LO/EUS\)" To: "Stewart Bryant" , "pwe3" X-OriginalArrivalTime: 11 Jan 2007 21:37:50.0700 (UTC) FILETIME=[BE5F5AC0:01C735C8] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Lars Eggert , Mark Townsley , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yes.=20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: Tuesday, January 09, 2007 1:42 PM > To: pwe3 > Cc: Lars Eggert; Mark Townsley; Danny McPherson > Subject: [PWE3] PWE3 Congestion >=20 >=20 > The PWE3 WG needs to form a consensus on whether to adopt >=20 > http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt >=20 > as a working group item. >=20 > For my part I think congestion is a topic that, for the > good of the Internet, we as a WG have a responsibility > to address. >=20 > So I put the question to the PWE3 WG: >=20 > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? >=20 > - Stewart >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 12 04:34:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Imk-0007KH-Qw; Fri, 12 Jan 2007 04:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Imi-0007K4-T2 for pwe3@ietf.org; Fri, 12 Jan 2007 04:33:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Imh-00040B-J8 for pwe3@ietf.org; Fri, 12 Jan 2007 04:33:16 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2007 10:33:15 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0C9XEMT013191; Fri, 12 Jan 2007 10:33:14 +0100 Received: from [10.61.82.142] (ams3-vpn-dhcp4751.cisco.com [10.61.82.142]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0C9X7C8016224; Fri, 12 Jan 2007 10:33:07 +0100 (MET) Message-ID: <45A755CE.5040308@cisco.com> Date: Fri, 12 Jan 2007 09:33:02 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nabil Seddigh Subject: Re: [PWE3] PWE3 Congestion References: <45A3E20F.2060004@cisco.com> <45A67B5B.60105@solananetworks.com> In-Reply-To: <45A67B5B.60105@solananetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=793; t=1168594394; x=1169458394; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20PWE3=20Congestion |Sender:=20; bh=CO0oERd6MGrIUcCPcZx0K5oyOjaTSnBeEGBXTRz0wRQ=; b=KMOZ2Uie9w/MXDfXY6y4S0qJROFGmXyMvzNHBqPll8wPczThA9JgQ5ezIuwSU5qclSfI6nf9 k++zX338oGJqzK/Nm6vs3zupx93qCPOlnV5W7KoCaWBjFkNMgFHXweGQ; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Lars Eggert , Mark Townsley , pwe3 , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Nabil Seddigh wrote: > I get worried when I see things > resembling ATM rate control etc. This is why I think that PWE3 must be actively engaged in the definition of the congestion mechanism. We are well aware that the dataplane for PWE3 needs to be a highly efficient switching function. I therefore see this as a partnership between us and transport. They have expertise in control congestion and the effects of congestion on the net. We have expertise in the design and deployment of pseudowires in a variety of network environments, and will push back on any proposed mechanism that is impractical in our environment. What we need is a lightweight solution that to quote our charter "need only be sufficient for the satisfactory operation of the service" - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 12 05:27:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Jcz-0003Q5-Fr; Fri, 12 Jan 2007 05:27:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Jcy-0003Q0-72 for pwe3@ietf.org; Fri, 12 Jan 2007 05:27:16 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Jcv-0005Xl-LK for pwe3@ietf.org; Fri, 12 Jan 2007 05:27:16 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0CAPAtW004380; Fri, 12 Jan 2007 12:25:11 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 12:27:05 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 12:27:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] PWE3 Congestion Date: Fri, 12 Jan 2007 12:27:03 +0200 Message-ID: <213394AB6954BE4682E8B2A491034683485976@esebe108.NOE.Nokia.com> In-Reply-To: <45A755CE.5040308@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PWE3] PWE3 Congestion Thread-Index: Acc2LqEVUQKT8DAITe+eOkYbqU/YOgAA7jhw From: To: , X-OriginalArrivalTime: 12 Jan 2007 10:27:05.0650 (UTC) FILETIME=[34DDD120:01C73634] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112122513-0F1BCBB0-5B68AEBE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: lars.eggert@netlab.nec.de, townsley@cisco.com, pwe3@ietf.org, danny@tcb.net X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0568765387==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0568765387== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_02F7_01C73644.F6498D80" This is a multi-part message in MIME format. ------=_NextPart_000_02F7_01C73644.F6498D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > This is why I think that PWE3 must be actively engaged in the > definition of the congestion mechanism. We are well aware > that the dataplane for PWE3 needs to be a highly efficient > switching function. > > I therefore see this as a partnership between us and > transport. They have expertise in control congestion and the > effects of congestion on the net. We have expertise in the > design and deployment of pseudowires in a variety of network > environments, and will push back on any proposed mechanism > that is impractical in our environment. What we need is a > lightweight solution that to quote our charter "need only be > sufficient for the satisfactory operation of the service" Completely agree. And I think the transport folks will understand that pseudowires have special characteristics that require different congestion control mechanisms than those currently in use for transport-layer protocols. The constraints imposed by the pseudowire characteristics might make it very hard to establish the usual TCP friendliness and fairness properties, but if we come up with a general, i.e., simple, mechanism to reduce bandwidth use during congestion and to safely reacquire bandwidth after congestion, that'd be fine with me personally. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_02F7_01C73644.F6498D80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTEyMTAyNzAyWjAjBgkqhkiG 9w0BCQQxFgQUK/luRRVal2CrueIHcA9B62dGTCkwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAEqVLbpKm7nwcHuhHea8ShyMViic5vu3qlFAId37 DiyeclpyrbhBcmlysMNV6ZWx2sBVNB5x747qRwFbdrfshjZpdcrOTD0q6ogdWTVKszN2/BybOj3D Oeospd02H5uE/8KWOEFVy6cBYE3td4rNGAL+u0bQSr6hnrDKMs2LZNebPTHVf2vNJd+Wx15iq+jV s/6jH+8qH4yjEa+A3B4uOdmEqLCKSYRD2t0qWbsOdBE/BJeoaJc/77ddEU8RCiKFYncFZeIufHh/ xAVKOnMXKLaNKwej58Es620N9ASmBpER2JFNYMhCdNHyfuHXaGbcjHCs6ACKEMSZv5I4317Q1/gA AAAAAAA= ------=_NextPart_000_02F7_01C73644.F6498D80-- --===============0568765387== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0568765387==-- From pwe3-bounces@ietf.org Fri Jan 12 10:55:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OkV-00087J-Ia; Fri, 12 Jan 2007 10:55:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OkT-000877-Rl for pwe3@ietf.org; Fri, 12 Jan 2007 10:55:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5OkO-0007sr-Rk for pwe3@ietf.org; Fri, 12 Jan 2007 10:55:21 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2007 16:55:14 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0CFtCcf009261; Fri, 12 Jan 2007 16:55:12 +0100 Received: from [10.61.82.135] (ams3-vpn-dhcp4744.cisco.com [10.61.82.135]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0CFtCC8013633; Fri, 12 Jan 2007 16:55:12 +0100 (MET) Message-ID: <45A7AF5B.1010403@cisco.com> Date: Fri, 12 Jan 2007 15:55:07 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4394; t=1168617312; x=1169481312; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20[rbridge]=20Brief=20summary=20of=20feedback=20from= 20the=20IEEE=20meeting] |Sender:=20; bh=XpzwD6uOfsRT2kzGYMIa2vh8ecF8iwMgm1I34CD7cbE=; b=WxOBpDnhvxrhdAPd94YbI08RMRNJK9jt6uiCrOicBUA49ZSUYPz8oEZgCRxOextK19jGAlN4 EdjbxgdESDHspFixLV0mNCvNfeFf1DYbPv7yXvk/nVGDUX/VwqPi/Btj; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [PWE3] [Fwd: [rbridge] Brief summary of feedback from the IEEE meeting] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a report on the IETF-IEEE discussion on Rbridge. It seems that IEEE is planning to do work on congestion notification. We need be be aware of this for two reasons firstly we may at some stage need a next generation Ethernet PW as a result, and secondly anything the IEEE does is usually low overheaded in the data plane, and therefore may be applicable to our own work on congestion. - Stewart -------- Original Message -------- Subject: [rbridge] Brief summary of feedback from the IEEE meeting Date: Fri, 12 Jan 2007 09:19:28 -0600 From: Eric Gray (LO/EUS) To: SUMMARY of IEEE Feedback on TRILL Architecture ============================================== This is a brief summary of the verbal feedback we received from members of the IEEE 802.1 at the November meeting in Dallas. I am merely passing these on. They are not representative of any formal feedback, there was no vote taken or call for objections made, and they do not necessarily reflect my own opinion on any particular aspect of the work in IEEE, or in the TRILL WG. o One point was to address all of the documents: the statement that spanning tree protocol converges slowly, is inefficient or otherwise defective requires more clarification. o 802.1s (MSTP) has been around since 2000 - and is now part of 802.1Q. o RSTP has a convergence time much quicker than appears to have been considered in the problem statement draft. RSTP is now part of 802.1D (2004). o The TRILL document set should be specific as to which aspects of spanning tree "deficiencies" it will address and how it will address them. o Current bridging deployments take advantage of the STP root election process to optimize the use of certain links in the bridging topology. o The specific scenario described is the "wiring closet" problem outlined in the Architecture draft. o The 802.1 group would like to point out that they feel the TRILL solution will be dead on arrival if it does not address this issue. o The group does not consider replacing all wiring closet equipment with RBridges as a valid approach to address this issue. o Several members of the group said that currently developing 802.1 protocols and enhancements must be considered in working through the process of TRILL protocol definition. o For example, there are issues with supporting BCN in the use of tunneling technologies (specifically, how will an ingress RBridge ensure that a congestion notification is delivered to the actual source). o There was some discussion of BCN details (see below), but it will be important to have continuing dialogue (or some other form of interaction) going forward. o There are several other issues with 802.1 enhancements and/or extensions and issues with address transparency that should be considered as well. o Members of the group considers the intention of developing an SPF-based approach (using a link-state routing protocol) - particularly with intended plug-and-play capabilities - commendable, but would prefer: o the IETF consider sending routing experts to help the IEEE with shortest path bridging using a link-state routing protocol (replacing the current DVRP), or o focus strictly on defining control plane mechanisms to establish forwarding information for already existing - and yet to be defined 802 encapsulation and data-plane technologies. In the brief discussion on the topic of BCN, one thing that came out was that there is a need - and considerations in progress - to include some part of an original data-frame as part of congestion notification messages. This could potentially address issues with "tunneled" MAC frames - provided that the portion included is of sufficient length to include at least the MAC DA/SA of the triggering frame. There are no guarantees that this will happen, and it would be a very good idea to track the development of BCN in IEEE 802.1 - assuming we might want to support data-center applications using RBridges. -- Eric Gray _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 12 14:27:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S3P-0001r1-6e; Fri, 12 Jan 2007 14:27:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S3N-0001q9-EM for pwe3@ietf.org; Fri, 12 Jan 2007 14:27:05 -0500 Received: from winger.mail.pas.earthlink.net ([207.217.120.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5S3K-0003g4-Uz for pwe3@ietf.org; Fri, 12 Jan 2007 14:27:05 -0500 Received: from [207.69.182.209] (helo=[207.69.182.209]) by winger.mail.pas.earthlink.net with asmtp (Exim 4.34) id 1H5S3I-0006Wa-Ry; Fri, 12 Jan 2007 13:27:00 -0600 In-Reply-To: <45A3E20F.2060004@cisco.com> References: <45A3E20F.2060004@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47772ADA-297E-4635-9443-6EFF3A57E055@gmail.com> Content-Transfer-Encoding: 7bit From: Phil Bedard Subject: Re: [PWE3] PWE3 Congestion Date: Fri, 12 Jan 2007 14:26:58 -0500 To: Stewart Bryant X-Mailer: Apple Mail (2.752.3) X-ELNK-Trace: eb8212ccd47acc465a752383f42c064374bf435c0eb9d47834545a5d4a25b07e5b9b0c68951e53abda26055b1a6a9271350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.69.182.209 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Lars Eggert , Mark Townsley , pwe3 , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I think it's worthwhile to explore a light weight congestion control mechanism especially for protection scenarios where only a lower-bandwidth path exists. Would this PW congestion control modify the underlying transport layer for protocols that support congestion notification, like a Frame-Relay PW? Or is that an exercise better left up to an equipment vendor? Phil On Jan 9, 2007, at 1:42 PM, Stewart Bryant wrote: > > The PWE3 WG needs to form a consensus on whether to adopt > > http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt > > as a working group item. > > For my part I think congestion is a topic that, for the > good of the Internet, we as a WG have a responsibility > to address. > > So I put the question to the PWE3 WG: > > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? > > - Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 15 09:49:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6T8n-0001fr-8l; Mon, 15 Jan 2007 09:48:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6T8m-0001fj-2V for pwe3@ietf.org; Mon, 15 Jan 2007 09:48:52 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6T8k-0008Hg-Qc for pwe3@ietf.org; Mon, 15 Jan 2007 09:48:52 -0500 Received: from [192.168.2.104] (VDSL-151-118-3-159.DNVR.QWEST.NET [151.118.3.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id A18B9644C4; Mon, 15 Jan 2007 07:48:45 -0700 (MST) In-Reply-To: <45A3E20F.2060004@cisco.com> References: <45A3E20F.2060004@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Mon, 15 Jan 2007 07:48:38 -0700 To: Stewart Bryant X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Lars Eggert , Mark Townsley , pwe3 Subject: [PWE3] Re: PWE3 Congestion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Jan 9, 2007, at 11:42 AM, Stewart Bryant wrote: > > The PWE3 WG needs to form a consensus on whether to adopt > > http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt > > as a working group item. > > For my part I think congestion is a topic that, for the > good of the Internet, we as a WG have a responsibility > to address. > > So I put the question to the PWE3 WG: > > Should the PWE3 WG adopt draft-rosen-pwe3-congestion-04.txt > as a working group draft? I believe that given discussions here and in the last meeting, we've seen consensus and should move forward with this as a WG draft. Please post the next revision as such... Thanks! -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 15 13:15:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6WM2-0005YN-9r; Mon, 15 Jan 2007 13:14:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6WM1-0005YI-3u for pwe3@ietf.org; Mon, 15 Jan 2007 13:14:45 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6WLz-0005nt-SG for pwe3@ietf.org; Mon, 15 Jan 2007 13:14:45 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2007 10:14:44 -0800 X-IronPort-AV: i="4.13,191,1167638400"; d="scan'208"; a="50840775:sNHT42680640" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0FIEh4w020870 for ; Mon, 15 Jan 2007 13:14:43 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0FIEhOA012463 for ; Mon, 15 Jan 2007 13:14:43 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 13:14:43 -0500 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 13:14:43 -0500 Message-ID: <45ABC492.8070407@cisco.com> Date: Mon, 15 Jan 2007 19:14:42 +0100 From: Mark Townsley User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2007 18:14:43.0180 (UTC) FILETIME=[07B262C0:01C738D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=865; t=1168884883; x=1169748883; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20AD=20Evaluation=20of=20draft-ietf-pwe3-wildcard-pw-type-02.tx t |Sender:=20 |To:=20pwe3@ietf.org; bh=/XCOxu5w+jtgzyFQYc48YH+gxRIWpV2xG8t04IurpZU=; b=p3SWzOp37HYdpovzobXMJuJKn2rJPB1RgvJM1m3kQwCWV0y/bbixHr+Wbqt2y5CYW2NwcEg/ V/FuYyIsLwxn8gluVJ5JHsVrXKWuwEtwf1QOi8RCxpPmamcbF2SGJby1; Authentication-Results: rtp-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [PWE3] AD Evaluation of draft-ietf-pwe3-wildcard-pw-type-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Before sending this to IETF Last Call, I'd like to understand how possible race-conditions are avoided or resolved with the new PW Type. The document is clear that it is a configuration error to have both sides send the wildcard PW Type. However, does it follow that this is fixed in advance? For example, is it desirable to allow this sort of case... "PE A can accept any type of PW (i.e., it is in wildcard mode by default), but if PE B sends a wildcard PW Type, PE A will fallback and choose its preferred non-wildcard PW mode of (as an example) ethernet." If these kinds of dynamic configurations are expected, then there may be some deadlock or non-deterministic situations where one side waits on the other to initiate, or the decision is left up to chance based on which side receives a message first, etc. Thanks, - Mark _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 15 15:50:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YmW-0000VJ-24; Mon, 15 Jan 2007 15:50:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YmR-0000Fw-Ny; Mon, 15 Jan 2007 15:50:11 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6YmI-0000Ru-79; Mon, 15 Jan 2007 15:50:11 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2D2BF32A4C; Mon, 15 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H6YmI-0002ef-0l; Mon, 15 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 15 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-ms-pw-requirements-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --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 for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) Author(s) : M. Bocci, L. Martini Filename : draft-ietf-pwe3-ms-pw-requirements-04.txt Pages : 26 Date : 2007-1-15 This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-ms-pw-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-ms-pw-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-15105422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-ms-pw-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-ms-pw-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-15105422.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Mon Jan 15 16:06:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z1c-00075l-Ln; Mon, 15 Jan 2007 16:05:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z1b-00075W-F6 for pwe3@ietf.org; Mon, 15 Jan 2007 16:05:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Z1a-0003d1-2p for pwe3@ietf.org; Mon, 15 Jan 2007 16:05:51 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jan 2007 22:05:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0FL5k5X008220; Mon, 15 Jan 2007 22:05:46 +0100 Received: from [10.61.65.245] (ams3-vpn-dhcp501.cisco.com [10.61.65.245]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0FL5kC8005746; Mon, 15 Jan 2007 22:05:46 +0100 (MET) Message-ID: <45ABECA2.8040703@cisco.com> Date: Mon, 15 Jan 2007 21:05:38 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3@ietf.org Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-ms-pw-requirements-04.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3057; t=1168895146; x=1169759146; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20I-D=20ACTION=3Adraft-ietf-pwe3-ms-pw-require ments-04.txt |Sender:=20; bh=ABZbvGs3sR6jF+FHDI1Bk5JjtytDy+4MTa7mUvg4K9c=; b=mA7tT+hg2kyQOG73KwJMlZIF8pIo91BdVKNEIGr3rPX+/XP/P7rHGtEI29WWc4FdS5hL35MN U2VjJkpEDiNq0pkvyYZ8Nu3wWor9vT1wXHYNgmUHnZ5AOXV/okNN0KsM; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is the start of a Last Call for this draft. Last Call will finish Tuesday 30th January. Since work on Mult-segment pseudowires started our thoughts on the uses of this technology have moved on. Please (re)read this draft and send feedback to the list. Thanks Stewart Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. > > Title : Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) > Author(s) : M. Bocci, L. Martini > Filename : draft-ietf-pwe3-ms-pw-requirements-04.txt > Pages : 26 > Date : 2007-1-15 > > This document describes the necessary requirements to allow a service > provider to extend the reach of pseudowires across multiple domains. > These domains can be autonomous systems under one provider > administrative control, IGP areas in one autonomous system, different > autonomous systems under the administrative control of two or more > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-pwe3-ms-pw-requirements-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pwe3-ms-pw-requirements-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jan 16 02:25:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ih2-0000ii-FT; Tue, 16 Jan 2007 02:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ih1-0000iJ-SW for pwe3@ietf.org; Tue, 16 Jan 2007 02:25:15 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ih0-0001TM-7x for pwe3@ietf.org; Tue, 16 Jan 2007 02:25:15 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0G7Ow8S013243; Tue, 16 Jan 2007 01:25:11 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 01:25:00 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.20]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 12:54:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] A case in VPLS using MS-PW Date: Tue, 16 Jan 2007 12:54:55 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196508FFA2@INEXC1U01.in.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] A case in VPLS using MS-PW thread-index: AccvqRXUvfMXmV6ZRRyYciWciVFkBAJhUjAA From: "Dutta, Pranjal \(Pranjal\)" To: , X-OriginalArrivalTime: 16 Jan 2007 07:24:55.0701 (UTC) FILETIME=[6BC2F450:01C7393F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: hu.kan@zte.com.cn X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0554135267==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0554135267== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7393F.6B8A151C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7393F.6B8A151C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please refer inline ________________________________ From: jin.lizhong@zte.com.cn [mailto:jin.lizhong@zte.com.cn]=20 Sent: Thursday, 04 January, 2007 8:01 AM To: pwe3@ietf.org Cc: hu.kan@zte.com.cn Subject: [PWE3] A case in VPLS using MS-PW =20 Hi, all=20 We meet a question when implementing VPLS using MS-PW, pls see the following figure.=20 CE1---T-PE1----------S-PE----------T-PE2---CE2=20 |=20 CE3=20 Configure a static multi-segment Pseudo Wire between T-PE1 and T-PE2, consisted by S-PW1 and S-PW2. If S-PE is also a T-PE and need to setup a PW between S-PE and T-PE2, named PW3. CE1, CE2 and CE3 are in the same VPLS.=20 Then what's the relationship between S-PW2 and PW3 ?=20 There are two cases:=20 1. S-PW2 and PW3 are independent PWs, then the path from CE1 to CE3 is T-PE1->S-PE->T-PE2->S-PE. It is not the best path. And if PWs belonging to the same VPLS need same PWID. Then to identify them individually, PW need to implement certain extension, for PW identification cannot be based-upon Source+Destination+Pwid mechnism.=20 You would use generalized PWID for MS-PW signaling. So apart from PWID the SAII, TAII would differentiate the Pseudo wires. Please refer to draft http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-02.txt for details. 2. S-PW2 and PW3 are the same PW, then Multi-segment PW is not needed, hub & spoke PWs are setup between T-PE1, S-PE and T-PE2. This case can solve this problem.=20 Which cases do you guys prefer?=20 =20 Hope this helps, Pranjal .............................................. Add: No.68 Zijinghua Rd,Yuhuatai District,=20 Nanjing. P.R.China.=20 Zip: 210012=20 Tel: 0086-25-52871645=20 Mail: jin.lizhong@zte.com.cn=20 ..............................................=20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C7393F.6B8A151C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

      =         Please refer inline

From: = jin.lizhong@zte.com.cn [mailto:jin.lizhong@zte.com.cn]
Sent: Thursday, 04 = January, 2007 8:01 AM
To: pwe3@ietf.org
Cc: hu.kan@zte.com.cn
Subject: [PWE3] A case in = VPLS using MS-PW

 


Hi, all

We meet a question when implementing VPLS using MS-PW, pls see the = following figure.

CE1---T-PE1----------S-= PE----------T-PE2---CE2
                      = |
                    =  CE3

Configure a static multi-segment Pseudo Wire between T-PE1 and T-PE2, consisted by = S-PW1 and S-PW2. If S-PE is also a T-PE and need to setup a PW between S-PE = and T-PE2, named PW3. CE1, CE2 and CE3 are in the same VPLS. =

Then what's the relationship between S-PW2 and PW3 ?

There are two cases:
1. S-PW2 and PW3 are independent PWs, then the path from CE1 to CE3 is T-PE1->S-PE->T-PE2->S-PE. It is not the best path. And if PWs belonging to the same VPLS need same PWID. Then to identify them = individually, PW need to implement certain extension, for PW identification cannot be based-upon Source+Destination+Pwid = mechnism.

You would use generalized PWID for MS-PW signaling. So apart from PWID the SAII, = TAII would differentiate the Pseudo wires. Please refer to = draft

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-p= w-02.txt for details.


2. S-PW2 and PW3 are the same PW, then = Multi-segment PW is not needed, hub & spoke PWs are setup between T-PE1, S-PE and = T-PE2. This case can solve this problem.

Which cases do you guys prefer?

 =

Hope this helps,

Pranjal




.............................................. Add:   No.68 = Zijinghua Rd,Yuhuatai District,
      Nanjing. P.R.China.
Zip:   210012
Tel:   0086-25-52871645
Mail:  jin.lizhong@zte.com.cn
.............................................. = 

 
----------------------------------------------=
----------
ZTE Information Security Notice=
: The information contained in this mail&nb=
sp;is solely property of the sender's organ=
ization. This mail communication is confidential=
. Recipients named above are obligated to&n=
bsp;maintain secrecy and are not permitted =
to disclose the contents of this communicat=
ion to others.
This email and any files&n=
bsp;transmitted with it are confidential and&nbs=
p;intended solely for the use of the i=
ndividual or entity to whom they are a=
ddressed. If you have received this email&n=
bsp;in error please notify the originator o=
f the message. Any views expressed in =
this message are those of the individual&nb=
sp;sender.
This message has been scan=
ned for viruses and Spam by ZTE Anti-S=
pam system.
------_=_NextPart_001_01C7393F.6B8A151C-- --===============0554135267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0554135267==-- From pwe3-bounces@ietf.org Wed Jan 17 08:27:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7AoY-0004O2-0c; Wed, 17 Jan 2007 08:26:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7AoW-0004Ns-GU for pwe3@ietf.org; Wed, 17 Jan 2007 08:26:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7AoR-00056W-2F for pwe3@ietf.org; Wed, 17 Jan 2007 08:26:52 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2007 14:26:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0HDQiO1002631; Wed, 17 Jan 2007 14:26:44 +0100 Received: from [64.103.65.227] (dhcp-gpk02-vlan300-64-103-65-227.cisco.com [64.103.65.227]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0HDQdC8009103; Wed, 17 Jan 2007 14:26:40 +0100 (MET) Message-ID: <45AE240E.5000801@cisco.com> Date: Wed, 17 Jan 2007 13:26:38 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Townsley Subject: Re: [PWE3] AD Evaluation of draft-ietf-pwe3-wildcard-pw-type-02.txt References: <45ABC492.8070407@cisco.com> In-Reply-To: <45ABC492.8070407@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1589; t=1169040404; x=1169904404; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20AD=20Evaluation=20of=20draft-ietf-pwe3-wildc ard-pw-type-02.txt |Sender:=20; bh=yacG8sPQV5SQTX2VZ2dAtt+voLVWURJbeVdHI5kxtxU=; b=QQdiUUOVnM1MibsmBIpJYUyBXLAOR8Ncx2eJd8A9Vl/woBVB4OFjvI2kni67f/MIFu5qWwni UbqFsvnl8C1fbqN7/5Yq/ft5BuVypP6yTgKBxFBdLFYb1sZ9hv/v/fVD; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Mark Townsley wrote: > > Before sending this to IETF Last Call, I'd like to understand how > possible race-conditions are avoided or resolved with the new PW Type. > The document is clear that it is a configuration error to have both > sides send the wildcard PW Type. However, does it follow that this is > fixed in advance? > > For example, is it desirable to allow this sort of case... > > "PE A can accept any type of PW (i.e., it is in wildcard mode by > default), but if PE B sends a wildcard PW Type, PE A will fallback and > choose its preferred non-wildcard PW mode of (as an example) ethernet." > The draft says: If the PW Type cannot be supported or is "wildcard" it MUST respond to this message with a Label Release message with an LDP Status Code of "Generic Misconfiguration Error". Further actions are beyond the scope of this document but could include notifying the associated application (if any) or notifying network management. Maybe the draft needs to be more explicit, but surely a mutual wildcard request is the same as a wildcard response to a wildcard request. > If these kinds of dynamic configurations are expected, then there may be > some deadlock or non-deterministic situations where one side waits on > the other to initiate, or the decision is left up to chance based on > which side receives a message first, etc. > I don't think that there was any initial intent to ever support wildcard wildcard, and as you say if you do allow it the result is unpredictable. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 17 17:43:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JUm-0003cL-Jk; Wed, 17 Jan 2007 17:43:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JUj-0003bk-7x; Wed, 17 Jan 2007 17:43:01 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7JUh-0003zD-Uc; Wed, 17 Jan 2007 17:43:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AA33C176DB; Wed, 17 Jan 2007 22:42:29 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7JUD-0000KL-8Z; Wed, 17 Jan 2007 17:42:29 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 17 Jan 2007 17:42:29 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Internet Architecture Board , pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Protocol Action: 'SONET/SDH Circuit Emulation over Packet (CEP)' to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The IESG has approved the following document: - 'SONET/SDH Circuit Emulation over Packet (CEP) ' as a Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-14.txt Technical Summary This document provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over packet-switched networks, and MPLS networks in particular. Working Group Summary This draft has been extensively reviewed by the PWE3 WG and there is consensus for it. It was recently revised with modifications to the control word to bring it into line with the other PWE3 specifications. Protocol Quality This document was reviewed by Mark Townsley. Note to RFC Editor OLD "are not a substitute for PW layer security." NEW "are not a substitute for securing the PW and underlying MPLS network itself." _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 22 08:36:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zKg-0001lI-2m; Mon, 22 Jan 2007 08:35:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zKe-0001l9-Eo for pwe3@ietf.org; Mon, 22 Jan 2007 08:35:32 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8zKd-0002y7-4p for pwe3@ietf.org; Mon, 22 Jan 2007 08:35:32 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jan 2007 14:35:31 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0MDZUr8030512; Mon, 22 Jan 2007 14:35:30 +0100 Received: from [10.61.65.16] (ams3-vpn-dhcp272.cisco.com [10.61.65.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0MDZPC8015491; Mon, 22 Jan 2007 14:35:30 +0100 (MET) Message-ID: <45B4BD98.3090802@cisco.com> Date: Mon, 22 Jan 2007 13:35:20 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=373; t=1169472930; x=1170336930; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20VCCV-12=20last=20call |Sender:=20; bh=rszJ8RYXr64Ttnk1DvGjqBRAVW17ymWpujJASwFgK+w=; b=tH1WpVwMNlFQyZ03CBdQtVJsvEHwmJAj9sFZ5Fi0vzau6GcVg79NiiTFkbaTIhvLFjLVfYCv Z2WbCYOAOfsisqt2rkj3oaKI59HN8p6aNuXB9Z5s1GxwtS5F4tq+BbSf; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [PWE3] VCCV-12 last call X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is the start of last call for Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt last call will end 6th February. There are a couple of issues that I have with regard to IANA policy that is raised by this draft, but I will ask my questions in another thread. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 22 10:35:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91C2-0002BG-08; Mon, 22 Jan 2007 10:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91C0-0002B7-Lc for pwe3@ietf.org; Mon, 22 Jan 2007 10:34:44 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H91Bz-0003xf-C4 for pwe3@ietf.org; Mon, 22 Jan 2007 10:34:44 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jan 2007 16:34:43 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0MFYg6r007201; Mon, 22 Jan 2007 16:34:42 +0100 Received: from [10.61.65.16] (ams3-vpn-dhcp272.cisco.com [10.61.65.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0MFYcC8024753; Mon, 22 Jan 2007 16:34:42 +0100 (MET) Message-ID: <45B4D989.4080302@cisco.com> Date: Mon, 22 Jan 2007 15:34:33 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1680; t=1169480082; x=1170344082; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20VCCV-12=20IANA=20questions |Sender:=20; bh=DZui0H3nFlrnOJVY0ow5l3vIg3bkz+k4TGK9OpQBeRM=; b=WLOHRksCZGPufuTmJptim4MUf46vt7zx0/eEUt2ggaHU87cqi9kwfXbZ+ivEy3kcOub1xcrb qdE5b/SYU1Qps44QdpmwsDSoi0C9VZM2zAokqp8GgqHq+Ni6iXBwrOPD; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [PWE3] VCCV-12 IANA questions X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The first question that I have is what policy should be applied to the selection of values for Pseudowire Associated Channel Types We currently have two allocations 0x21 Associated Channel carries an IPv4 packet [RFC4385] 0x57 Associated Channel carries an IPv6 packet [RFC4385] These were chosen to be identical to the values assigned the Assigned PPP DLL Protocol Numbers registry, and the choice goes back to the days when we were thinking of using that registry. Now going forward, what policy does the WG think should be used. Given that we have two independent registries we had neither hope nor need of keeping then in sync. So we can either 1) Start at 1 (reserving 0 for a rainy day) and continue up. 2) Where there is a similar identifier in Assigned PPP DLL Protocol Numbers use it otherwise try to pick one that will not be used by PPP. The proposal by the VCCV authors was to use 7 for BFD Without IP/UDP Header (which PPP says is transparency inefficient and therefore is unlikely to ever be used). (1) will result in a more "compact registry", if you can call a registry with 0x55 empty entries compact. (2) is consistent with what we did in the past. Anyone have any thoughts? My second question concerns the several small registries that are set up by VCCV Control Channel Types (8 possible values 3 used) Connectivity Verification Types (CV Types) (8 possible values 6 used) CC Types (8 possible values 1 used) There are currently under expert review. However with registries this small I am inclined to suggest that we should make them IETF consensus? Anyone have any thoughts. Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 22 11:45:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92I0-0000LI-OZ; Mon, 22 Jan 2007 11:45:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92Hz-0000JX-OO for pwe3@ietf.org; Mon, 22 Jan 2007 11:44:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92Hy-0000mn-ED for pwe3@ietf.org; Mon, 22 Jan 2007 11:44:59 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jan 2007 17:44:56 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0MGit1x032404; Mon, 22 Jan 2007 17:44:55 +0100 Received: from [10.61.65.16] (ams3-vpn-dhcp272.cisco.com [10.61.65.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0MGisC8018504; Mon, 22 Jan 2007 17:44:55 +0100 (MET) Message-ID: <45B4EA01.8040305@cisco.com> Date: Mon, 22 Jan 2007 16:44:49 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=983; t=1169484295; x=1170348295; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Consent=20of=20Corrigendum=201=20to=20Recommendation=20G.8121 /Y.1381 |Sender:=20; bh=Z1OLb3lSSu9Ufv14Ur2anIOaKDXG9m72TIV1SkOG5js=; b=nZFS0mkcdC3FQwdS5MaK8PrpfNJrgKS2+0DFD+T83+JMK2Bn/jLo5rTenQlblnR59rXgYkhf sY9bI7d/l5zRssnV7KHcbIZ8Y9wLVtCKlsS4rFhRpfwZTLe72C+gdvPL; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Mark Townsley , Danny McPherson Subject: [PWE3] Consent of Corrigendum 1 to Recommendation G.8121/Y.1381 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Re the following liaison statement November 2006 ITU-T SG 15 IETF pwe3 and mpls WG Consent of Corrigendum 1 to Recommendation G.8121/Y.1381 https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=288 The core of which is: "The consented Corrigendum addresses the topic of reserved label ranges and restricts the range to {0..15}, down from the range {0..31} which was in the original text. "We thank for your input in reviewing the Recommendation, which has been instrumental in generating this Corrigendum, and look forward to continuing our relationship on this topic in the spirit of cooperation that has been prevalent over the recent months. In addition, we would kindly request that you keep us informed of any of your activities that you consider might be of our interest." The text in the word document is the necessary edits which look correct. I propose that PWE3 simply respond thanking them making the change. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jan 23 19:23:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Vuw-0000yW-Vu; Tue, 23 Jan 2007 19:23:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Vuw-0000xL-E9 for pwe3@ietf.org; Tue, 23 Jan 2007 19:23:10 -0500 Received: from fncnmp04.fnc.fujitsu.com ([168.127.0.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Vuu-0001e2-4C for pwe3@ietf.org; Tue, 23 Jan 2007 19:23:10 -0500 Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp04.fnc.fujitsu.com with ESMTP; 23 Jan 2007 18:22:01 -0600 X-IronPort-AV: i="4.13,226,1167631200"; d="scan'208"; a="57686422:sNHT22497360" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [PWE3] VCCV-12 last call Date: Tue, 23 Jan 2007 18:22:01 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: Acc+Kt8y5vW+XyRHSK+Eo8wbQB5ZmgBIpuYw From: "O'Connor, Don" To: "Stewart Bryant" , "pwe3" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org My reading of VCCV - 12 is that=20 1) It only supports BFD Base and not MPLS BFD. It can be noted that = draft-ietf-bfd-mpls-03.txt. is not listed among the references 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP = Ping, LSP Ping, or BFD (Base). So it is not possible to support MPLS BFD = which enables concurrent use of LSP Ping and BFD Is my understanding accurate ?=20 Regards Don -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Monday, January 22, 2007 7:35 AM To: pwe3 Subject: [PWE3] VCCV-12 last call This is the start of last call for Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt last call will end 6th February. There are a couple of issues that I have with regard to IANA policy that is raised by this draft, but I will ask my questions in another thread. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 24 12:22:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9loj-0008BA-8Z; Wed, 24 Jan 2007 12:21:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9loh-0008B3-Pb for pwe3@ietf.org; Wed, 24 Jan 2007 12:21:47 -0500 Received: from p02c11o146.mxlogic.net ([208.65.145.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9log-0007j0-Cm for pwe3@ietf.org; Wed, 24 Jan 2007 12:21:47 -0500 Received: from unknown [208.251.151.99] by p02c11o146.mxlogic.net (mxl_mta-4.0.2-1) with SMTP id aa597b54.2406886320.2111.00-023.p02c11o146.mxlogic.net (envelope-from ); Wed, 24 Jan 2007 10:21:46 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jan 2007 11:21:18 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D703B80056@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SAToP RTP frequency default Thread-Index: Acc/3A8i/u+tBcUtT8iqVoiPX7Cozg== From: "STUART VENTERS" To: X-Spam: [F=0.0102000040; S=0.010(2007010901)] X-MAIL-FROM: X-SOURCE-IP: [208.251.151.99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [PWE3] SAToP RTP frequency default X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Greetings, I'm looking at using SAToP for transporting T1's using differential = timing mode. I'm wondering about the choice of 8Khz for the default RTP timestamp = frequency in RFC-4553. Specifically, does the default actually work and does it match what's = preferred in the field? Section 4.3.2. Usage of RTP Header 5th paragraph The frequency of the clock used for generating timestamps MUST be an integer multiple of 8 kHz. All implementations of SAToP MUST support the 8 kHz clock. Other multiples of 8 kHz MAY be used. A common wander spec for end to end T1 transport is 18us. The 8khz RTP = default appears to cause the tdm to packet IWF to add quite a bit of = noise to the information concerning the actual phase of the incoming T1. = Depending on the noise frequency, the packet to tdm iwf may be able to = filter it out, but it seems like the wander spec would be easier to meet = with a lower quantization noise. (In a similar situation in the Sonet = world, I think the receiving iwf is in fact sometimes unable to filter = it out without help from the transmitting iwf in the form of dithering.) The 8Khz default results in a quantization noise of +- 62.5us. =20 Making the differential timing default be the nominal tdm line rate = might be and alternative to the current default. (IE 1.544Mhz for T1, = 2.048 for E1, etc.) For a sample size of 3 implementations, this appears to be in line with = actual practice. (My personal preference would be 8.192M, but I could go with 1.544 = making it 4 implementations.) Perhaps others on the list have an opinion in this regard. I've looked in the pwe3 mail archives for this. The closest I've found = was a discussion in Sept 04 about how the 192 bytes payload default = interacted with the 8khz timestamp frequency. Perhaps someone could = point me someplace else where this has already been discussed. Cheers, Stuart Venters _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 24 12:30:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lwi-0004RS-77; Wed, 24 Jan 2007 12:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lwg-0004Qp-Vh for pwe3@ietf.org; Wed, 24 Jan 2007 12:30:02 -0500 Received: from webmail.resolutenetworks.com ([80.179.15.67] helo=mail.resolutenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9lwf-0000wc-IP for pwe3@ietf.org; Wed, 24 Jan 2007 12:30:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] SAToP RTP frequency default Date: Wed, 24 Jan 2007 19:31:35 +0200 Message-ID: <0606D918CE9CEA4E9835D2CDAA001A95C68EB1@ilmail1.il.reduxcom.com> In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D703B80056@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PWE3] SAToP RTP frequency default thread-index: Acc/3A8i/u+tBcUtT8iqVoiPX7CozgAAObzw References: <8F242B230AD6474C8E7815DE0B4982D703B80056@EXV1.corp.adtran.com> From: "Ron Cohen" To: "STUART VENTERS" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stuart, My 2c: I agree with you that 8kHz is way too low. The MEF (Metro Ethernet Forum) specification requires 25MHz which is much more reasonable. Best Ron -----Original Message----- From: STUART VENTERS [mailto:stuart.venters@adtran.com]=20 Sent: Wednesday, January 24, 2007 7:21 PM To: pwe3@ietf.org Subject: [PWE3] SAToP RTP frequency default Greetings, I'm looking at using SAToP for transporting T1's using differential timing mode. I'm wondering about the choice of 8Khz for the default RTP timestamp frequency in RFC-4553. Specifically, does the default actually work and does it match what's preferred in the field? Section 4.3.2. Usage of RTP Header 5th paragraph The frequency of the clock used for generating timestamps MUST be an integer multiple of 8 kHz. All implementations of SAToP MUST support the 8 kHz clock. Other multiples of 8 kHz MAY be used. A common wander spec for end to end T1 transport is 18us. The 8khz RTP default appears to cause the tdm to packet IWF to add quite a bit of noise to the information concerning the actual phase of the incoming T1. Depending on the noise frequency, the packet to tdm iwf may be able to filter it out, but it seems like the wander spec would be easier to meet with a lower quantization noise. (In a similar situation in the Sonet world, I think the receiving iwf is in fact sometimes unable to filter it out without help from the transmitting iwf in the form of dithering.) The 8Khz default results in a quantization noise of +- 62.5us. =20 Making the differential timing default be the nominal tdm line rate might be and alternative to the current default. (IE 1.544Mhz for T1, 2.048 for E1, etc.) For a sample size of 3 implementations, this appears to be in line with actual practice. (My personal preference would be 8.192M, but I could go with 1.544 making it 4 implementations.) Perhaps others on the list have an opinion in this regard. I've looked in the pwe3 mail archives for this. The closest I've found was a discussion in Sept 04 about how the 192 bytes payload default interacted with the 8khz timestamp frequency. Perhaps someone could point me someplace else where this has already been discussed. Cheers, Stuart Venters _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --=20 This message has been scanned for viruses and dangerous content by ESVA, and is believed to be clean. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 24 15:49:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9p2W-0006TZ-1q; Wed, 24 Jan 2007 15:48:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9opi-0007or-Ay for pwe3@ietf.org; Wed, 24 Jan 2007 15:35:02 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9oph-00065p-2r for pwe3@ietf.org; Wed, 24 Jan 2007 15:35:02 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2007 12:34:59 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0OKYwAK019322; Wed, 24 Jan 2007 12:34:58 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn7.cisco.com [10.25.236.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l0OKYxhp029630; Wed, 24 Jan 2007 12:34:59 -0800 (PST) In-Reply-To: <1F374478-8169-45FF-BCD8-BE00F58C436A@tcb.net> References: <45000234.8070203@cisco.com> <45002772.8060603@ericsson.com> <1F374478-8169-45FF-BCD8-BE00F58C436A@tcb.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68918D28-0B50-44A5-9333-1C917D7154F7@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Wed, 24 Jan 2007 12:34:47 -0800 To: pwe3@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=308; t=1169670898; x=1170534898; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20IETF=20LC=20of=20draft-ietf-avt-hc-over-mpls-protocol-07 |Sender:=20; bh=+GuL1SeRdyd2a1Hg4RfxPTeuPOu7Z2t1P1RwXWc/IbA=; b=x8tpd9XyVJU7uYfTLY8Xo1HnSD7XeIbpVoTFTDrAcsIZhRmyYlyop8mA3NRico8JbtToS01X ituckhxe31LGun5hdaGFAUGCf41Nb4bj9kTfeQypyiCxAvTbm7SiIOU3; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Wed, 24 Jan 2007 15:48:15 -0500 Cc: pwe3-chairs@tools.ietf.org, Mark M Townsley Subject: [PWE3] IETF LC of draft-ietf-avt-hc-over-mpls-protocol-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I would like to bring to the attention of this group that this draft is about to be IETF Last Called. I'm sure that it could benefit from the review of people in this working group and I would appreciate if one or two people could read it and send any LC comments. Thank you, Cullen _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 08:34:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA4jD-0005cu-LX; Thu, 25 Jan 2007 08:33:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA4jC-0005aO-CP for pwe3@ietf.org; Thu, 25 Jan 2007 08:33:22 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA4jB-00032Q-2g for pwe3@ietf.org; Thu, 25 Jan 2007 08:33:22 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 14:33:21 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PDXKRj017723; Thu, 25 Jan 2007 14:33:20 +0100 Received: from [64.103.65.172] (dhcp-gpk02-vlan300-64-103-65-172.cisco.com [64.103.65.172]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PDXIC8015105; Thu, 25 Jan 2007 14:33:20 +0100 (MET) Message-ID: <45B8B19D.5030306@cisco.com> Date: Thu, 25 Jan 2007 13:33:17 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=870; t=1169732000; x=1170596000; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20IETF=20LC=20of=20draft-ietf-avt-hc-over-mpls-protoc ol-07] |Sender:=20; bh=vnGIPmb7bnNAevLMjVckPupH075wcJtwu4pv908Mjho=; b=o+lB+wW7huNqGWNW9i8H4huZTcQ6e7oP59/enhS0/9e/Frvg/tJPVtY+BUG1CE29slErnqW0 VqGqO6HS7fLCtcTsPsmDgk7fhU3xmpHwUu8sOuza57xiZv9oDFIDnj4P; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [PWE3] [Fwd: IETF LC of draft-ietf-avt-hc-over-mpls-protocol-07] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org -------- Original Message -------- Subject: IETF LC of draft-ietf-avt-hc-over-mpls-protocol-07 Date: Wed, 24 Jan 2007 12:34:47 -0800 From: Cullen Jennings To: pwe3@ietf.org CC: pwe3-chairs@tools.ietf.org, Magnus Westerlund , Mark M Townsley References: <45000234.8070203@cisco.com> <45002772.8060603@ericsson.com> <1F374478-8169-45FF-BCD8-BE00F58C436A@tcb.net> I would like to bring to the attention of this group that this draft is about to be IETF Last Called. I'm sure that it could benefit from the review of people in this working group and I would appreciate if one or two people could read it and send any LC comments. Thank you, Cullen _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 10:43:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6kc-0006Pk-Vc; Thu, 25 Jan 2007 10:42:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6kb-0006Pb-C4; Thu, 25 Jan 2007 10:42:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6kV-00083F-1v; Thu, 25 Jan 2007 10:42:57 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 16:42:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PFgo9H000878; Thu, 25 Jan 2007 16:42:50 +0100 Received: from [64.103.65.172] (dhcp-gpk02-vlan300-64-103-65-172.cisco.com [64.103.65.172]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PFgoC8029063; Thu, 25 Jan 2007 16:42:50 +0100 (MET) Message-ID: <45B8CFF8.9090800@cisco.com> Date: Thu, 25 Jan 2007 15:42:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2023; t=1169739770; x=1170603770; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Y.1720=20liased=20text |Sender:=20; bh=LpUbxPuuuLqeGCNsmC+xJSMhsmTJvaR6WNljA4iKNB4=; b=odI1FyZueofTxCdoRqXJizQPYGqh5rLaG5ENEkQnUjXAtlvRS43IVnDAoJs9/iXnOKDd4pog g8zJmzt0U0V5v2O4AaE4tE3ZXAveQCavMxpO07mUj9+11LvLSGO1w5eu; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mpls@ietf.org Subject: [PWE3] Y.1720 liased text X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Please could some else from the PWE3 WG take a look at the following liaison statement. https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=289 I think that we need to respond with the following, but I would like someone else to check my interpretation of their text and the IETF MPLS design. An appropriate response would seem to be: The PWE3 WG is concerned about the consented text for Y.1720 that has been liaised to us. In particular the following text in Y.1720 looks like a violation of the IETF MPLS architecture. Appendix II Packet 1+1 example realization The packet 1+1 scheme can be implemented by using a sequence as an identifier. The sequence number can be carried as the first four bytes inside the shim header of the LSP providing packet 1+1. Since the ingress and egress nodes must be aware of each LSP participating in the packet 1+1, the egress node will recognize that there is a sequence number inside the label. It will use the sequence number for selection purpose and then remove it before forwarding the accepted packet further. Note that packet 1+1 can be provided at any level of the hierarchy of a nested LSP. Figure II.1 illustrates the sequence number position behind the 4-bytes MPLS encapsulation header. This implies that the Y.1720 is proposing to place an item in the label stack that does not conform to the design of an RFC3032 label stack entry. This breaks the MPLS invariant that any item that follows an LSE with the S bit set to zero MUST be another LSE. It also breaks the guideline that any item that follows a MPLS LSE should either be an IP packet or should conform to the design described in RFC4385. It is our view that all MPLS packet designs must adhere to the design invariants and guidelines produced by the IETF and the text in Appendix II, and any technical design that conflicts with the IETF design needs amendment before Y.1720 is published in its final form. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 11:12:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Cj-0008OP-2w; Thu, 25 Jan 2007 11:12:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Ch-0008OG-GB for pwe3@ietf.org; Thu, 25 Jan 2007 11:11:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7Cg-0005Ql-6D for pwe3@ietf.org; Thu, 25 Jan 2007 11:11:59 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 17:11:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0PGBvNM031532; Thu, 25 Jan 2007 17:11:57 +0100 Received: from [64.103.65.172] (dhcp-gpk02-vlan300-64-103-65-172.cisco.com [64.103.65.172]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PGBvC8008597; Thu, 25 Jan 2007 17:11:57 +0100 (MET) Message-ID: <45B8D6C9.5010004@cisco.com> Date: Thu, 25 Jan 2007 16:11:53 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=342; t=1169741517; x=1170605517; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Linear=20protection=20switching=20for=20T-MPLS=20networks |Sender:=20; bh=5Lg3/QoYKEUVoH2K1VmSARnZyJuYpVbnL/rAae9R6s8=; b=ajwBHmmdn6BeOhjkW9cQlPIHwUNP8Fg+jzON0k0abgWvDLncJDXusOXyqtJEfOmXZDs9WUwN 7Tl3QnAFAR6HMveDroH+Yih87ZrZfnmVozGjDMwDZlkolr2Y1NfFJvOL; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [PWE3] Linear protection switching for T-MPLS networks X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Does anyone working on the protection of pseudowires have any views on the "Linear protection switching for T-MPLS networks" design that was liaised to us https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=290 If there are issues we need to raise them, otherwise I will simply thank them for the liaison. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 11:27:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7RN-0001sk-T0; Thu, 25 Jan 2007 11:27:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7RM-0001sX-Sy for pwe3@ietf.org; Thu, 25 Jan 2007 11:27:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7RL-0001Fc-Ie for pwe3@ietf.org; Thu, 25 Jan 2007 11:27:08 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 17:27:07 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PGR6sW016622; Thu, 25 Jan 2007 17:27:06 +0100 Received: from [64.103.65.172] (dhcp-gpk02-vlan300-64-103-65-172.cisco.com [64.103.65.172]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PGR6C8013152; Thu, 25 Jan 2007 17:27:06 +0100 (MET) Message-ID: <45B8DA5A.2040204@cisco.com> Date: Thu, 25 Jan 2007 16:27:06 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=475; t=1169742427; x=1170606427; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20multipoint=20TMPLS |Sender:=20; bh=5pTQYN1SZR8qWIOQ6Fb2HQLAqgCpoCjVbr739vTQ5lo=; b=a6gpse9R/FzvXN1a8HoZeBLpXbEj+4C0qhM9Ei3t5qgMz/2PYmm1bCV7Swa15IsMC0Zvvetn 9oiphLRI/9wPTbxVUNNrBbopNk/8Rodg4TBalWPj76KXWOg9T5HpdTho; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [PWE3] multipoint TMPLS X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The following liaison describes point to multipoint TMPLS connectivity. https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=287 PWE3 is not currently chartered to work on multipoint pseudowires. Multipoint was excluded from our original charter, but is simply not mentioned in our current charter. Is multipoint an item that PWE3 should be working on? I think that we need to suggest that this document gets liased to the L2VPN WG. Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 11:33:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7X8-0005Aj-US; Thu, 25 Jan 2007 11:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7X7-0005AY-Ss for pwe3@ietf.org; Thu, 25 Jan 2007 11:33:05 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7X6-0001vy-JF for pwe3@ietf.org; Thu, 25 Jan 2007 11:33:05 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2007 08:33:04 -0800 X-IronPort-AV: i="4.13,239,1167638400"; d="scan'208"; a="51600462:sNHT44014328" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PGX4D7024658; Thu, 25 Jan 2007 11:33:04 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PGX4VT009344; Thu, 25 Jan 2007 11:33:04 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:33:04 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:33:03 -0500 In-Reply-To: <45B8DA5A.2040204@cisco.com> References: <45B8DA5A.2040204@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] multipoint TMPLS Date: Thu, 25 Jan 2007 11:33:02 -0500 To: Stewart Bryant X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 16:33:03.0779 (UTC) FILETIME=[7C4D2730:01C7409E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1008; t=1169742784; x=1170606784; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20multipoint=20TMPLS |Sender:=20 |To:=20Stewart=20Bryant=20; bh=cJ58gbRF/BwWDGrvt8PnKlx4Kf0ssCLNELnmR5rV0p8=; b=ZRD7zSsYcssYgSIaLv0+ixPYGK06nkcqWDo69m+t11mwCe31c4nX4m4dVmcVKDLOiaE3JLbi GJcB/AxCMognD7e01SujGEX55dGmfnm0DpuFVMwzSZNuIk8gRQ2an7Ax; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > The following liaison describes point to multipoint > TMPLS connectivity. > > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=287 > > PWE3 is not currently chartered to work on > multipoint pseudowires. Multipoint was excluded > from our original charter, but is simply > not mentioned in our current charter. > > Is multipoint an item that PWE3 should be working > on? That is a good question. I think we need to hear from operational types about whether or not this is interesting/a requirement, or whether the solutions worked on in L2VPN are sufficient to solve their problems. It would be interesting to discuss the problem statement used by the T-MPLS ITU folks to as a starting point. > I think that we need to suggest that this document > gets liased to the L2VPN WG. For sure. --Tom > > Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 11:45:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7hW-0003Yf-K9; Thu, 25 Jan 2007 11:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7hV-0003VQ-BT for pwe3@ietf.org; Thu, 25 Jan 2007 11:43:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7hT-0004P6-VU for pwe3@ietf.org; Thu, 25 Jan 2007 11:43:49 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 17:43:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PGhjXq021651; Thu, 25 Jan 2007 17:43:45 +0100 Received: from [64.103.65.172] (dhcp-gpk02-vlan300-64-103-65-172.cisco.com [64.103.65.172]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PGhjC8017823; Thu, 25 Jan 2007 17:43:45 +0100 (MET) Message-ID: <45B8DE3F.2070300@cisco.com> Date: Thu, 25 Jan 2007 16:43:43 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=991; t=1169743425; x=1170607425; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Response=20to=20liasion=20stement=20G.8110.1=20(TMPLS) |Sender:=20; bh=nNeO4SvyXbAYyUlRWLpiWGQXDk0gMHVUUe6xZXxoZmE=; b=GLkz5Yxbxyq9csAH8lqj9vAzrUJOGK/APVXu58la9P0jAQHS3bvCUuJM/UkkDhxbzLR6KDLU mSdKgNILMEP8BMPhj4xKZfjW8iz0/yOB4HBFz2WOhw46pWdPjTwyGUP5; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [PWE3] Response to liasion stement G.8110.1 (TMPLS) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The following liaison statement is the text of the ITU TMPLS design https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=286 At IETF67 we agreed to liaise draft-bryant-pwe3-mpls-transport-00 to ITU SG15 I think that we should respond with something like: Thank you for liaising the text of G.8110.1. Looking at the requirements for TMPLS, it is our view that these can be met with existing widely deployed designs based on the specifications produced by the IETF PWE3 WG. We attach the following IETF draft which was written by members of the PWE3 WG and describes how to satisfy specified TMPLS requirement using the mechanisms already specified by the IETF. We request that you perform a detailed review of draft-bryant-pwe3-mpls-transport-00 so that we can determine what - if any - amendments we need to make to fully satisfy the TMPLS requirement with the existing well established and deployed pseudowire protocols. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 11:45:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7j0-00040O-16; Thu, 25 Jan 2007 11:45:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7iy-000407-Lg; Thu, 25 Jan 2007 11:45:20 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7iu-0004cw-Tv; Thu, 25 Jan 2007 11:45:20 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:45:16 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Jan 2007 16:45:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Y.1720 liased text Date: Thu, 25 Jan 2007 16:45:14 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AEF736A@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Y.1720 liased text Thread-Index: AcdAl7upam0dQ5/jQ1WFKzsuykEJMwAAQz0w From: To: , X-OriginalArrivalTime: 25 Jan 2007 16:45:14.0780 (UTC) FILETIME=[30030DC0:01C740A0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mpls@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Stewart, Well, there are certainly some issues when the semantic of a specific field in a traffic unit is NOT consistent in any layer network. For example, the MPLS label field can currently take on at least 3 different semantics, viz: - a proxy for destination identifier (ie the usual label-swapping/forwarding paradigm) - a proxy for a source identifier (ie a necessary consequence of (lower level) LSP merging) - a 'functional action', eg various labels in the reserved code-space 0-15. This is not good practice IMO....and one observation here would be that under misconnectivity incorrect downstream decisions could arise (noting that this may not simply be between LSPs at the same level but also across LSPs at different levels). Though to be strictly accurate, since the 'functional action' labels (0-15) are partitioned from the rest of the label space the consequence has some certainty of (incorrect) action. I am not familiar with the content of Y.1720, but from what you describe below it seems we can add yet another semantic to the label field.....or at least *its interpretation as a label field*, under misconnectivity, by some LSR that unexpectedly receives it (but also see Note below). Does not sound very good to me. Note - If S=3D1 in the preceding MPLS header then there seems less of a problem than if S=3D0.....which may appear an odd observation to make, = but I do so because of this specific text Stewart extracted from Y.1720 Appendix II (note the highlighted word 'any'): "Note that packet 1+1 can be provided at *any* level of the hierarchy of a nested LSP." regards, Neil > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: 25 January 2007 15:43 > To: pwe3 > Cc: mpls@ietf.org > Subject: [PWE3] Y.1720 liased text >=20 >=20 > Please could some else from the PWE3 WG take a look at > the following liaison statement. >=20 > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D289 >=20 > I think that we need to respond with the following, but > I would like someone else to check my interpretation of > their text and the IETF MPLS design. >=20 > An appropriate response would seem to be: >=20 >=20 > The PWE3 WG is concerned about the consented text for Y.1720=20 > that has been liaised to us. >=20 > In particular the following text in Y.1720 looks like a=20 > violation of the IETF MPLS architecture. >=20 > Appendix II >=20 > Packet 1+1 example realization > The packet 1+1 scheme can be implemented by using a sequence as an=20 > identifier. The sequence number can be carried as the first=20 > four bytes=20 > inside the shim header of the LSP providing packet 1+1. Since the=20 > ingress and egress nodes must be aware of each LSP=20 > participating in the=20 > packet 1+1, the egress node will recognize that there is a sequence=20 > number inside the label. It will use the sequence number for=20 > selection=20 > purpose and then remove it before forwarding the accepted packet=20 > further. Note that packet 1+1 can be provided at any level of the=20 > hierarchy of a nested LSP. Figure II.1 illustrates the=20 > sequence number=20 > position behind the 4-bytes MPLS encapsulation header. >=20 >=20 > This implies that the Y.1720 is proposing to place an item in=20 > the label stack that does not conform to the design of an=20 > RFC3032 label stack entry. >=20 > This breaks the MPLS invariant that any item that follows > an LSE with the S bit set to zero MUST be another LSE. >=20 > It also breaks the guideline that any item that follows > a MPLS LSE should either be an IP packet or should conform > to the design described in RFC4385. >=20 > It is our view that all MPLS packet designs must adhere to > the design invariants and guidelines produced by the IETF > and the text in Appendix II, and any technical design that=20 > conflicts with the IETF design needs amendment before Y.1720=20 > is published in its final form. >=20 > Regards >=20 > Stewart >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 11:45:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7j8-00046z-Gg; Thu, 25 Jan 2007 11:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7j6-00046u-R0 for pwe3@ietf.org; Thu, 25 Jan 2007 11:45:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7j5-0004eh-G0 for pwe3@ietf.org; Thu, 25 Jan 2007 11:45:28 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 17:45:28 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PGjQCi022340; Thu, 25 Jan 2007 17:45:26 +0100 Received: from [64.103.65.172] (dhcp-gpk02-vlan300-64-103-65-172.cisco.com [64.103.65.172]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PGjQC8018538; Thu, 25 Jan 2007 17:45:26 +0100 (MET) Message-ID: <45B8DEA6.20003@cisco.com> Date: Thu, 25 Jan 2007 16:45:26 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas D. Nadeau" Subject: Re: [PWE3] multipoint TMPLS References: <45B8DA5A.2040204@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1144; t=1169743526; x=1170607526; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20multipoint=20TMPLS |Sender:=20; bh=Hq3I8n/nCtDtASI2hEBBALhKJWmAjbnRWufsekAixpo=; b=kfAkgDgGr9z2Kbcgrsx5Hw3j2knLBhzCPzaDsVPhm/j8BNVmNAgM1T2PVMzRED1+SciIqyod AIk2ku+2L2wV+qNXI/7CLz6edH1Mx+/aWgwbYsM5+MN0VOSJhjxA0aC2; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thomas D. Nadeau wrote: > >> The following liaison describes point to multipoint >> TMPLS connectivity. >> >> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=287 >> >> PWE3 is not currently chartered to work on >> multipoint pseudowires. Multipoint was excluded >> from our original charter, but is simply >> not mentioned in our current charter. >> >> Is multipoint an item that PWE3 should be working >> on? > > > That is a good question. I think we need to > hear from operational types about whether or not > this is interesting/a requirement, or whether the solutions > worked on in L2VPN are sufficient to solve their problems. > It would be interesting to discuss the problem statement > used by the T-MPLS ITU folks to as a starting point. > Yes I agree - Stewart >> I think that we need to suggest that this document >> gets liased to the L2VPN WG. > > > For sure. > > --Tom > > > >> >> Stewart >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 11:50:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7nm-0007XX-QS; Thu, 25 Jan 2007 11:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7nl-0007XM-D8 for pwe3@ietf.org; Thu, 25 Jan 2007 11:50:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7nj-0005eN-1Y for pwe3@ietf.org; Thu, 25 Jan 2007 11:50:17 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 08:50:14 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0PGoEkZ012051; Thu, 25 Jan 2007 08:50:14 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0PGoBnL001659; Thu, 25 Jan 2007 08:50:14 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:50:06 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:50:06 -0500 In-Reply-To: <45B8DE3F.2070300@cisco.com> References: <45B8DE3F.2070300@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9AFA54EE-5A70-40D5-8C42-B52BFE6A5FE8@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] Response to liasion stement G.8110.1 (TMPLS) Date: Thu, 25 Jan 2007 11:50:05 -0500 To: Stewart Bryant X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 16:50:06.0179 (UTC) FILETIME=[DDB30330:01C740A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1238; t=1169743814; x=1170607814; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20Response=20to=20liasion=20stement=20G.8110.1 =20(TMPLS) |Sender:=20; bh=Osupykw5QMseXXZ+zW4a2WXOPtvMOx1FOzUigAPUFbM=; b=E06v8N9VRdi1DX8m5gw4+lUoTgg5y80uzUmwQQvdt+bzTR7mdASCMNap+AOP0+ZyxQekENMK NxjwEhwfh6DxEjvDSN569eDIQ9cJvRRawvy1eNHCZV7mAj2bHTkLrzVQ; Authentication-Results: sj-dkim-7; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I concur with your proposal. --Tom > The following liaison statement is the text of the > ITU TMPLS design > > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=286 > > At IETF67 we agreed to liaise draft-bryant-pwe3-mpls-transport-00 > to ITU SG15 > > I think that we should respond with something like: > > Thank you for liaising the text of G.8110.1. > > Looking at the requirements for TMPLS, it is our view > that these can be met with existing widely deployed > designs based on the specifications produced by the > IETF PWE3 WG. > > We attach the following IETF draft which was > written by members of the PWE3 WG and describes > how to satisfy specified TMPLS requirement using > the mechanisms already specified by the IETF. > > We request that you perform a detailed review of > draft-bryant-pwe3-mpls-transport-00 so that we > can determine what - if any - amendments we need > to make to fully satisfy the TMPLS requirement > with the existing well established and deployed > pseudowire protocols. > > Regards > > Stewart > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 12:55:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8nh-0007Ly-50; Thu, 25 Jan 2007 12:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8nf-0007LX-N7 for pwe3@ietf.org; Thu, 25 Jan 2007 12:54:15 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8nd-0000dv-7D for pwe3@ietf.org; Thu, 25 Jan 2007 12:54:15 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0PHsEhc006834; Thu, 25 Jan 2007 18:54:14 +0100 In-Reply-To: <45B8DE3F.2070300@cisco.com> To: Stewart Bryant Subject: Re: [PWE3] Response to liasion stement G.8110.1 (TMPLS) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Thu, 25 Jan 2007 18:54:07 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/25/2007 18:54:08, Serialize complete at 01/25/2007 18:54:08 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org stewart after a quick look o) spell out to which requirements for TMPLS this refers (liaison, or doc., e-mail exchange, etc.) o) s/view/understanding o) there are no "members" or "membership" to the PWE3 WG (yet ;-) o) spell out title of the draft o) s/TMPLS requirement/TMPLS requirements o) i think ITU refers to it as "T-MPLS" not "TMPLS" o) repeats twice that PWE3 WG are widely deployed and well established (enough with once), better make it clear that the fundamental concern is that "the T-MPLS variant of pseudowire over MPLS will in some way, and at some time, depart from the IETF design without any way for the network to know which variant it is operating" and that the "The purpose of this draft is to describe how those requirements can be met using existing IETF RFCs without modification." thanks, - d. Stewart Bryant 25/01/2007 17:43 To: pwe3 cc: Subject: [PWE3] Response to liasion stement G.8110.1 (TMPLS) The following liaison statement is the text of the ITU TMPLS design https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=286 At IETF67 we agreed to liaise draft-bryant-pwe3-mpls-transport-00 to ITU SG15 I think that we should respond with something like: Thank you for liaising the text of G.8110.1. Looking at the requirements for TMPLS, it is our view that these can be met with existing widely deployed designs based on the specifications produced by the IETF PWE3 WG. We attach the following IETF draft which was written by members of the PWE3 WG and describes how to satisfy specified TMPLS requirement using the mechanisms already specified by the IETF. We request that you perform a detailed review of draft-bryant-pwe3-mpls-transport-00 so that we can determine what - if any - amendments we need to make to fully satisfy the TMPLS requirement with the existing well established and deployed pseudowire protocols. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 13:28:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9Ks-0002wy-CU; Thu, 25 Jan 2007 13:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9Kp-0002sG-PZ; Thu, 25 Jan 2007 13:28:31 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA9Kl-0007dg-5a; Thu, 25 Jan 2007 13:28:31 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0PIRkwa005071; Thu, 25 Jan 2007 12:28:14 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 12:27:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Y.1720 liased text Date: Thu, 25 Jan 2007 12:27:59 -0600 Message-ID: <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> In-Reply-To: <45B8CFF8.9090800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Y.1720 liased text Thread-Index: AcdAl69IWvoz3o4xROaHgE5riVGhGAAFUCpg References: <45B8CFF8.9090800@cisco.com> From: "Trowbridge, Stephen J \(Steve\)" To: "Stewart Bryant" , "pwe3" X-OriginalArrivalTime: 25 Jan 2007 18:27:58.0345 (UTC) FILETIME=[89C86F90:01C740AE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mpls@ietf.org, "Ghani Abbas \(BE/ETL\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Stewart, I am not really close enough to Y.1720 to respond regarding the technical content, but what was just approved is not a new Recommendation. It is a minor maintenance update to a Recommendation originally developed in ITU-T Study Group 13 that has been in force since April 2003. All protection switching work was collected together in ITU-T Study Group 15 with the reorganization of work at the end of 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance update. If anyone on this list is more familiar with original Y.1720 than me, I think it would be helpful to know whether you think that we broke something in the process of doing the maintenance update, or if these are new concerns being raised in 2007 about a document that has been approved and in force since 2003? Regards, Steve -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Thursday, January 25, 2007 8:43 AM To: pwe3 Cc: mpls@ietf.org Subject: [PWE3] Y.1720 liased text Please could some else from the PWE3 WG take a look at the following liaison statement. https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D289 I think that we need to respond with the following, but I would like someone else to check my interpretation of their text and the IETF MPLS design. An appropriate response would seem to be: The PWE3 WG is concerned about the consented text for Y.1720 that has been liaised to us. In particular the following text in Y.1720 looks like a violation of the IETF MPLS architecture. Appendix II Packet 1+1 example realization The packet 1+1 scheme can be implemented by using a sequence as an identifier. The sequence number can be carried as the first four bytes inside the shim header of the LSP providing packet 1+1. Since the ingress and egress nodes must be aware of each LSP participating in the packet 1+1, the egress node will recognize that there is a sequence number inside the label. It will use the sequence number for selection purpose and then remove it before forwarding the accepted packet further. Note that packet 1+1 can be provided at any level of the hierarchy of a nested LSP. Figure II.1 illustrates the sequence number position behind the 4-bytes MPLS encapsulation header. This implies that the Y.1720 is proposing to place an item in the label stack that does not conform to the design of an RFC3032 label stack entry. This breaks the MPLS invariant that any item that follows an LSE with the S bit set to zero MUST be another LSE. It also breaks the guideline that any item that follows a MPLS LSE should either be an IP packet or should conform to the design described in RFC4385. It is our view that all MPLS packet designs must adhere to the design invariants and guidelines produced by the IETF and the text in Appendix II, and any technical design that conflicts with the IETF design needs amendment before Y.1720 is published in its final form. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 14:16:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAA4H-0006w5-Ip; Thu, 25 Jan 2007 14:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAA4G-0006vr-Dy for pwe3@ietf.org; Thu, 25 Jan 2007 14:15:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAA4D-0004pd-MC for pwe3@ietf.org; Thu, 25 Jan 2007 14:15:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2007 14:15:26 -0500 X-IronPort-AV: i="4.13,239,1167627600"; d="scan'208"; a="112492707:sNHT49387044" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PJFPm4028555; Thu, 25 Jan 2007 14:15:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PJFPVT024355; Thu, 25 Jan 2007 14:15:25 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 14:15:24 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 14:15:24 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F595D03-67A8-493A-BC65-1284C38F83A8@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 last call Date: Thu, 25 Jan 2007 14:15:22 -0500 To: "O'Connor, Don" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 19:15:24.0623 (UTC) FILETIME=[2A4BFDF0:01C740B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2075; t=1169752525; x=1170616525; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20 |To:=20=22O'Connor,=20Don=22=20; bh=6cUxbmCO/9KCeXIv+ztRPJfpuwXQo1w9901X5m2Nfuc=; b=G/4Ems87aIfMHPHZBRMujp2kc2niJlWddniQnclFRGXBzC7L8G3HwsBzQX/cwJoK/45BSX/G RWZ3fQBRIbGBFHrH+Zyf9wvxlF5gRRIK/bkVr+we9MGvfbPC20D9CHkz; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: pwe3 , Stewart Bryant X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > My reading of VCCV - 12 is that > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that > draft-ietf-bfd-mpls-03.txt. is not listed among the references BFD-base is only required because the bootstrapping rules required to setup BFD/VCCV are single-hop style. > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP > Ping, LSP Ping, or BFD (Base). So it is not possible to support > MPLS BFD which enables concurrent use of LSP Ping and BFD You do not negotiate anything per se; you advertise capabilities for VCCV. You may advertise none, one or all of the different CC/CV combinations, which means you are willing to accept any of those combinations (within the rules stipulated in the draft). The receiving side is then free to send any of those combinations (within the rules stipulated in the draft), but once one is successfully sent (and acked), no others are allowed, and no "re-negotiation" is allowed without bringing down the PW. The latter comes specifically from the rules stipulated in RFC 4447. --Tom > > Is my understanding accurate ? > > Regards > > Don > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, January 22, 2007 7:35 AM > To: pwe3 > Subject: [PWE3] VCCV-12 last call > > > This is the start of last call for > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > last call will end 6th February. > > There are a couple of issues that I have with regard to > IANA policy that is raised by this draft, but I will > ask my questions in another thread. > > Regards > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 15:05:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAqA-0002Um-Fn; Thu, 25 Jan 2007 15:04:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAq9-0002Uh-Tw for pwe3@ietf.org; Thu, 25 Jan 2007 15:04:57 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAAq4-0002aE-Fj for pwe3@ietf.org; Thu, 25 Jan 2007 15:04:57 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 20:04:47 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Jan 2007 20:04:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] VCCV-12 last call Date: Thu, 25 Jan 2007 20:04:46 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AEF755B@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdAtWfXFqeqiWgKQU2F8gfAwUXdPAABmDvw From: To: , X-OriginalArrivalTime: 25 Jan 2007 20:04:46.0909 (UTC) FILETIME=[0FF4F6D0:01C740BC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pwe3@ietf.org, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org what happens if you subsequently get misconnectivity between LSPs using different options? regards, Neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]=20 > Sent: 25 January 2007 19:15 > To: O'Connor, Don > Cc: pwe3; Stewart Bryant > Subject: Re: [PWE3] VCCV-12 last call >=20 >=20 >=20 > On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: >=20 > > My reading of VCCV - 12 is that > > > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that > > draft-ietf-bfd-mpls-03.txt. is not listed among the references >=20 > BFD-base is only required because the bootstrapping=20 > rules required to setup BFD/VCCV are single-hop style. >=20 > > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP > > Ping, LSP Ping, or BFD (Base). So it is not possible to support =20 > > MPLS BFD which enables concurrent use of LSP Ping and BFD >=20 > You do not negotiate anything per se; you advertise=20 > capabilities for VCCV. You may advertise none, one or all of=20 > the different CC/CV =20 > combinations, > which means you are willing to accept any of those combinations =20 > (within the > rules stipulated in the draft). The receiving side is then=20 > free to send any of those combinations (within the rules=20 > stipulated in the draft), =20 > but > once one is successfully sent (and acked), no others are=20 > allowed, and no "re-negotiation" is allowed without bringing=20 > down the PW. The latter =20 > comes > specifically from the rules stipulated in RFC 4447. >=20 > --Tom >=20 >=20 >=20 > > > > Is my understanding accurate ? > > > > Regards > > > > Don > > > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Monday, January 22, 2007 7:35 AM > > To: pwe3 > > Subject: [PWE3] VCCV-12 last call > > > > > > This is the start of last call for > > > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)=20 > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > > > last call will end 6th February. > > > > There are a couple of issues that I have with regard to > > IANA policy that is raised by this draft, but I will > > ask my questions in another thread. > > > > Regards > > > > Stewart > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 16:11:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABsS-0004Ta-0Q; Thu, 25 Jan 2007 16:11:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABsQ-0004TU-Ap for pwe3@ietf.org; Thu, 25 Jan 2007 16:11:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HABsO-0002Jq-T3 for pwe3@ietf.org; Thu, 25 Jan 2007 16:11:22 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 13:11:20 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0PLBKAI031452; Thu, 25 Jan 2007 13:11:20 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0PLBInH014578; Thu, 25 Jan 2007 13:11:19 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:11:06 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:11:06 -0500 In-Reply-To: <0536FC9B908BEC4597EE721BE6A353891AEF755B@i2km07-ukbr.domain1.systemhost.net> References: <0536FC9B908BEC4597EE721BE6A353891AEF755B@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <489D8A7E-1026-4B7C-9024-A13595C34A68@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 last call Date: Thu, 25 Jan 2007 16:11:05 -0500 To: X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 21:11:06.0271 (UTC) FILETIME=[53D76AF0:01C740C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2815; t=1169759480; x=1170623480; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20; bh=tj38iDjRqo+1lCanNQHen75xhc9ujw8LdTvs32V+nvg=; b=wPeg29ABNK75cFmf+bJbSsmCGJhGqSc5wlqxKDFaItZgcyWcSWc8xHpBAEwrEcB27TpOTcjh W8v8qT9UHkqfhAdvo8az1ZEUB9qwwC1besUsCdoDWN55kXp7Trt7JzLz; Authentication-Results: sj-dkim-5; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: pwe3@ietf.org, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I don't understand what you mean. Can you be more specific in your example? --Tom > what happens if you subsequently get misconnectivity between LSPs > using > different options? > > regards, Neil > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: 25 January 2007 19:15 >> To: O'Connor, Don >> Cc: pwe3; Stewart Bryant >> Subject: Re: [PWE3] VCCV-12 last call >> >> >> >> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: >> >>> My reading of VCCV - 12 is that >>> >>> 1) It only supports BFD Base and not MPLS BFD. It can be noted that >>> draft-ietf-bfd-mpls-03.txt. is not listed among the references >> >> BFD-base is only required because the bootstrapping >> rules required to setup BFD/VCCV are single-hop style. >> >>> 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP >>> Ping, LSP Ping, or BFD (Base). So it is not possible to support >>> MPLS BFD which enables concurrent use of LSP Ping and BFD >> >> You do not negotiate anything per se; you advertise >> capabilities for VCCV. You may advertise none, one or all of >> the different CC/CV >> combinations, >> which means you are willing to accept any of those combinations >> (within the >> rules stipulated in the draft). The receiving side is then >> free to send any of those combinations (within the rules >> stipulated in the draft), >> but >> once one is successfully sent (and acked), no others are >> allowed, and no "re-negotiation" is allowed without bringing >> down the PW. The latter >> comes >> specifically from the rules stipulated in RFC 4447. >> >> --Tom >> >> >> >>> >>> Is my understanding accurate ? >>> >>> Regards >>> >>> Don >>> >>> -----Original Message----- >>> From: Stewart Bryant [mailto:stbryant@cisco.com] >>> Sent: Monday, January 22, 2007 7:35 AM >>> To: pwe3 >>> Subject: [PWE3] VCCV-12 last call >>> >>> >>> This is the start of last call for >>> >>> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >>> >>> last call will end 6th February. >>> >>> There are a couple of issues that I have with regard to >>> IANA policy that is raised by this draft, but I will >>> ask my questions in another thread. >>> >>> Regards >>> >>> Stewart >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 16:50:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HACTj-0006y3-2M; Thu, 25 Jan 2007 16:49:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HACTg-0006xp-JX; Thu, 25 Jan 2007 16:49:52 -0500 Received: from amsfep20-int.chello.nl ([62.179.120.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HACTe-0007hu-3w; Thu, 25 Jan 2007 16:49:52 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep20-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070125214946.VSDM14586.amsfep20-int.chello.nl@[192.168.17.5]>; Thu, 25 Jan 2007 22:49:46 +0100 Message-ID: <45B925F8.90707@chello.nl> Date: Thu, 25 Jan 2007 22:49:44 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Trowbridge, Stephen J \(Steve\)" Subject: Re: [PWE3] Y.1720 liased text References: <45B8CFF8.9090800@cisco.com> <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> In-Reply-To: <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mpls@ietf.org, "Ghani Abbas \(BE/ETL\)" , pwe3 , Stewart Bryant X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hello Steve, You wrote: > Hi Stewart, > I am not really close enough to Y.1720 to respond regarding the > technical content, but what was just approved is not a new > Recommendation. It is a minor maintenance update to a Recommendation > originally developed in ITU-T Study Group 13 that has been in force > since April 2003. All protection switching work was collected together > in ITU-T Study Group 15 with the reorganization of work at the end of > 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance > update. > > If anyone on this list is more familiar with original Y.1720 than me, I > think it would be helpful to know whether you think that we broke > something in the process of doing the maintenance update, or if these > are new concerns being raised in 2007 about a document that has been > approved and in force since 2003? It was indeed a maintenance update. The previous version was consented in the 07/2003 plenary and approved in 09/2003. The Appendix mentioned was not altered after that revision, so this text is there for three years. Regards, Huub (editor of Y.1720). > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, January 25, 2007 8:43 AM > To: pwe3 > Cc: mpls@ietf.org > Subject: [PWE3] Y.1720 liased text > > Please could some else from the PWE3 WG take a look at the following > liaison statement. > > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=289 > > I think that we need to respond with the following, but I would like > someone else to check my interpretation of their text and the IETF MPLS > design. > > An appropriate response would seem to be: > > > The PWE3 WG is concerned about the consented text for Y.1720 that has > been liaised to us. > > In particular the following text in Y.1720 looks like a violation of the > IETF MPLS architecture. > > Appendix II > > Packet 1+1 example realization > The packet 1+1 scheme can be implemented by using a sequence as an > identifier. The sequence number can be carried as the first four bytes > inside the shim header of the LSP providing packet 1+1. Since the > ingress and egress nodes must be aware of each LSP participating in the > packet 1+1, the egress node will recognize that there is a sequence > number inside the label. It will use the sequence number for selection > purpose and then remove it before forwarding the accepted packet > further. Note that packet 1+1 can be provided at any level of the > hierarchy of a nested LSP. Figure II.1 illustrates the sequence number > position behind the 4-bytes MPLS encapsulation header. > > > This implies that the Y.1720 is proposing to place an item in the label > stack that does not conform to the design of an RFC3032 label stack > entry. > > This breaks the MPLS invariant that any item that follows an LSE with > the S bit set to zero MUST be another LSE. > > It also breaks the guideline that any item that follows a MPLS LSE > should either be an IP packet or should conform to the design described > in RFC4385. > > It is our view that all MPLS packet designs must adhere to the design > invariants and guidelines produced by the IETF and the text in Appendix > II, and any technical design that conflicts with the IETF design needs > amendment before Y.1720 is published in its final form. > > Regards > > Stewart -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jan 25 17:47:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HADMt-0005Vz-13; Thu, 25 Jan 2007 17:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HADMs-0005Vu-G5 for pwe3@ietf.org; Thu, 25 Jan 2007 17:46:54 -0500 Received: from fncnmp04.fnc.fujitsu.com ([168.127.0.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HADMq-0007oG-RI for pwe3@ietf.org; Thu, 25 Jan 2007 17:46:54 -0500 Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp04.fnc.fujitsu.com with ESMTP; 25 Jan 2007 16:46:52 -0600 X-IronPort-AV: i="4.13,239,1167631200"; d="scan'208,217"; a="58093109:sNHT34469476" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] VCCV-12 last call Date: Thu, 25 Jan 2007 16:46:51 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdAtS9n51FWTsapQtS99gDhKUgHYQAG1h4U From: "O'Connor, Don" To: "Thomas D. Nadeau" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: pwe3 , Stewart Bryant X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1599552439==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1599552439== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C740D2.B452EC15" This is a multi-part message in MIME format. ------_=_NextPart_001_01C740D2.B452EC15 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom =20 Section 7 indicates that only one CC mode can be used -=20 =20 "In particular, once a valid CC Type is used by a PE (traffic=20 sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation." =20 There is no statement that only one CV Type can be used. However the = current CV precedence rules in Section 7 imply that there is a = restriction that only one CV mode can be used concurrently.=20 =20 I believe that it would be useful to have a CV mode with concurrent LSP = Ping and BFD. So my request is to add a code point for the following=20 =20 LSP Ping + BFD for fault detection only =20 I would also suggest giving this code point the highest precedence in = the Section 7 CV precedence table =20 Regards =20 Don ________________________________ From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thu 1/25/2007 1:15 PM To: O'Connor, Don Cc: Stewart Bryant; pwe3 Subject: Re: [PWE3] VCCV-12 last call On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > My reading of VCCV - 12 is that > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that=20 > draft-ietf-bfd-mpls-03.txt. is not listed among the references BFD-base is only required because the bootstrapping rules = required to setup BFD/VCCV are single-hop style. > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP=20 > Ping, LSP Ping, or BFD (Base). So it is not possible to support=20 > MPLS BFD which enables concurrent use of LSP Ping and BFD You do not negotiate anything per se; you advertise capabilities = for VCCV. You may advertise none, one or all of the different CC/CV=20 combinations, which means you are willing to accept any of those combinations=20 (within the rules stipulated in the draft). The receiving side is then free to send any of those combinations (within the rules stipulated in the draft),=20 but once one is successfully sent (and acked), no others are allowed, and no "re-negotiation" is allowed without bringing down the PW. The latter=20 comes specifically from the rules stipulated in RFC 4447. --Tom > > Is my understanding accurate ? > > Regards > > Don > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, January 22, 2007 7:35 AM > To: pwe3 > Subject: [PWE3] VCCV-12 last call > > > This is the start of last call for > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > last call will end 6th February. > > There are a couple of issues that I have with regard to > IANA policy that is raised by this draft, but I will > ask my questions in another thread. > > Regards > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C740D2.B452EC15 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [PWE3] VCCV-12 last call=0A= =0A= =0A=
=0A=
Tom
=0A=
 
=0A=
Section 7 indicates that only = one CC mode =0A= can be used -
=0A=
 
=0A=
"In particular, once a = valid CC Type =0A= is used by a PE (traffic
   sent using that = encapsulation), the PE =0A= MUST NOT send any
   traffic down another CC Type =0A= encapsulation."
=0A=
 
=0A=
There is no statement that = only one CV Type =0A= can be used. However the current CV precedence rules in Section 7 imply = that =0A= there is a restriction that only one CV mode can be used concurrently. =0A=
=0A=
 
=0A=
I believe that it would be = useful to have a =0A= CV mode with concurrent LSP Ping and BFD. So my request is to add a code = point =0A= for the following
=0A=
 
=0A=
LSP Ping + BFD for fault = detection =0A= only
=0A=
 
=0A=
I would also suggest giving = this code point =0A= the highest precedence in the Section 7 CV precedence table
=0A=
 
=0A=
Regards
=0A=
 
=0A=
Don
=0A=

=0A=
=0A= From: Thomas D. Nadeau =0A= [mailto:tnadeau@cisco.com]
Sent: Thu 1/25/2007 1:15 = PM
To: =0A= O'Connor, Don
Cc: Stewart Bryant; pwe3
Subject: Re: = [PWE3] =0A= VCCV-12 last call

=0A=

=0A=

On Jan 23, 2007, at 7:22 PM, O'Connor, Don = wrote:

> My =0A= reading of VCCV - 12 is that
>
> 1) It only supports BFD = Base and =0A= not MPLS BFD. It can be noted that 
> = draft-ietf-bfd-mpls-03.txt. is =0A= not listed among the =0A= references

        BFD-base is = only =0A= required because the bootstrapping rules required to
setup BFD/VCCV = are =0A= single-hop style.

> 2) It is only possible to negotiate (by = LDP) one =0A= CV protocol - ICMP 
> Ping, LSP Ping, or BFD (Base). So it is = not =0A= possible to support 
> MPLS BFD which enables concurrent use = of LSP =0A= Ping and BFD

        You do = not =0A= negotiate anything per se; you advertise capabilities for
VCCV. You = may =0A= advertise none, one or all of the different =0A= CC/CV 
combinations,
which means you are willing to accept = any of =0A= those combinations 
(within the
rules stipulated in the = draft). The =0A= receiving side is then free to send
any of those combinations (within = the =0A= rules stipulated in the draft), 
but
once one is successfully = sent =0A= (and acked), no others are allowed, and no
"re-negotiation" is = allowed =0A= without bringing down the PW.  The = latter 
comes
specifically =0A= from the rules stipulated in RFC =0A= 4447.

        =0A= --Tom



>
> Is my understanding accurate = ?
>
> =0A= Regards
>
> Don
>
> -----Original = Message-----
> =0A= From: Stewart Bryant [mailto:stbryant@cisco.com]
>= Sent: =0A= Monday, January 22, 2007 7:35 AM
> To: pwe3
> Subject: = [PWE3] =0A= VCCV-12 last call
>
>
> This is the start of last call =0A= for
>
> Pseudo Wire Virtual Circuit Connectivity = Verification =0A= (VCCV)
> = http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
&g= t;
> =0A= last call will end 6th February.
>
> There are a couple of = issues =0A= that I have with regard to
> IANA policy that is raised by this = draft, but =0A= I will
> ask my questions in another thread.
>
> =0A= Regards
>
> Stewart
>
> =0A= _______________________________________________
> pwe3 mailing =0A= list
> pwe3@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/pwe3
>
> =0A= _______________________________________________
> pwe3 mailing =0A= list
> pwe3@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/pwe3

=0A= =0A= =0A= ------_=_NextPart_001_01C740D2.B452EC15-- --===============1599552439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1599552439==-- From pwe3-bounces@ietf.org Fri Jan 26 02:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HALZE-0005Re-H0; Fri, 26 Jan 2007 02:32:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HALZC-0005RP-CM for pwe3@ietf.org; Fri, 26 Jan 2007 02:32:10 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HALZ6-0005GD-PE for pwe3@ietf.org; Fri, 26 Jan 2007 02:32:10 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 07:31:59 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Jan 2007 07:31:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] VCCV-12 last call Date: Fri, 26 Jan 2007 07:31:58 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AEF7617@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdAxWC5XIgemsH7TU6tJ3H5cRnASwAVJOXw From: To: X-OriginalArrivalTime: 26 Jan 2007 07:31:59.0227 (UTC) FILETIME=[105564B0:01C7411C] X-Spam-Score: 0.2 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: pwe3@ietf.org, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sorry Tom that I was not clear.....what I meant was what happens if you use different OAM options on different LSPs/PWs and then one has misconnectivity between them? I presume this has been considered? Note - If one is using a consistent OAM function on all LSPs/PWs then one should (however see later) have predictable behaviour under misconnectivity, ie the traffic unit fields relating to the OAM function have a consistent semantic. However, this is a more general point for all the fields in a traffic unit, and not just OAM (any network mode/technology). For example, also see my post of yesterday on the thread "RE: [PWE3] Y.1720 liased text".....I attach the text for ease of reference below: =3D=3D=3D Well, there are certainly some issues when the semantic of a specific field in a traffic unit is NOT consistent in any layer network. For example, the MPLS label field can currently take on at least 3 different semantics, viz: - a proxy for destination identifier (ie the usual label-swapping/forwarding paradigm) - a proxy for a source identifier (ie a necessary consequence of (lower level) LSP merging) - a 'functional action', eg various labels in the reserved code-space 0-15. This is not good practice IMO....and one observation here would be that under misconnectivity incorrect downstream decisions could arise (noting that this may not simply be between LSPs at the same level but also across LSPs at different levels). Though to be strictly accurate, since the 'functional action' labels (0-15) are partitioned from the rest of the label space the consequence has some certainty of (incorrect) action. I am not familiar with the content of Y.1720, but from what you describe below it seems we can add yet another semantic to the label field.....or at least *its interpretation as a label field*, under misconnectivity, by some LSR that unexpectedly receives it (but also see Note below). Does not sound very good to me. Note - If S=3D1 in the preceding MPLS header then there seems less of a problem than if S=3D0.....which may appear an odd observation to make, = but I do so because of this specific text Stewart extracted from Y.1720 Appendix II (note the highlighted word 'any'): "Note that packet 1+1 can be provided at *any* level of the hierarchy of a nested LSP." =3D=3D=3D regards, Neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]=20 > Sent: 25 January 2007 21:11 > To: Harrison,N,Neil,JCGA1 R > Cc: don.oconnor@us.fujitsu.com; pwe3@ietf.org; stbryant@cisco.com > Subject: Re: [PWE3] VCCV-12 last call >=20 >=20 >=20 > I don't understand what you mean. Can you be > more specific in your example? >=20 > --Tom >=20 >=20 > > what happens if you subsequently get misconnectivity between LSPs > > using > > different options? > > > > regards, Neil > > > >> -----Original Message----- > >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> Sent: 25 January 2007 19:15 > >> To: O'Connor, Don > >> Cc: pwe3; Stewart Bryant > >> Subject: Re: [PWE3] VCCV-12 last call > >> > >> > >> > >> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > >> > >>> My reading of VCCV - 12 is that > >>> > >>> 1) It only supports BFD Base and not MPLS BFD. It can be=20 > noted that=20 > >>> draft-ietf-bfd-mpls-03.txt. is not listed among the references > >> > >> BFD-base is only required because the bootstrapping > >> rules required to setup BFD/VCCV are single-hop style. > >> > >>> 2) It is only possible to negotiate (by LDP) one CV=20 > protocol - ICMP=20 > >>> Ping, LSP Ping, or BFD (Base). So it is not possible to=20 > support MPLS=20 > >>> BFD which enables concurrent use of LSP Ping and BFD > >> > >> You do not negotiate anything per se; you advertise=20 > capabilities for=20 > >> VCCV. You may advertise none, one or all of the different CC/CV > >> combinations, > >> which means you are willing to accept any of those combinations > >> (within the > >> rules stipulated in the draft). The receiving side is then > >> free to send any of those combinations (within the rules > >> stipulated in the draft), > >> but > >> once one is successfully sent (and acked), no others are > >> allowed, and no "re-negotiation" is allowed without bringing > >> down the PW. The latter > >> comes > >> specifically from the rules stipulated in RFC 4447. > >> > >> --Tom > >> > >> > >> > >>> > >>> Is my understanding accurate ? > >>> > >>> Regards > >>> > >>> Don > >>> > >>> -----Original Message----- > >>> From: Stewart Bryant [mailto:stbryant@cisco.com] > >>> Sent: Monday, January 22, 2007 7:35 AM > >>> To: pwe3 > >>> Subject: [PWE3] VCCV-12 last call > >>> > >>> > >>> This is the start of last call for > >>> > >>> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)=20 > >>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > >>> > >>> last call will end 6th February. > >>> > >>> There are a couple of issues that I have with regard to=20 > IANA policy=20 > >>> that is raised by this draft, but I will ask my questions=20 > in another=20 > >>> thread. > >>> > >>> Regards > >>> > >>> Stewart > >>> > >>> _______________________________________________ > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>> > >>> _______________________________________________ > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >> >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 02:43:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HALk2-0002ig-Nl; Fri, 26 Jan 2007 02:43:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HALk0-0002iF-62; Fri, 26 Jan 2007 02:43:20 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HALju-0007Va-HN; Fri, 26 Jan 2007 02:43:20 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 07:43:07 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Jan 2007 07:43:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Y.1720 liased text Date: Fri, 26 Jan 2007 07:43:06 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Y.1720 liased text Thread-Index: AcdAyvfqh5wffLkuRQmC9hNv5lSAfgAUPIvA From: To: , X-OriginalArrivalTime: 26 Jan 2007 07:43:06.0985 (UTC) FILETIME=[9E592D90:01C7411D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: mpls@ietf.org, stbryant@cisco.com, pwe3@ietf.org, ghani.abbas@ericsson.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Huub,=20 Can you clarify how the S bit is set when this 1+1 seq no. field is used? What is puzzling me is this sentence in the text Stewart extracted from Y.1720/Appendix 11: "Note that packet 1+1 can be provided at any level of the hierarchy of a nested LSP." I sort-of read this as there can be a set of nested LSPs (hence concatenated MPLS headers) and that the protection mechanism can be applied to any one of these within such a stack. Am I reading this right? If I am, then please see my concerns of yesterday on this thread....which, in essence, is querying what happens if there is misconnectivity and the LSP carrying the 1+1 Seq No. stuff arrives at some arbitrary LSR.....how will that LSR parse/interpret the fields it sees? I have no background on Y.1720, so my apologies if I am asking a dumb question. regards, Neil > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 > Sent: 25 January 2007 21:50 > To: Trowbridge, Stephen J (Steve) > Cc: mpls@ietf.org; Ghani Abbas (BE/ETL); pwe3; Stewart Bryant > Subject: Re: [PWE3] Y.1720 liased text >=20 >=20 > Hello Steve, >=20 > You wrote: >=20 > > Hi Stewart, > > I am not really close enough to Y.1720 to respond regarding the=20 > > technical content, but what was just approved is not a new=20 > > Recommendation. It is a minor maintenance update to a=20 > Recommendation=20 > > originally developed in ITU-T Study Group 13 that has been in force=20 > > since April 2003. All protection switching work was=20 > collected together=20 > > in ITU-T Study Group 15 with the reorganization of work at=20 > the end of=20 > > 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance=20 > > update. > >=20 > > If anyone on this list is more familiar with original=20 > Y.1720 than me,=20 > > I think it would be helpful to know whether you think that we broke=20 > > something in the process of doing the maintenance update,=20 > or if these=20 > > are new concerns being raised in 2007 about a document that=20 > has been=20 > > approved and in force since 2003? >=20 > It was indeed a maintenance update. The previous version was=20 > consented in the 07/2003 plenary and approved in 09/2003. >=20 > The Appendix mentioned was not altered after that revision, > so this text is there for three years. >=20 > Regards, Huub (editor of Y.1720). >=20 >=20 > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Thursday, January 25, 2007 8:43 AM > > To: pwe3 > > Cc: mpls@ietf.org > > Subject: [PWE3] Y.1720 liased text > >=20 > > Please could some else from the PWE3 WG take a look at the=20 > following=20 > > liaison statement. > >=20 > > = https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D289 > >=20 > > I think that we need to respond with the following, but I=20 > would like=20 > > someone else to check my interpretation of their text and the IETF=20 > > MPLS design. > >=20 > > An appropriate response would seem to be: > >=20 > >=20 > > The PWE3 WG is concerned about the consented text for=20 > Y.1720 that has=20 > > been liaised to us. > >=20 > > In particular the following text in Y.1720 looks like a=20 > violation of=20 > > the IETF MPLS architecture. > >=20 > > Appendix II > >=20 > > Packet 1+1 example realization > > The packet 1+1 scheme can be implemented by using a sequence as an=20 > > identifier. The sequence number can be carried as the first=20 > four bytes=20 > > inside the shim header of the LSP providing packet 1+1. Since the=20 > > ingress and egress nodes must be aware of each LSP participating in=20 > > the packet 1+1, the egress node will recognize that there is a=20 > > sequence number inside the label. It will use the sequence=20 > number for=20 > > selection purpose and then remove it before forwarding the accepted=20 > > packet further. Note that packet 1+1 can be provided at any=20 > level of=20 > > the hierarchy of a nested LSP. Figure II.1 illustrates the sequence=20 > > number position behind the 4-bytes MPLS encapsulation header. > >=20 > >=20 > > This implies that the Y.1720 is proposing to place an item in the=20 > > label stack that does not conform to the design of an RFC3032 label=20 > > stack entry. > >=20 > > This breaks the MPLS invariant that any item that follows=20 > an LSE with=20 > > the S bit set to zero MUST be another LSE. > >=20 > > It also breaks the guideline that any item that follows a MPLS LSE=20 > > should either be an IP packet or should conform to the design=20 > > described in RFC4385. > >=20 > > It is our view that all MPLS packet designs must adhere to=20 > the design=20 > > invariants and guidelines produced by the IETF and the text in=20 > > Appendix II, and any technical design that conflicts with the IETF=20 > > design needs amendment before Y.1720 is published in its final form. > >=20 > > Regards > >=20 > > Stewart >=20 > --=20 > = =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 > http://www.van-helvoort.eu/=20 > = =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 > Always remember that you are unique...just like everyone else... >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 06:36:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPN1-0003x2-0m; Fri, 26 Jan 2007 06:35:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPMx-0003wM-Og; Fri, 26 Jan 2007 06:35:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPMw-0001nr-GA; Fri, 26 Jan 2007 06:35:47 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 12:35:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QBZYaB017365; Fri, 26 Jan 2007 12:35:34 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QBZTC8000147; Fri, 26 Jan 2007 12:35:29 +0100 (MET) Message-ID: <45B9E77A.9000606@cisco.com> Date: Fri, 26 Jan 2007 11:35:22 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort Subject: Re: [mpls] Re: [PWE3] Y.1720 liased text References: <45B8CFF8.9090800@cisco.com> <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> <45B925F8.90707@chello.nl> In-Reply-To: <45B925F8.90707@chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=434; t=1169811335; x=1170675335; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[mpls]=20Re=3A=20[PWE3]=20Y.1720=20liased=20text |Sender:=20; bh=SDbbqx9uL2YN+vqIPtvRDkG9lvSuKAoc3UojRSS3Vqc=; b=mwBkpD63H7+bhA46PLVLvom6rbOJgI+LrlreaOrQc0OKHM0GoPFca4+6f+rZtbtdbLVhwwhW T0sqPpRMppmiet55NMk8+Am3+dQakN1ncEuXIrsgzp7bepcPenfB+Ivv; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mpls@ietf.org, pwe3 , "Ghani Abbas \(BE/ETL\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > It was indeed a maintenance update. The previous version was > consented in the 07/2003 plenary and approved in 09/2003. > > The Appendix mentioned was not altered after that revision, > so this text is there for three years. > > Regards, Huub (editor of Y.1720). Not withstanding that, the issue of non-LSE data within the stack is a valid concern. What have stack design was implemented and deployed? Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 07:10:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPu0-0005co-Si; Fri, 26 Jan 2007 07:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPtx-0005Y8-Rv; Fri, 26 Jan 2007 07:09:53 -0500 Received: from [62.179.120.10] (helo=amsfep15-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPtt-0007Pv-EQ; Fri, 26 Jan 2007 07:09:53 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep15-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126120947.BOMW1787.amsfep15-int.chello.nl@[192.168.17.5]>; Fri, 26 Jan 2007 13:09:47 +0100 Message-ID: <45B9EF8A.4000300@chello.nl> Date: Fri, 26 Jan 2007 13:09:46 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mpls@ietf.org, stbryant@cisco.com, pwe3@ietf.org, ghani.abbas@ericsson.com Subject: [PWE3] Re: Y.1720 liased text X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hello Neil, You responded: > Thanks Huub, > > Can you clarify how the S bit is set when this 1+1 seq no. field is > used? I checked the appendix II twice (because my left eye is still 10%), I could not find any text referring to setting the S bit. I only see that the 4 octet sequence number is placed right after the shim header. > What is puzzling me is this sentence in the text Stewart > extracted from Y.1720/Appendix 11: > > "Note that packet 1+1 can be provided at any level of the hierarchy of a > nested LSP." > > I sort-of read this as there can be a set of nested LSPs (hence > concatenated MPLS headers) and that the protection mechanism can be > applied to any one of these within such a stack. Am I reading this > right? I agree with your reading. > If I am, then please see my concerns of yesterday on this > thread....which, in essence, is querying what happens if there is > misconnectivity and the LSP carrying the 1+1 Seq No. stuff arrives at > some arbitrary LSR.....how will that LSR parse/interpret the fields it > sees? > > I have no background on Y.1720, so my apologies if I am asking a dumb > question. There are no dumb questions, only dumb answers. Maybe this is one: This morning I did some further investigating where the text originates and found it in the IETF archives: http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt It was also discussed on the MPLS WG list and there I found the answer to your concerns expressed above (provided by yourself ;-) http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00211.html Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 07:15:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPzL-0000JV-6k; Fri, 26 Jan 2007 07:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPzJ-0000IS-EJ; Fri, 26 Jan 2007 07:15:25 -0500 Received: from [213.46.243.15] (helo=amsfep18-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPzI-0008G4-14; Fri, 26 Jan 2007 07:15:25 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep18-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126121520.CMYM25065.amsfep18-int.chello.nl@[192.168.17.5]>; Fri, 26 Jan 2007 13:15:20 +0100 Message-ID: <45B9F0D6.9040702@chello.nl> Date: Fri, 26 Jan 2007 13:15:18 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stewart Bryant Subject: Re: [mpls] / [PWE3] Y.1720 liased text References: <45B8CFF8.9090800@cisco.com> <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> <45B925F8.90707@chello.nl> <45B9E77A.9000606@cisco.com> In-Reply-To: <45B9E77A.9000606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mpls@ietf.org, pwe3 , "Ghani Abbas \(BE/ETL\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hello Stewart, You replied: >> It was indeed a maintenance update. The previous version was >> consented in the 07/2003 plenary and approved in 09/2003. >> >> The Appendix mentioned was not altered after that revision, >> so this text is there for three years. >> >> Regards, Huub (editor of Y.1720). > > Not withstanding that, the issue of non-LSE data within > the stack is a valid concern. > > What have stack design was implemented and deployed? Would you please be so kind to elaborate/expand the last sentence, English is my second language, so I may misinterpret what you want to express. Kind regards, huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 07:17:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQ1B-00022B-NH; Fri, 26 Jan 2007 07:17:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQ19-00021D-PH; Fri, 26 Jan 2007 07:17:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQ18-0008WO-Gg; Fri, 26 Jan 2007 07:17:19 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 13:17:18 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QCHHBL030636; Fri, 26 Jan 2007 13:17:17 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QCHCC8012927; Fri, 26 Jan 2007 13:17:12 +0100 (MET) Message-ID: <45B9F143.2050701@cisco.com> Date: Fri, 26 Jan 2007 12:17:07 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> <45B9EF8A.4000300@chello.nl> In-Reply-To: <45B9EF8A.4000300@chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=460; t=1169813837; x=1170677837; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20Y.1720=20liased=20text |Sender:=20; bh=x+IT2iDw5NXffXm0BFumqsTZpg7CrtYV4qhteZ8tUOw=; b=KjjQCBTGDiX2b8IToF4TwBhbVz71OHC+NsZM8PCTl70yivzPhylo3sLNnAhYrp8G1ZB0i3rP x0QVo2AnCg3TbTorJfQXRFtdW5cVJBoq8PJ/FdgjA9cx0vwwGmZvzZ0u; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: neil.2.harrison@bt.com, ghani.abbas@ericsson.com, pwe3@ietf.org, mpls@ietf.org Subject: [PWE3] Re: Y.1720 liased text X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > I checked the appendix II twice (because my left eye is still 10%), > I could not find any text referring to setting the S bit. > I only see that the 4 octet sequence number is placed right > after the shim header. The implication of the text is that you can have a packet of the form: LSE (RFC3032) Sequence number LSE (RFC3032) Payload Is that correct? If so what is the setting of the S bit (See RFC3032) in each case? - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 07:30:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQDN-0000Y4-IH; Fri, 26 Jan 2007 07:29:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQDM-0000Xu-KB; Fri, 26 Jan 2007 07:29:56 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQDH-00026e-6M; Fri, 26 Jan 2007 07:29:56 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:27:56 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Jan 2007 12:27:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Re: Y.1720 liased text Date: Fri, 26 Jan 2007 12:27:54 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AF50079@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBRK7Mw4C9cvphRgOUNBIbPqxo3gAAJdoA From: To: , X-OriginalArrivalTime: 26 Jan 2007 12:27:55.0118 (UTC) FILETIME=[67AB58E0:01C74145] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Stewart....this is precisely my issue too. regards, Neil > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: 26 January 2007 12:17 > To: Huub van Helvoort > Cc: Harrison,N,Neil,JCGA1 R; ghani.abbas@ericsson.com;=20 > pwe3@ietf.org; mpls@ietf.org > Subject: [PWE3] Re: Y.1720 liased text >=20 >=20 >=20 > > I checked the appendix II twice (because my left eye is=20 > still 10%), I=20 > > could not find any text referring to setting the S bit. I only see=20 > > that the 4 octet sequence number is placed right after the shim=20 > > header. >=20 > The implication of the text is that you can have a packet of the > form: >=20 > LSE (RFC3032) > Sequence number > LSE (RFC3032) > Payload >=20 > Is that correct? >=20 > If so what is the setting of the S bit (See RFC3032) in each case? >=20 > - Stewart >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 07:39:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQMP-0005dX-Ey; Fri, 26 Jan 2007 07:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQMN-0005dA-DO; Fri, 26 Jan 2007 07:39:15 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQMJ-0003jQ-Qx; Fri, 26 Jan 2007 07:39:15 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:39:11 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Jan 2007 12:39:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Re: Y.1720 liased text Date: Fri, 26 Jan 2007 12:39:10 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AF500B8@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBQwPYBpagkXcpTUyc+b2VicoIlAAAsUsA From: To: X-OriginalArrivalTime: 26 Jan 2007 12:39:10.0719 (UTC) FILETIME=[FA5BE0F0:01C74146] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mpls@ietf.org, ghani.abbas@ericsson.com, pwe3@ietf.org, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Huub....back in 2002 when I wrote this I did flag up the issue of misconnectivity even then......but reading my own words I was only thinking about a bottom of stack problem, ie S=3D1 in preceding header. The text Stewart picked out of Y.1720/Appendix II seems to imply that this can also apply to an LSP in the *middle* of an arbitrary stack....ergo the questions wrt: - what are the S bit settings in this stack? - what happens if misconnectivity occurs, ie could such an LSP arriving unexpectedly at some LSR end-up parsing the sequence number field assuming it had the 'normal' MPLS 4 octet header structure (ie label/S/EXP/TTL)?.....though as I noted in a previous mail, there is an even larger issue here that the fields in traffic units should have consistent semantics network-wide (any mode/technology) regards, Neil > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 > Sent: 26 January 2007 12:10 > To: Harrison,N,Neil,JCGA1 R > Cc: mpls@ietf.org; stbryant@cisco.com; pwe3@ietf.org;=20 > ghani.abbas@ericsson.com > Subject: [PWE3] Re: Y.1720 liased text >=20 >=20 > Hello Neil, >=20 > You responded: >=20 > > Thanks Huub, > >=20 > > Can you clarify how the S bit is set when this 1+1 seq no. field is=20 > > used? >=20 > I checked the appendix II twice (because my left eye is still=20 > 10%), I could not find any text referring to setting the S=20 > bit. I only see that the 4 octet sequence number is placed=20 > right after the shim header. >=20 > > What is puzzling me is this sentence in the text Stewart extracted=20 > > from Y.1720/Appendix 11: > >=20 > > "Note that packet 1+1 can be provided at any level of the=20 > hierarchy of=20 > > a nested LSP." > >=20 > > I sort-of read this as there can be a set of nested LSPs (hence=20 > > concatenated MPLS headers) and that the protection mechanism can be=20 > > applied to any one of these within such a stack. Am I reading this=20 > > right? >=20 > I agree with your reading. >=20 > > If I am, then please see my concerns of yesterday on this=20 > > thread....which, in essence, is querying what happens if there is=20 > > misconnectivity and the LSP carrying the 1+1 Seq No. stuff=20 > arrives at=20 > > some arbitrary LSR.....how will that LSR parse/interpret=20 > the fields it=20 > > sees? > >=20 > > I have no background on Y.1720, so my apologies if I am=20 > asking a dumb=20 > > question. >=20 > There are no dumb questions, only dumb answers. Maybe this is one: >=20 > This morning I did some further investigating where the text=20 > originates and found it in the IETF archives:=20 > http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls- packet-protection-00.txt It was also discussed on the MPLS WG list and there I found the answer to your concerns expressed above (provided by yourself ;-) http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00211.html Cheers, Huub. --=20 =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 http://www.van-helvoort.eu/ =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 Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 07:45:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQSR-0000cD-Bu; Fri, 26 Jan 2007 07:45:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQSP-0000bp-1b; Fri, 26 Jan 2007 07:45:29 -0500 Received: from amsfep17-int.chello.nl ([62.179.120.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQSM-0004uO-KP; Fri, 26 Jan 2007 07:45:29 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep17-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126124524.YGOM9209.amsfep17-int.chello.nl@[192.168.17.5]>; Fri, 26 Jan 2007 13:45:24 +0100 Message-ID: <45B9F3A1.1090006@chello.nl> Date: Fri, 26 Jan 2007 13:27:13 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stewart Bryant References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> <45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> In-Reply-To: <45B9F143.2050701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: neil.2.harrison@bt.com, ghani.abbas@ericsson.com, pwe3@ietf.org, mpls@ietf.org Subject: [PWE3] Re: Y.1720 liased text X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hello Steward, You replied: >> I checked the appendix II twice (because my left eye is still 10%), >> I could not find any text referring to setting the S bit. >> I only see that the 4 octet sequence number is placed right >> after the shim header. > > The implication of the text is that you can have a packet of the > form: > > LSE (RFC3032) > Sequence number > LSE (RFC3032) > Payload > > Is that correct? This is also what I read, and apparently Neil does as well. > If so what is the setting of the S bit (See RFC3032) in each > case? Because the text does not mention any altering of the S-bit I assume they do not change. I agree with Neil (see his 2002 post) that this requires a very carefull configuartion of the network. Checking that both ends support this feature and closely guard the connectivity for both diverse routes. Note that this text is in an appendix, so it does not form an integral part of the recommendation, i.e. it is not mandatory. Regards, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 09:45:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASIt-0003dP-Cw; Fri, 26 Jan 2007 09:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASIr-0003c9-9R; Fri, 26 Jan 2007 09:43:45 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASIn-0006tY-Tw; Fri, 26 Jan 2007 09:43:45 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1HASIY-0005tH-00; Fri, 26 Jan 2007 14:43:26 +0000 Received: from your029b8cecfe ([80.68.57.98] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 14:43:27 +0000 Message-ID: <003d01c74158$5510a470$4002010a@your029b8cecfe> From: "Adrian Farrel" To: "Huub van Helvoort" , "Stewart Bryant" References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> Subject: Re: [PWE3] Re: Y.1720 liased text Date: Fri, 26 Jan 2007 14:39:48 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 26 Jan 2007 14:43:27.0839 (UTC) FILETIME=[572616F0:01C74158] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: neil.2.harrison@bt.com, mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Huub, >> The implication of the text is that you can have a packet of the >> form: >> >> LSE (RFC3032) >> Sequence number >> LSE (RFC3032) >> Payload >> >> Is that correct? > > This is also what I read, and apparently Neil does as well. > >> If so what is the setting of the S bit (See RFC3032) in each >> case? > > Because the text does not mention any altering of the S-bit > I assume they do not change. Ah, so either setting of the S-bit is allowed? > I agree with Neil (see his 2002 post) that this requires a > very carefull configuartion of the network. Checking that > both ends support this feature and closely guard the connectivity > for both diverse routes. With the S-bit, careful config is needed. Without the S-bit it seems like a router that popped a label would expect the next thing on the stack to also be a label, but would actually find a magic sequence number. Although you could config around this (since the pop action must be installed) this is a new MPLS behavior. At the least it is a new LFIB action that is not previously described in any MPLS documentation. > Note that this text is in an appendix, so it does not form > an integral part of the recommendation, i.e. it is not mandatory. Hmmm. Shouldn't there be a specification of: - what must be supported - what can also be attempted I think Stewart's question is quite helpful here. Do we have any idea of what deployed implementations do? Cheers, Adrian _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 10:08:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASgB-00081c-JH; Fri, 26 Jan 2007 10:07:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASg9-00081O-O2 for pwe3@ietf.org; Fri, 26 Jan 2007 10:07:49 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASg8-0002YW-40 for pwe3@ietf.org; Fri, 26 Jan 2007 10:07:49 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2007 07:07:47 -0800 X-IronPort-AV: i="4.13,243,1167638400"; d="scan'208"; a="105767143:sNHT55840014" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0QF7l2q001322; Fri, 26 Jan 2007 07:07:47 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QF7kGo008650; Fri, 26 Jan 2007 07:07:47 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 10:07:40 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 10:07:40 -0500 In-Reply-To: <0536FC9B908BEC4597EE721BE6A353891AEF7617@i2km07-ukbr.domain1.systemhost.net> References: <0536FC9B908BEC4597EE721BE6A353891AEF7617@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72C8437F-728A-49F7-8390-A5A146C699EB@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 last call Date: Fri, 26 Jan 2007 10:07:39 -0500 To: X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 15:07:40.0292 (UTC) FILETIME=[B8E0D440:01C7415B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6674; t=1169824067; x=1170688067; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20; bh=lQIwgFpI9YDG8e78I9XFq+W8B+i2YJjR9KhklRFzX2U=; b=c8sdj/ia0Ayc7bmTF/d5LxXJz+BPRpYgxCxzOJDYjZjNs60lfj8S3vVM/WZc8fm7GRKd6xCz RX9YtagY/kj5Iech2OPQ3gcpu7hOkddB3/v0F6YjcI46UrvW75MCvAqn; Authentication-Results: sj-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: pwe3@ietf.org, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > Sorry Tom that I was not clear.....what I meant was what happens if > you > use different OAM options on different LSPs/PWs and then one has > misconnectivity between them? I presume this has been considered? Yes, I think it has. I think the choice of which type of VCCV to use for each PW is up to the PW/configuration. I don't see how mandating that all PWs that ride on the same LSP use the same VCCV mode needs to be mandatory. If you want to configure this once deployed based on local policy, that is possible. However, there might be other reasons why people might want to deploy different modes on different PWs (say based on the AC type), which I think is reasonable to allow as well. > Note - If one is using a consistent OAM function on all LSPs/PWs then > one should (however see later) have predictable behaviour under > misconnectivity, ie the traffic unit fields relating to the OAM > function > have a consistent semantic. However, this is a more general point for > all the fields in a traffic unit, and not just OAM (any network > mode/technology). For example, also see my post of yesterday on the > thread "RE: [PWE3] Y.1720 liased text".....I attach the text for > ease of > reference below: Again, I think that the spec. does allow for making things consistent, if you so choose to configure your LSRs this way. I do know of other operators however, that wish to use different methods on different PWs based on the AC type. But in the end the spec. is flexible enough to accommodate both your and their requirements. --Tom > > === > > Well, there are certainly some issues when the semantic of a specific > field in a traffic unit is NOT consistent in any layer network. For > example, the MPLS label field can currently take on at least 3 > different > semantics, viz: > - a proxy for destination identifier (ie the usual > label-swapping/forwarding paradigm) > - a proxy for a source identifier (ie a necessary consequence of > (lower level) LSP merging) > - a 'functional action', eg various labels in the reserved > code-space 0-15. > > This is not good practice IMO....and one observation here would be > that > under misconnectivity incorrect downstream decisions could arise > (noting > that this may not simply be between LSPs at the same level but also > across LSPs at different levels). Though to be strictly accurate, > since > the 'functional action' labels (0-15) are partitioned from the rest of > the label space the consequence has some certainty of (incorrect) > action. > > I am not familiar with the content of Y.1720, but from what you > describe > below it seems we can add yet another semantic to the label > field.....or > at least *its interpretation as a label field*, under misconnectivity, > by some LSR that unexpectedly receives it (but also see Note below). > Does not sound very good to me. > > Note - If S=1 in the preceding MPLS header then there seems less of a > problem than if S=0.....which may appear an odd observation to > make, but > I do so because of this specific text Stewart extracted from Y.1720 > Appendix II (note the highlighted word 'any'): > > "Note that packet 1+1 can be provided at *any* level of the > hierarchy of > a nested LSP." > > === > > regards, Neil > > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: 25 January 2007 21:11 >> To: Harrison,N,Neil,JCGA1 R >> Cc: don.oconnor@us.fujitsu.com; pwe3@ietf.org; stbryant@cisco.com >> Subject: Re: [PWE3] VCCV-12 last call >> >> >> >> I don't understand what you mean. Can you be >> more specific in your example? >> >> --Tom >> >> >>> what happens if you subsequently get misconnectivity between LSPs >>> using >>> different options? >>> >>> regards, Neil >>> >>>> -----Original Message----- >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>> Sent: 25 January 2007 19:15 >>>> To: O'Connor, Don >>>> Cc: pwe3; Stewart Bryant >>>> Subject: Re: [PWE3] VCCV-12 last call >>>> >>>> >>>> >>>> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: >>>> >>>>> My reading of VCCV - 12 is that >>>>> >>>>> 1) It only supports BFD Base and not MPLS BFD. It can be >> noted that >>>>> draft-ietf-bfd-mpls-03.txt. is not listed among the references >>>> >>>> BFD-base is only required because the bootstrapping >>>> rules required to setup BFD/VCCV are single-hop style. >>>> >>>>> 2) It is only possible to negotiate (by LDP) one CV >> protocol - ICMP >>>>> Ping, LSP Ping, or BFD (Base). So it is not possible to >> support MPLS >>>>> BFD which enables concurrent use of LSP Ping and BFD >>>> >>>> You do not negotiate anything per se; you advertise >> capabilities for >>>> VCCV. You may advertise none, one or all of the different CC/CV >>>> combinations, >>>> which means you are willing to accept any of those combinations >>>> (within the >>>> rules stipulated in the draft). The receiving side is then >>>> free to send any of those combinations (within the rules >>>> stipulated in the draft), >>>> but >>>> once one is successfully sent (and acked), no others are >>>> allowed, and no "re-negotiation" is allowed without bringing >>>> down the PW. The latter >>>> comes >>>> specifically from the rules stipulated in RFC 4447. >>>> >>>> --Tom >>>> >>>> >>>> >>>>> >>>>> Is my understanding accurate ? >>>>> >>>>> Regards >>>>> >>>>> Don >>>>> >>>>> -----Original Message----- >>>>> From: Stewart Bryant [mailto:stbryant@cisco.com] >>>>> Sent: Monday, January 22, 2007 7:35 AM >>>>> To: pwe3 >>>>> Subject: [PWE3] VCCV-12 last call >>>>> >>>>> >>>>> This is the start of last call for >>>>> >>>>> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >>>>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >>>>> >>>>> last call will end 6th February. >>>>> >>>>> There are a couple of issues that I have with regard to >> IANA policy >>>>> that is raised by this draft, but I will ask my questions >> in another >>>>> thread. >>>>> >>>>> Regards >>>>> >>>>> Stewart >>>>> >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >>>> _______________________________________________ >>>> pwe3 mailing list >>>> pwe3@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >> _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 10:25:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASwZ-0000sX-Lg; Fri, 26 Jan 2007 10:24:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASwY-0000sA-N0 for pwe3@ietf.org; Fri, 26 Jan 2007 10:24:46 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASwX-0004yH-9y for pwe3@ietf.org; Fri, 26 Jan 2007 10:24:46 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 16:24:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QFOi73025746; Fri, 26 Jan 2007 16:24:44 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QFOhC8010178; Fri, 26 Jan 2007 16:24:44 +0100 (MET) Message-ID: <45BA1D36.7060003@cisco.com> Date: Fri, 26 Jan 2007 15:24:38 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "O'Connor, Don" Subject: Re: [PWE3] VCCV-12 last call References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3638; t=1169825084; x=1170689084; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20; bh=uXgs3OkO2kh5+a0SfShatHYuMFkdBUSBP7DlkeM5zkc=; b=ZdB5NzW/e165F+3aR3AvNNnd6AJnfesjO5H0LaQ37OZw7IKlG96pmXnXUFu+St2fcdfS7pbU DNWtDdBfZAfIYQVLA1RqVwhZrQgHaPJsHpOn8DJRg0IwNSCz4T++zkNc; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "Thomas D. Nadeau" , pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I think that there are many cases where it's reasonable to use more than one connectivity verifications mode. For example one mode that synchronises a lot of state and a second lightwight mode that does fast a fast simple connectivity check. Stewart O'Connor, Don wrote: > Tom > > Section 7 indicates that only one CC mode can be used - > > "In particular, once a valid CC Type is used by a PE (traffic > sent using that encapsulation), the PE MUST NOT send any > traffic down another CC Type encapsulation." > > There is no statement that only one CV Type can be used. However the > current CV precedence rules in Section 7 imply that there is a > restriction that only one CV mode can be used concurrently. > > I believe that it would be useful to have a CV mode with concurrent LSP > Ping and BFD. So my request is to add a code point for the following > > LSP Ping + BFD for fault detection only > > I would also suggest giving this code point the highest precedence in > the Section 7 CV precedence table > > Regards > > Don > > ------------------------------------------------------------------------ > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thu 1/25/2007 1:15 PM > To: O'Connor, Don > Cc: Stewart Bryant; pwe3 > Subject: Re: [PWE3] VCCV-12 last call > > > On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > > > My reading of VCCV - 12 is that > > > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that > > draft-ietf-bfd-mpls-03.txt. is not listed among the references > > BFD-base is only required because the bootstrapping rules > required to > setup BFD/VCCV are single-hop style. > > > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP > > Ping, LSP Ping, or BFD (Base). So it is not possible to support > > MPLS BFD which enables concurrent use of LSP Ping and BFD > > You do not negotiate anything per se; you advertise capabilities for > VCCV. You may advertise none, one or all of the different CC/CV > combinations, > which means you are willing to accept any of those combinations > (within the > rules stipulated in the draft). The receiving side is then free to send > any of those combinations (within the rules stipulated in the draft), > but > once one is successfully sent (and acked), no others are allowed, and no > "re-negotiation" is allowed without bringing down the PW. The latter > comes > specifically from the rules stipulated in RFC 4447. > > --Tom > > > > > > > Is my understanding accurate ? > > > > Regards > > > > Don > > > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Monday, January 22, 2007 7:35 AM > > To: pwe3 > > Subject: [PWE3] VCCV-12 last call > > > > > > This is the start of last call for > > > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > > > last call will end 6th February. > > > > There are a couple of issues that I have with regard to > > IANA policy that is raised by this draft, but I will > > ask my questions in another thread. > > > > Regards > > > > Stewart > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 10:34:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT5U-0004Sp-6f; Fri, 26 Jan 2007 10:34:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT5S-0004Si-Vo for pwe3@ietf.org; Fri, 26 Jan 2007 10:33:58 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAT5Q-0006Ka-4Y for pwe3@ietf.org; Fri, 26 Jan 2007 10:33:58 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2007 07:33:55 -0800 X-IronPort-AV: i="4.13,243,1167638400"; d="scan'208,217"; a="105775925:sNHT86008455" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QFXtpR007628; Fri, 26 Jan 2007 07:33:55 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QFXmH8023039; Fri, 26 Jan 2007 07:33:53 -0800 (PST) Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 10:33:49 -0500 Received: from 161.44.193.137 ([161.44.193.137]) by xmb-rtp-202.amer.cisco.com ([64.102.31.52]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 15:33:49 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Jan 2007 10:33:44 -0500 Subject: Re: [PWE3] VCCV-12 last call From: Danny Prairie To: "O'Connor, Don" , "Thomas D. Nadeau" Message-ID: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdAtS9n51FWTsapQtS99gDhKUgHYQAG1h4UACO1Qxc= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 26 Jan 2007 15:33:49.0565 (UTC) FILETIME=[603CE2D0:01C7415F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10134; t=1169825635; x=1170689635; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dprairie@cisco.com; z=From:=20Danny=20Prairie=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20 |To:=20=22O'Connor, =20Don=22=20, =0A=20=20=20= 20=20=20=20=20=22Thomas=20D.=20Nadeau=22=20 |Content-Type:=20multipart/alternative=3B=0A=09boundary=3D=22B_3252652424 _2884439=22 |Content-Transfer-Encoding:=20 |MIME-Version:=201.0; bh=sa4M/U+82Rx9sWwZ/3l9CytQJcYIdbOJNgafdPwcoyk=; b=DZWYks9TWlofdJ0d/4EcuV9J+z5pQq1Z3TUdBamV0RSlA/8/GFbgg1lpLYVXaS26Y3wLF64T kqTsN2VwxNhudPC/zvGyx7cQZzrmFbso1lq8TdkrMLJVs7X0EnbD35OtB398AYHXDZdIpimu20 qkLL7E9CxqfbBcd1us9RwaZwE=; Authentication-Results: sj-dkim-1; header.From=dprairie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 1.6 (+) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: pwe3 , Stewart Bryant X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1797154182==" Errors-To: pwe3-bounces@ietf.org > 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. --===============1797154182== Content-type: multipart/alternative; boundary="B_3252652424_2884439" > 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_3252652424_2884439 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Don, Good point about the CV. That being said, I would advocate not encoding the allowed combinations explicitly, but rather advertise the capabilities of the node, and have the peer decide which type of verification operations it will perform, potentially also including the use of BFD and LSP Ping concurrently. Regards, Danny On 1/25/07 5:46 PM, "O'Connor, Don" wrote: > Tom > > Section 7 indicates that only one CC mode can be used - > > "In particular, once a valid CC Type is used by a PE (traffic > sent using that encapsulation), the PE MUST NOT send any > traffic down another CC Type encapsulation." > > There is no statement that only one CV Type can be used. However the current > CV precedence rules in Section 7 imply that there is a restriction that only > one CV mode can be used concurrently. > > I believe that it would be useful to have a CV mode with concurrent LSP Ping > and BFD. So my request is to add a code point for the following > > LSP Ping + BFD for fault detection only > > I would also suggest giving this code point the highest precedence in the > Section 7 CV precedence table > > Regards > > Don > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thu 1/25/2007 1:15 PM > To: O'Connor, Don > Cc: Stewart Bryant; pwe3 > Subject: Re: [PWE3] VCCV-12 last call > > > > On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > >> > My reading of VCCV - 12 is that >> > >> > 1) It only supports BFD Base and not MPLS BFD. It can be noted that >> > draft-ietf-bfd-mpls-03.txt. is not listed among the references > > BFD-base is only required because the bootstrapping rules required to > setup BFD/VCCV are single-hop style. > >> > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP >> > Ping, LSP Ping, or BFD (Base). So it is not possible to support >> > MPLS BFD which enables concurrent use of LSP Ping and BFD > > You do not negotiate anything per se; you advertise capabilities for > VCCV. You may advertise none, one or all of the different CC/CV > combinations, > which means you are willing to accept any of those combinations > (within the > rules stipulated in the draft). The receiving side is then free to send > any of those combinations (within the rules stipulated in the draft), > but > once one is successfully sent (and acked), no others are allowed, and no > "re-negotiation" is allowed without bringing down the PW. The latter > comes > specifically from the rules stipulated in RFC 4447. > > --Tom > > > >> > >> > Is my understanding accurate ? >> > >> > Regards >> > >> > Don >> > >> > -----Original Message----- >> > From: Stewart Bryant [mailto:stbryant@cisco.com] >> > Sent: Monday, January 22, 2007 7:35 AM >> > To: pwe3 >> > Subject: [PWE3] VCCV-12 last call >> > >> > >> > This is the start of last call for >> > >> > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >> > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >> > >> > last call will end 6th February. >> > >> > There are a couple of issues that I have with regard to >> > IANA policy that is raised by this draft, but I will >> > ask my questions in another thread. >> > >> > Regards >> > >> > Stewart >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www1.ietf.org/mailman/listinfo/pwe3 >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --B_3252652424_2884439 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [PWE3] VCCV-12 last call Hi Do= n,

Good point about the CV. That being said, I would advocate not encoding the= allowed combinations explicitly, but rather advertise the capabilities of t= he node, and have the peer decide which type of verification operations it w= ill perform, potentially also including the use of BFD and LSP Ping concurre= ntly.

Regards,

Danny


On 1/25/07 5:46 PM, "O'Connor, Don" <don.oconnor@us.fujitsu.co= m> wrote:

Tom
Section 7 indicates that only one CC mode can be = used -

"In particular, once a valid CC Type is used= by a PE (traffic
   sent using that encapsulation), the PE MUST NOT send any<= BR>    traffic down another CC Type encapsulation."
There is no statement that only one CV Type can b= e used. However the current CV precedence rules in Section 7 imply that ther= e is a restriction that only one CV mode can be used concurrently.

I believe that it would be useful to have a CV mo= de with concurrent LSP Ping and BFD. So my request is to add a code point fo= r the following

LSP Ping + BFD for fault detection only
I would also suggest giving this code point the h= ighest precedence in the Section 7 CV precedence table
Regards
Don

From:<= /B> Thomas D. Nadeau [mailto:tnadeau@cis= co.com]
Sent: Thu 1/25/2007 1:15 PM
To: O'Connor, Don
Cc: Stewart Bryant; pwe3
Subject: Re: [PWE3] VCCV-12 last call



On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote:

> My reading of VCCV - 12 is that
>
> 1) It only supports BFD Base and not MPLS BFD. It can be noted that > draft-ietf-bfd-mpls-03.txt. is not listed among the references

        BFD-base is only required b= ecause the bootstrapping rules required to
setup BFD/VCCV are single-hop style.

> 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP > Ping, LSP Ping, or BFD (Base). So it is not possible to support
> MPLS BFD which enables concurrent use of LSP Ping and BFD

        You do not negotiate anythi= ng per se; you advertise capabilities for
VCCV. You may advertise none, one or all of the different CC/CV
combinations,
which means you are willing to accept any of those combinations
(within the
rules stipulated in the draft). The receiving side is then free to send
any of those combinations (within the rules stipulated in the draft),
but
once one is successfully sent (and acked), no others are allowed, and no "re-negotiation" is allowed without bringing down the PW.  T= he latter
comes
specifically from the rules stipulated in RFC 4447.

        --Tom



>
> Is my understanding accurate ?
>
> Regards
>
> Don
>
> -----Original Message-----
> From: Stewart Bryant [mailto:stbr= yant@cisco.com]
> Sent: Monday, January 22, 2007 7:35 AM
> To: pwe3
> Subject: [PWE3] VCCV-12 last call
>
>
> This is the start of last call for
>
> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
>
> last call will end 6th February.
>
> There are a couple of issues that I have with regard to
> IANA policy that is raised by this draft, but I will
> ask my questions in another thread.
>
> Regards
>
> Stewart
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3

____________________= ___________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3

 --B_3252652424_2884439-- --===============1797154182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1797154182==-- From pwe3-bounces@ietf.org Fri Jan 26 10:36:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT7n-00063T-Mp; Fri, 26 Jan 2007 10:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT7l-00063O-U0 for pwe3@ietf.org; Fri, 26 Jan 2007 10:36:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAT7k-0006hL-CE for pwe3@ietf.org; Fri, 26 Jan 2007 10:36:21 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 16:36:20 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QFaJsQ029155; Fri, 26 Jan 2007 16:36:19 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QFaJC8013767; Fri, 26 Jan 2007 16:36:19 +0100 (MET) Message-ID: <45BA1FED.2050507@cisco.com> Date: Fri, 26 Jan 2007 15:36:13 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Prairie Subject: Re: [PWE3] VCCV-12 last call References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4186; t=1169825779; x=1170689779; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20; bh=YZlZf/IVfgjJp5bYjq2UFlqZyrI0o04R8WkytetppA4=; b=eSKRNgONsFH6eN4Olr9uJ03ka/N10mLd9Z2IgQ33MvMQSE/mYo+WuyijhMLBSKTiVPKMt4ZU zuGS/9fmhOShV0Co3MRMAa5R012cYNppO8oV4RH2RwG2bgRXWh6LR3Ok; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I agree - Stewart Danny Prairie wrote: > Hi Don, > > Good point about the CV. That being said, I would advocate not encoding > the allowed combinations explicitly, but rather advertise the > capabilities of the node, and have the peer decide which type of > verification operations it will perform, potentially also including the > use of BFD and LSP Ping concurrently. > > Regards, > > Danny > > > On 1/25/07 5:46 PM, "O'Connor, Don" wrote: > > Tom > > Section 7 indicates that only one CC mode can be used - > > "In particular, once a valid CC Type is used by a PE (traffic > sent using that encapsulation), the PE MUST NOT send any > traffic down another CC Type encapsulation." > > There is no statement that only one CV Type can be used. However the > current CV precedence rules in Section 7 imply that there is a > restriction that only one CV mode can be used concurrently. > > I believe that it would be useful to have a CV mode with concurrent > LSP Ping and BFD. So my request is to add a code point for the > following > > LSP Ping + BFD for fault detection only > > I would also suggest giving this code point the highest precedence > in the Section 7 CV precedence table > > Regards > > Don > > ------------------------------------------------------------------------ > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thu 1/25/2007 1:15 PM > To: O'Connor, Don > Cc: Stewart Bryant; pwe3 > Subject: Re: [PWE3] VCCV-12 last call > > > > On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > >> My reading of VCCV - 12 is that >> >> 1) It only supports BFD Base and not MPLS BFD. It can be noted that >> draft-ietf-bfd-mpls-03.txt. is not listed among the references > > BFD-base is only required because the bootstrapping rules > required to > setup BFD/VCCV are single-hop style. > >> 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP >> Ping, LSP Ping, or BFD (Base). So it is not possible to support >> MPLS BFD which enables concurrent use of LSP Ping and BFD > > You do not negotiate anything per se; you advertise > capabilities for > VCCV. You may advertise none, one or all of the different CC/CV > combinations, > which means you are willing to accept any of those combinations > (within the > rules stipulated in the draft). The receiving side is then free to send > any of those combinations (within the rules stipulated in the draft), > but > once one is successfully sent (and acked), no others are allowed, and no > "re-negotiation" is allowed without bringing down the PW. The latter > comes > specifically from the rules stipulated in RFC 4447. > > --Tom > > > >> >> Is my understanding accurate ? >> >> Regards >> >> Don >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Monday, January 22, 2007 7:35 AM >> To: pwe3 >> Subject: [PWE3] VCCV-12 last call >> >> >> This is the start of last call for >> >> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >> >> last call will end 6th February. >> >> There are a couple of issues that I have with regard to >> IANA policy that is raised by this draft, but I will >> ask my questions in another thread. >> >> Regards >> >> Stewart >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 > > ------------------------------------------------------------------------ > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 11:31:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATyP-0003H2-3T; Fri, 26 Jan 2007 11:30:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATyN-0003Gq-1D for pwe3@ietf.org; Fri, 26 Jan 2007 11:30:43 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATyK-0008NW-Lp for pwe3@ietf.org; Fri, 26 Jan 2007 11:30:43 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2007 08:30:41 -0800 X-IronPort-AV: i="4.13,244,1167638400"; d="scan'208"; a="51678291:sNHT47110240" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QGUesw013980; Fri, 26 Jan 2007 11:30:40 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QGUYOO018292; Fri, 26 Jan 2007 11:30:40 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:30:36 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:30:35 -0500 In-Reply-To: <45B4D989.4080302@cisco.com> References: <45B4D989.4080302@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4ABDDC6A-72CB-473E-9124-B7A41CF4CE18@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 IANA questions Date: Fri, 26 Jan 2007 11:30:33 -0500 To: Stewart Bryant X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 16:30:35.0822 (UTC) FILETIME=[4E8674E0:01C74167] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2400; t=1169829040; x=1170693040; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20IANA=20questions |Sender:=20 |To:=20Stewart=20Bryant=20; bh=VLRqKaBeuV1nmDUlYJNqCzqlvNeKAMyYUcuy1nXsU/A=; b=qCUCLOXmtHiYBN9Ek6zti6Ifa9XvM6D5G/mVQ7y2Ysf757RQzRjgwF5dJKPziHuUejM0zGEU fk7VPnjuTxXUuX40jKHwJ5NN6pnNB2U/G2VRtL/56WkcOperuF4tCEPK; Authentication-Results: rtp-dkim-1; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi, > The first question that I have is what policy should be > applied to the selection of values for Pseudowire > Associated Channel Types > > We currently have two allocations > > 0x21 Associated Channel carries an IPv4 packet [RFC4385] > 0x57 Associated Channel carries an IPv6 packet [RFC4385] > > These were chosen to be identical to the values assigned > the Assigned PPP DLL Protocol Numbers registry, and the > choice goes back to the days when we were thinking of using > that registry. > > Now going forward, what policy does the WG think should > be used. Given that we have two independent registries > we had neither hope nor need of keeping then in sync. So > we can either > > 1) Start at 1 (reserving 0 for a rainy day) and continue up. > > 2) Where there is a similar identifier in Assigned PPP DLL > Protocol Numbers use it otherwise try to pick one that > will not be used by PPP. > > The proposal by the VCCV authors was to use 7 for BFD > Without IP/UDP Header (which PPP says is transparency > inefficient and therefore is unlikely to ever be used). > > (1) will result in a more "compact registry", if you can > call a registry with 0x55 empty entries compact. (2) is > consistent with what we did in the past. > > Anyone have any thoughts? I think it might be useful to start a new registry so that things are cleaner. However, I am worried about existing implementations of VCCV, so I would like to keep the actual values the same if we choose to do this. > My second question concerns the several small registries > that are set up by VCCV > > Control Channel Types (8 possible values 3 used) > Connectivity Verification Types (CV Types) (8 possible values 6 used) > CC Types (8 possible values 1 used) > > There are currently under expert review. However with > registries this small I am inclined to suggest that we > should make them IETF consensus? I personally prefer expert review for that very reason, which is why the document is written as it is. There are not a lot of values to play with and so I think we need to be very careful about how the values are allocated in the future. --Tom > > Anyone have any thoughts. > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 12:51:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVDK-0005Ku-8S; Fri, 26 Jan 2007 12:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVDJ-0005Ko-6U for pwe3@ietf.org; Fri, 26 Jan 2007 12:50:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVDH-00022T-S9 for pwe3@ietf.org; Fri, 26 Jan 2007 12:50:13 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 18:50:12 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0QHoBtS013427; Fri, 26 Jan 2007 18:50:11 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QHoAC8020717; Fri, 26 Jan 2007 18:50:10 +0100 (MET) Message-ID: <45BA3F4A.5000404@cisco.com> Date: Fri, 26 Jan 2007 17:50:02 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 IANA questions References: <45B4D989.4080302@cisco.com> <4ABDDC6A-72CB-473E-9124-B7A41CF4CE18@cisco.com> In-Reply-To: <4ABDDC6A-72CB-473E-9124-B7A41CF4CE18@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2734; t=1169833811; x=1170697811; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20IANA=20questions |Sender:=20; bh=1ZXT8fT96WG3Rv4UoUtXvTlAly166svhBzSn8ByUIp8=; b=DmOdQGScYzMEcP437DtgRko99phXMQ9qupoPV0PxTpOLcooK2C1ZIpjSXlcds22DYrnJdUxt 8n/PHhAnrX3SbWjgod+oApUi5lnucI8ZLA4rk99WtYQ0ZLsSrSsdXuHi; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thomas D. Nadeau wrote: > > Hi, > > >> The first question that I have is what policy should be >> applied to the selection of values for Pseudowire >> Associated Channel Types >> >> We currently have two allocations >> >> 0x21 Associated Channel carries an IPv4 packet [RFC4385] >> 0x57 Associated Channel carries an IPv6 packet [RFC4385] >> >> These were chosen to be identical to the values assigned >> the Assigned PPP DLL Protocol Numbers registry, and the >> choice goes back to the days when we were thinking of using >> that registry. >> >> Now going forward, what policy does the WG think should >> be used. Given that we have two independent registries >> we had neither hope nor need of keeping then in sync. So >> we can either >> >> 1) Start at 1 (reserving 0 for a rainy day) and continue up. >> >> 2) Where there is a similar identifier in Assigned PPP DLL >> Protocol Numbers use it otherwise try to pick one that >> will not be used by PPP. >> >> The proposal by the VCCV authors was to use 7 for BFD >> Without IP/UDP Header (which PPP says is transparency >> inefficient and therefore is unlikely to ever be used). >> >> (1) will result in a more "compact registry", if you can >> call a registry with 0x55 empty entries compact. (2) is >> consistent with what we did in the past. >> >> Anyone have any thoughts? > > > I think it might be useful to start a new registry > so that things are cleaner. However, I am worried about > existing implementations of VCCV, so I would like to > keep the actual values the same if we choose to do this. Whatever we do we keep 0x21 and 0x57. It the policy for future ones I was asking about. > >> My second question concerns the several small registries >> that are set up by VCCV >> >> Control Channel Types (8 possible values 3 used) >> Connectivity Verification Types (CV Types) (8 possible values 6 used) >> CC Types (8 possible values 1 used) >> >> There are currently under expert review. However with >> registries this small I am inclined to suggest that we >> should make them IETF consensus? > > > I personally prefer expert review for that very reason, > which is why the document is written as it is. There > are not a lot of values to play with and so I think we need > to be very careful about how the values are allocated in > the future. > > --Tom IETF consensus means you need an RFC (I think a stds track RFC) and therefore is a higher hurdle than expert review. No expert would decline a code point to a stds track RFC. Sure, they would be involved in the discussion, but they would go with the outcome of the IETF deliberation. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 13:09:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVVk-00075U-Lb; Fri, 26 Jan 2007 13:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVVj-00075M-L5 for pwe3@ietf.org; Fri, 26 Jan 2007 13:09:15 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVVi-0004jD-Bv for pwe3@ietf.org; Fri, 26 Jan 2007 13:09:15 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2007 13:09:14 -0500 X-IronPort-AV: i="4.13,244,1167627600"; d="scan'208"; a="112563209:sNHT49981768" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0QI9EMQ016466; Fri, 26 Jan 2007 13:09:14 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QI99Vf015648; Fri, 26 Jan 2007 13:09:14 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 13:09:10 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 13:09:10 -0500 In-Reply-To: <45BA3F4A.5000404@cisco.com> References: <45B4D989.4080302@cisco.com> <4ABDDC6A-72CB-473E-9124-B7A41CF4CE18@cisco.com> <45BA3F4A.5000404@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25D6B3C9-2942-4EF0-9E6C-5646AA1DAE95@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 IANA questions Date: Fri, 26 Jan 2007 13:09:10 -0500 To: Stewart Bryant X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 18:09:10.0439 (UTC) FILETIME=[13E96370:01C74175] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3053; t=1169834954; x=1170698954; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20IANA=20questions |Sender:=20 |To:=20Stewart=20Bryant=20; bh=b+J7kbgDmeFHvkokeCu9+iPLSgoHHbL4pMkyPD/CP+w=; b=Ku8lzjg1kBnpvHd8VoBG5oQavMznbuf1Rw0e/S1+XVmCwwlqeUh36vim3jHswTJwJ01Tfc1w NNQgZ/ckn1seko0a5IuKN1k2OrX7uoUw4WpAbIGbxSNlvXjymKiKJbdZ; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Jan 26, 2007, at 12:50 PM, Stewart Bryant wrote: > Thomas D. Nadeau wrote: > >> Hi, >>> The first question that I have is what policy should be >>> applied to the selection of values for Pseudowire >>> Associated Channel Types >>> >>> We currently have two allocations >>> >>> 0x21 Associated Channel carries an IPv4 packet [RFC4385] >>> 0x57 Associated Channel carries an IPv6 packet [RFC4385] >>> >>> These were chosen to be identical to the values assigned >>> the Assigned PPP DLL Protocol Numbers registry, and the >>> choice goes back to the days when we were thinking of using >>> that registry. >>> >>> Now going forward, what policy does the WG think should >>> be used. Given that we have two independent registries >>> we had neither hope nor need of keeping then in sync. So >>> we can either >>> >>> 1) Start at 1 (reserving 0 for a rainy day) and continue up. >>> >>> 2) Where there is a similar identifier in Assigned PPP DLL >>> Protocol Numbers use it otherwise try to pick one that >>> will not be used by PPP. >>> >>> The proposal by the VCCV authors was to use 7 for BFD >>> Without IP/UDP Header (which PPP says is transparency >>> inefficient and therefore is unlikely to ever be used). >>> >>> (1) will result in a more "compact registry", if you can >>> call a registry with 0x55 empty entries compact. (2) is >>> consistent with what we did in the past. >>> >>> Anyone have any thoughts? >> I think it might be useful to start a new registry >> so that things are cleaner. However, I am worried about >> existing implementations of VCCV, so I would like to >> keep the actual values the same if we choose to do this. > > Whatever we do we keep 0x21 and 0x57. It the policy > for future ones I was asking about. > >>> My second question concerns the several small registries >>> that are set up by VCCV >>> >>> Control Channel Types (8 possible values 3 used) >>> Connectivity Verification Types (CV Types) (8 possible values 6 >>> used) >>> CC Types (8 possible values 1 used) >>> >>> There are currently under expert review. However with >>> registries this small I am inclined to suggest that we >>> should make them IETF consensus? >> I personally prefer expert review for that very reason, >> which is why the document is written as it is. There >> are not a lot of values to play with and so I think we need >> to be very careful about how the values are allocated in >> the future. >> --Tom > > IETF consensus means you need an RFC (I think a stds track > RFC) and therefore is a higher hurdle than expert review. > No expert would decline a code point to a stds track RFC. > Sure, they would be involved in the discussion, but they > would go with the outcome of the IETF deliberation. I didn't realize that. I thought it was the other way around. If that is the case, then I agree with you that it is good to have an RFC that explains how the new code point is to be used. --Tom > > - Stewart > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 13:10:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVX9-00082Q-Ju; Fri, 26 Jan 2007 13:10:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVX8-00081E-Ap for pwe3@ietf.org; Fri, 26 Jan 2007 13:10:42 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVX6-00057x-Vu for pwe3@ietf.org; Fri, 26 Jan 2007 13:10:42 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id l0QIAe1Z057759; Fri, 26 Jan 2007 10:10:40 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l0QIAeB80092; Fri, 26 Jan 2007 10:10:40 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200701261810.l0QIAeB80092@merlot.juniper.net> To: Stewart Bryant Subject: Re: [PWE3] Response to liasion stement G.8110.1 (TMPLS) In-Reply-To: Your message of "Thu, 25 Jan 2007 16:43:43 GMT." <45B8DE3F.2070300@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73579.1169835040.1@juniper.net> Date: Fri, 26 Jan 2007 10:10:40 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, > The following liaison statement is the text of the > ITU TMPLS design > > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=286 > > At IETF67 we agreed to liaise draft-bryant-pwe3-mpls-transport-00 > to ITU SG15 > > I think that we should respond with something like: > > Thank you for liaising the text of G.8110.1. > > Looking at the requirements for TMPLS, it is our view > that these can be met with existing widely deployed > designs based on the specifications produced by the > IETF PWE3 WG. > > We attach the following IETF draft which was > written by members of the PWE3 WG and describes > how to satisfy specified TMPLS requirement using > the mechanisms already specified by the IETF. > > We request that you perform a detailed review of > draft-bryant-pwe3-mpls-transport-00 so that we > can determine what - if any - amendments we need > to make to fully satisfy the TMPLS requirement > with the existing well established and deployed > pseudowire protocols. Agreed. Yakov. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 13:13:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVZY-0002JN-Gl; Fri, 26 Jan 2007 13:13:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVZX-0002J9-85 for pwe3@ietf.org; Fri, 26 Jan 2007 13:13:11 -0500 Received: from audl951.usa.alcatel.com ([143.209.238.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVZV-0005ZZ-DI for pwe3@ietf.org; Fri, 26 Jan 2007 13:13:11 -0500 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id l0QID5Ul009960; Fri, 26 Jan 2007 12:13:05 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 26 Jan 2007 12:13:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] VCCV-12 last call Date: Fri, 26 Jan 2007 12:12:37 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdAtS9n51FWTsapQtS99gDhKUgHYQAG1h4UACO1QxcABFD3MA== References: From: "AISSAOUI Mustapha" To: "Danny Prairie" , "O'Connor, Don" , "Thomas D. Nadeau" X-OriginalArrivalTime: 26 Jan 2007 18:13:05.0773 (UTC) FILETIME=[A02E81D0:01C74175] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 Cc: pwe3 , Stewart Bryant X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0464224271==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0464224271== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74175.8F5FA0B6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74175.8F5FA0B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Danny, I made the same proposal in my LC comments. The problem is what you are proposing is not allowed by the text in Section 4. The first and second paragraphs read: " VCCV can support several types of connectivity verification types (CV types) or protocols within several possible control channel as=20 defined by the control channel type (CC types), but it does not=20 support the use of more than one combination of both concurrently.=20 The specific type or types of VCCV packets accepted by a router are indicated during capability advertisement as described in sections=20 5.5 and 6.2. The various VCCV CV types supported MUST be used only when they apply to the context of the PW demultiplexor in use. For example, LSP Ping type should only be used when MPLS is utilized as the PSN. =20 Once a set of capabilities if advertised, the specific one chosen=20 based on the preferred order specified below in section 7. Once=20 a specific CC and CV type combination has been chosen, transmitted=20 and replied to, this type combination MUST be the only one used=20 until such time as the Pseudowire is re-signaled."=20 =20 Then, the first paragraph in Section 7 reads: " When a PE receives a VCCV capability advertisement, the advertisement may potentially contain more than one CC or CV Type. In this case, it MUST use the following rules when=20 choosing which CC or CV type to use. It may only choose one mode based on the rules stipulated in sections 4 and 5 above. In particular, once a valid CC Type is used by a PE (traffic sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation." =20 This suggests that a PE will pick a single CC type, which we want to enforce, and a single CV type, which we want to relax for LSP Ping and BFD type 0x04. =20 Furthermore, I cannot find any text which explicitly states that a PE compares VCCV capabilities it advertized and those it received from its peer to perform the match. After the match is made, then the PE picks up a single CC type from the common set following the precedence orders. For CV types, the PE can pick up more than one as long as you abide by the restrictions governing the use of the BFD types, i.e.,: 1. If both types 0x08 and 0x04 are part of the match, ignore 0x04. 2. If both types 0x10 and 0x20 are part of the match, ignore 0x10 (there is a typo in the paragraph before last in Section 4 which said that 0x20 must be ignored). 3. If 0x08 or 0x20 is selected, status is converyed using BFD. 4. Types 0x08 and 0x020 should not be selected if the PE uses LDP status notifications. =20 5. If type 0x04 or 0x10 is selected, status should still be conveyed using LDP status notifications. =20 Mustapha. ________________________________ From: Danny Prairie [mailto:dprairie@cisco.com]=20 Sent: Friday, January 26, 2007 10:34 AM To: O'Connor, Don; Thomas D. Nadeau Cc: pwe3; Stewart Bryant Subject: Re: [PWE3] VCCV-12 last call =09 =09 Hi Don, =09 Good point about the CV. That being said, I would advocate not encoding the allowed combinations explicitly, but rather advertise the capabilities of the node, and have the peer decide which type of verification operations it will perform, potentially also including the use of BFD and LSP Ping concurrently. =09 Regards, =09 Danny =09 =09 On 1/25/07 5:46 PM, "O'Connor, Don" wrote: =09 =09 Tom =09 Section 7 indicates that only one CC mode can be used -=20 =09 "In particular, once a valid CC Type is used by a PE (traffic=20 sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation." =09 There is no statement that only one CV Type can be used. However the current CV precedence rules in Section 7 imply that there is a restriction that only one CV mode can be used concurrently.=20 =09 I believe that it would be useful to have a CV mode with concurrent LSP Ping and BFD. So my request is to add a code point for the following=20 =09 LSP Ping + BFD for fault detection only =09 I would also suggest giving this code point the highest precedence in the Section 7 CV precedence table =09 Regards =09 Don =09 =09 ________________________________ From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thu 1/25/2007 1:15 PM To: O'Connor, Don Cc: Stewart Bryant; pwe3 Subject: Re: [PWE3] VCCV-12 last call =09 =09 =09 On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: =09 > My reading of VCCV - 12 is that > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that=20 > draft-ietf-bfd-mpls-03.txt. is not listed among the references =09 BFD-base is only required because the bootstrapping rules required to setup BFD/VCCV are single-hop style. =09 > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP=20 > Ping, LSP Ping, or BFD (Base). So it is not possible to support=20 > MPLS BFD which enables concurrent use of LSP Ping and BFD =09 You do not negotiate anything per se; you advertise capabilities for VCCV. You may advertise none, one or all of the different CC/CV=20 combinations, which means you are willing to accept any of those combinations=20 (within the rules stipulated in the draft). The receiving side is then free to send any of those combinations (within the rules stipulated in the draft),=20 but once one is successfully sent (and acked), no others are allowed, and no "re-negotiation" is allowed without bringing down the PW. The latter=20 comes specifically from the rules stipulated in RFC 4447. =09 --Tom =09 =09 =09 > > Is my understanding accurate ? > > Regards > > Don > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, January 22, 2007 7:35 AM > To: pwe3 > Subject: [PWE3] VCCV-12 last call > > > This is the start of last call for > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > last call will end 6th February. > > There are a couple of issues that I have with regard to > IANA policy that is raised by this draft, but I will > ask my questions in another thread. > > Regards > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 =09 =09 ________________________________ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 =09 =09 =09 ------_=_NextPart_001_01C74175.8F5FA0B6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [PWE3] VCCV-12 last call
Danny,
I=20 made the same proposal in my LC comments. The problem is what you are = proposing=20 is not allowed by the text in Section 4. The first and second = paragraphs=20 read:
"  VCCV can support several types of connectivity = verification types=20 (CV
   types) or protocols within several possible control = channel=20 as
   defined by the control channel type (CC types), but = it does=20 not
   support the use of more than one combination of = both=20 concurrently.
   The specific type or types of VCCV = packets=20 accepted by a router are
   indicated during capability=20 advertisement as described in sections
   5.5 and 6.2. The = various=20 VCCV CV types supported MUST be used
   only when they = apply to the=20 context of the PW demultiplexor in use.
   For example, LSP = Ping=20 type should only be used when MPLS is utilized
   as the=20 PSN.
 
   Once a set of capabilities if advertised, the = specific one=20 chosen
   based on the preferred order specified below in = section=20 7. Once
   a specific CC and CV type combination has been = chosen,=20 transmitted
   and replied to, this type combination MUST = be the=20 only one used
   until such time as the Pseudowire is=20 re-signaled." 
 
Then, the first paragraph in Section 7 = reads:
"  When a PE receives a VCCV capability=20 advertisement,
   the advertisement may potentially contain = more=20 than one CC or
   CV Type. In this case, it MUST use the = following=20 rules when
   choosing which CC or CV type to use. It may = only=20 choose one mode
   based on the rules stipulated in = sections 4 and=20 5 above. In
   particular, once a valid CC Type is used by = a PE=20 (traffic
   sent using that encapsulation), the PE MUST NOT = send=20 any
   traffic down another CC Type=20 encapsulation."
 
This suggests that a PE will pick a single CC type, which we = want to=20 enforce, and a single CV type, which we want to relax for LSP Ping = and BFD=20 type 0x04.
 
Furthermore, I cannot find any text which explicitly = states=20 that a PE compares VCCV capabilities it advertized and those it received = from=20 its peer to perform the match. After the match is made, then the PE = picks up a=20 single CC type from the common set following the precedence orders. For = CV=20 types, the PE can pick up more than one as long as you = abide by=20 the restrictions governing the use of the BFD types, = i.e.,:
1.  If both types = 0x08 and 0x04=20 are part of the match, ignore 0x04.
2.  If both types 0x10 and 0x20 are part of the match, = ignore 0x10=20 (there is a typo in the paragraph before last in Section 4 which said = that 0x20=20 must be ignored).
3. If 0x08 or 0x20 is selected, status is converyed using=20 BFD.
4. Types 0x08 and 0x020 should not be selected if the = PE uses=20 LDP status notifications.  
5. If type 0x04 or 0x10 is selected, status should still be = conveyed=20 using LDP status notifications.
 
Mustapha.

From: Danny Prairie=20 [mailto:dprairie@cisco.com]
Sent: Friday, January 26, 2007 = 10:34=20 AM
To: O'Connor, Don; Thomas D. Nadeau
Cc: pwe3; = Stewart=20 Bryant
Subject: Re: [PWE3] VCCV-12 last = call

Hi Don,

Good point about the CV. That = being=20 said, I would advocate not encoding the allowed combinations = explicitly, but=20 rather advertise the capabilities of the node, and have the peer = decide which=20 type of verification operations it will perform, potentially also = including=20 the use of BFD and LSP Ping=20 concurrently.

Regards,

Danny


On 1/25/07 5:46 = PM,=20 "O'Connor, Don" <don.oconnor@us.fujitsu.com>=20 wrote:
Tom

Section 7=20 indicates that only one CC mode can be used -

"In = particular,=20 once a valid CC Type is used by a PE (traffic =
   sent=20 using that encapsulation), the PE MUST NOT send=20 any
   traffic down another CC Type=20 encapsulation."

There is no=20 statement that only one CV Type can be used. However the current CV=20 precedence rules in Section 7 imply that there is a restriction that = only=20 one CV mode can be used concurrently.

I = believe that=20 it would be useful to have a CV mode with concurrent LSP Ping and = BFD. So my=20 request is to add a code point for the following

LSP = Ping + BFD=20 for fault detection only

I = would also=20 suggest giving this code point the highest precedence in the Section = 7 CV=20 precedence table

Regards

Don

From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Se= nt:=20 Thu 1/25/2007 1:15 PM
To: O'Connor, Don
Cc: = Stewart=20 Bryant; pwe3
Subject: Re: [PWE3] VCCV-12 last = call



On Jan 23, 2007, at = 7:22 PM,=20 O'Connor, Don wrote:

> My reading of VCCV - 12 is=20 that
>
> 1) It only supports BFD Base and not MPLS BFD. = It can=20 be noted that
> draft-ietf-bfd-mpls-03.txt. is not listed = among the=20 = references

        BFD-bas= e=20 is only required because the bootstrapping rules required = to
setup=20 BFD/VCCV are single-hop style.

> 2) It is only possible to = negotiate (by LDP) one CV protocol - ICMP
> Ping, LSP Ping, = or BFD=20 (Base). So it is not possible to support
> MPLS BFD which = enables=20 concurrent use of LSP Ping and=20 BFD

        You do = not=20 negotiate anything per se; you advertise capabilities for
VCCV. = You may=20 advertise none, one or all of the different CC/CV =
combinations,
which=20 means you are willing to accept any of those combinations =
(within=20 the
rules stipulated in the draft). The receiving side is then = free to=20 send
any of those combinations (within the rules stipulated in = the=20 draft),
but
once one is successfully sent (and acked), no = others are=20 allowed, and no
"re-negotiation" is allowed without bringing down = the PW.=20  The latter
comes
specifically from the rules stipulated = in RFC=20 = 4447.

        --Tom


>
>=20 Is my understanding accurate ?
>
> = Regards
>
>=20 Don
>
> -----Original Message-----
> From: Stewart = Bryant=20 [mailto:stbryant@cisco.com]
>= ;=20 Sent: Monday, January 22, 2007 7:35 AM
> To: pwe3
> = Subject:=20 [PWE3] VCCV-12 last call
>
>
> This is the start = of last=20 call for
>
> Pseudo Wire Virtual Circuit Connectivity=20 Verification (VCCV)
> = http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
&g= t;
>=20 last call will end 6th February.
>
> There are a couple = of=20 issues that I have with regard to
> IANA policy that is raised = by this=20 draft, but I will
> ask my questions in another=20 thread.
>
> Regards
>
> = Stewart
>
>=20 _______________________________________________
> pwe3 mailing = list
> pwe3@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/pwe3
>
>=20 _______________________________________________
> pwe3 mailing = list
> pwe3@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3=20 mailing=20 = list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
<= /SPAN>

 ------_=_NextPart_001_01C74175.8F5FA0B6-- --===============0464224271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0464224271==-- From pwe3-bounces@ietf.org Fri Jan 26 13:59:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWHu-0007cc-G4; Fri, 26 Jan 2007 13:59:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWHr-0007bC-8n for pwe3@ietf.org; Fri, 26 Jan 2007 13:58:59 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWHd-00040G-DL for pwe3@ietf.org; Fri, 26 Jan 2007 13:58:59 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2007 10:58:45 -0800 X-IronPort-AV: i="4.13,244,1167638400"; d="scan'208,217"; a="51689814:sNHT112100180" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QIwjjw003947; Fri, 26 Jan 2007 13:58:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QIwiOA021311; Fri, 26 Jan 2007 13:58:44 -0500 (EST) Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 13:58:44 -0500 Received: from 161.44.193.137 ([161.44.193.137]) by xmb-rtp-202.amer.cisco.com ([64.102.31.52]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 18:58:43 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Jan 2007 13:58:40 -0500 Subject: Re: [PWE3] VCCV-12 last call From: Danny Prairie To: AISSAOUI Mustapha , "O'Connor, Don" , "Tom Nadeau (tnadeau)" Message-ID: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdAtS9n51FWTsapQtS99gDhKUgHYQAG1h4UACO1QxcABFD3MAAC10jc In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 26 Jan 2007 18:58:44.0682 (UTC) FILETIME=[00B2DAA0:01C7417C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19393; t=1169837925; x=1170701925; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dprairie@cisco.com; z=From:=20Danny=20Prairie=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20 |To:=20AISSAOUI=20Mustapha=20, =0A=2 0=20=20=20=20=20=20=20=22O'Connor, =20Don=22=20 , =0A=20=20=20=20=20=20=20=20=22Tom=20Nadeau=20(tnadeau)=22=20; bh=YHTQpvC2rFfe9yKRXLgVupfDP9cxJRAvWRdl49qU+zQ=; b=JQ2uf8IKMCTw7TJqyFOOHu3uFopm3QaIPS8ALG5cG7wO9sXTwyll8xeXcSRuYSnZUZ8pfCxj wiNFPxTpSl02QJwpFb0SPoIlYTY6DA76oTPonyNZMOr83hf1wG1u/9zn; Authentication-Results: rtp-dkim-1; header.From=dprairie@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.7 (+) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 Cc: pwe3 , "Stewart Bryant \(stbryant\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0369311474==" Errors-To: pwe3-bounces@ietf.org > 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. --===============0369311474== Content-type: multipart/alternative; boundary="B_3252664720_3626385" > 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_3252664720_3626385 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Mustapha, You are correct, we need to change the below text to reflect the behavioural change I suggested in my previous E-mail. Regards, Danny On 1/26/07 1:12 PM, "AISSAOUI Mustapha" wrote: > Danny, > I made the same proposal in my LC comments. The problem is what you are > proposing is not allowed by the text in Section 4. The first and second > paragraphs read: > " VCCV can support several types of connectivity verification types (CV > types) or protocols within several possible control channel as > defined by the control channel type (CC types), but it does not > support the use of more than one combination of both concurrently. > The specific type or types of VCCV packets accepted by a router are > indicated during capability advertisement as described in sections > 5.5 and 6.2. The various VCCV CV types supported MUST be used > only when they apply to the context of the PW demultiplexor in use. > For example, LSP Ping type should only be used when MPLS is utilized > as the PSN. > > Once a set of capabilities if advertised, the specific one chosen > based on the preferred order specified below in section 7. Once > a specific CC and CV type combination has been chosen, transmitted > and replied to, this type combination MUST be the only one used > until such time as the Pseudowire is re-signaled." > > Then, the first paragraph in Section 7 reads: > " When a PE receives a VCCV capability advertisement, > the advertisement may potentially contain more than one CC or > CV Type. In this case, it MUST use the following rules when > choosing which CC or CV type to use. It may only choose one mode > based on the rules stipulated in sections 4 and 5 above. In > particular, once a valid CC Type is used by a PE (traffic > sent using that encapsulation), the PE MUST NOT send any > traffic down another CC Type encapsulation." > > This suggests that a PE will pick a single CC type, which we want to enforce, > and a single CV type, which we want to relax for LSP Ping and BFD type 0x04. > > Furthermore, I cannot find any text which explicitly states that a PE compares > VCCV capabilities it advertized and those it received from its peer to perform > the match. After the match is made, then the PE picks up a single CC type from > the common set following the precedence orders. For CV types, the PE can pick > up more than one as long as you abide by the restrictions governing the use of > the BFD types, i.e.,: > 1. If both types 0x08 and 0x04 are part of the match, ignore 0x04. > 2. If both types 0x10 and 0x20 are part of the match, ignore 0x10 (there is a > typo in the paragraph before last in Section 4 which said that 0x20 must be > ignored). > 3. If 0x08 or 0x20 is selected, status is converyed using BFD. > 4. Types 0x08 and 0x020 should not be selected if the PE uses LDP status > notifications. > 5. If type 0x04 or 0x10 is selected, status should still be conveyed using LDP > status notifications. > > Mustapha. > >> >> >> >> From: Danny Prairie [mailto:dprairie@cisco.com] >> Sent: Friday, January 26, 2007 10:34 AM >> To: O'Connor, Don; Thomas D. Nadeau >> Cc: pwe3; Stewart Bryant >> Subject: Re: [PWE3] VCCV-12 last call >> >> >> Hi Don, >> >> Good point about the CV. That being said, I would advocate not encoding the >> allowed combinations explicitly, but rather advertise the capabilities of >> the node, and have the peer decide which type of verification operations it >> will perform, potentially also including the use of BFD and LSP Ping >> concurrently. >> >> Regards, >> >> Danny >> >> >> On 1/25/07 5:46 PM, "O'Connor, Don" wrote: >> >> >>> Tom >>> >>> Section 7 indicates that only one CC mode can be used - >>> >>> "In particular, once a valid CC Type is used by a PE (traffic >>> sent using that encapsulation), the PE MUST NOT send any >>> traffic down another CC Type encapsulation." >>> >>> There is no statement that only one CV Type can be used. However the >>> current CV precedence rules in Section 7 imply that there is a restriction >>> that only one CV mode can be used concurrently. >>> >>> I believe that it would be useful to have a CV mode with concurrent LSP >>> Ping and BFD. So my request is to add a code point for the following >>> >>> LSP Ping + BFD for fault detection only >>> >>> I would also suggest giving this code point the highest precedence in the >>> Section 7 CV precedence table >>> >>> Regards >>> >>> Don >>> >>> >>> >>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>> Sent: Thu 1/25/2007 1:15 PM >>> To: O'Connor, Don >>> Cc: Stewart Bryant; pwe3 >>> Subject: Re: [PWE3] VCCV-12 last call >>> >>> >>> >>> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: >>> >>>> > My reading of VCCV - 12 is that >>>> > >>>> > 1) It only supports BFD Base and not MPLS BFD. It can be noted that >>>> > draft-ietf-bfd-mpls-03.txt. is not listed among the references >>> >>> BFD-base is only required because the bootstrapping rules required >>> to >>> setup BFD/VCCV are single-hop style. >>> >>>> > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP >>>> > Ping, LSP Ping, or BFD (Base). So it is not possible to support >>>> > MPLS BFD which enables concurrent use of LSP Ping and BFD >>> >>> You do not negotiate anything per se; you advertise capabilities >>> for >>> VCCV. You may advertise none, one or all of the different CC/CV >>> combinations, >>> which means you are willing to accept any of those combinations >>> (within the >>> rules stipulated in the draft). The receiving side is then free to send >>> any of those combinations (within the rules stipulated in the draft), >>> but >>> once one is successfully sent (and acked), no others are allowed, and no >>> "re-negotiation" is allowed without bringing down the PW. The latter >>> comes >>> specifically from the rules stipulated in RFC 4447. >>> >>> --Tom >>> >>> >>> >>>> > >>>> > Is my understanding accurate ? >>>> > >>>> > Regards >>>> > >>>> > Don >>>> > >>>> > -----Original Message----- >>>> > From: Stewart Bryant [mailto:stbryant@cisco.com] >>>> > Sent: Monday, January 22, 2007 7:35 AM >>>> > To: pwe3 >>>> > Subject: [PWE3] VCCV-12 last call >>>> > >>>> > >>>> > This is the start of last call for >>>> > >>>> > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >>>> > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >>>> > >>>> > last call will end 6th February. >>>> > >>>> > There are a couple of issues that I have with regard to >>>> > IANA policy that is raised by this draft, but I will >>>> > ask my questions in another thread. >>>> > >>>> > Regards >>>> > >>>> > Stewart >>>> > >>>> > _______________________________________________ >>>> > pwe3 mailing list >>>> > pwe3@ietf.org >>>> > https://www1.ietf.org/mailman/listinfo/pwe3 >>>> > >>>> > _______________________________________________ >>>> > pwe3 mailing list >>>> > pwe3@ietf.org >>>> > https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >> > --B_3252664720_3626385 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [PWE3] VCCV-12 last call
Hi Mustapha,

You are correct, we need to change the below text to reflect the behavioura= l change I suggested in my previous E-mail.

Regards,

Danny


On 1/26/07 1:12 PM, "AISSAOUI Mustapha" <Mustapha.Aissaoui@alc= atel-lucent.com> wrote:

Danny,
I made the same proposal in my LC comments. The problem is what you are pro= posing is not allowed by the text in Section 4. The first and second paragra= phs read:
"  VCCV can support several types of connectivity verification ty= pes (CV
   types) or protocols within several possible control chann= el as
   defined by the control channel type (CC types), but it do= es not
   support the use of more than one combination of both conc= urrently.
   The specific type or types of VCCV packets accepted by a = router are
   indicated during capability advertisement as described in= sections
   5.5 and 6.2. The various VCCV CV types supported MUST be = used
   only when they apply to the context of the PW demultiplex= or in use.
   For example, LSP Ping type should only be used when MPLS = is utilized
   as the PSN.
  Once a set of capabilities if advert= ised, the specific one chosen
   based on the preferred order specified below in section 7= . Once
   a specific CC and CV type combination has been chosen, tr= ansmitted
   and replied to, this type combination MUST be the only on= e used
   until such time as the Pseudowire is re-signaled." <= BR>
Then, the first paragraph in Section 7 reads:
"  When a PE receives a VCCV capability advertisement,
   the advertisement may potentially contain more than one C= C or
   CV Type. In this case, it MUST use the following rules wh= en
   choosing which CC or CV type to use. It may only choose o= ne mode
   based on the rules stipulated in sections 4 and 5 above. = In
   particular, once a valid CC Type is used by a PE (traffic=
   sent using that encapsulation), the PE MUST NOT send any<= BR>    traffic down another CC Type encapsulation."
This suggests that a PE will pick a single CC typ= e, which we want to enforce, and a single CV type, which we want to relax fo= r LSP Ping and BFD type 0x04.
Furthermore, I cannot find any text which explici= tly states that a PE compares VCCV capabilities it advertized and those it r= eceived from its peer to perform the match. After the match is made, then th= e PE picks up a single CC type from the common set following the precedence = orders. For CV types, the PE can pick up more than one as long as you abide = by the restrictions governing the use of the BFD types, i.e.,:
1. If both types 0x08 and 0x04 are part of the match, ignore 0x04.
2.  If both types 0x10 and 0x20 are part of the match, ignore 0x10 (th= ere is a typo in the paragraph before last in Section 4 which said that 0x20= must be ignored).
3. If 0x08 or 0x20 is selected, status is converyed using BFD.
4. Types 0x08 and 0x020 should not be selected if the PE uses LDP status no= tifications.  
5. If type 0x04 or 0x10 is selected, status should still be conveyed using = LDP status notifications.
Mustapha.


 
From:= Danny Prairie  [mailto:dprair= ie@cisco.com]
Sent: Friday, January 26, 2007 10:34  AM
To: O'Connor, Don; Thomas D. Nadeau
Cc: pwe3; Stewart  Bryant
Subject: Re: [PWE3] VCCV-12 last call

 
Hi Don,

Good point about the CV. That being  said, I would advocate not encodi= ng the allowed combinations explicitly, but  rather advertise the capab= ilities of the node, and have the peer decide which  type of verificati= on operations it will perform, potentially also including  the use of B= FD and LSP Ping  concurrently.

Regards,

Danny


On 1/25/07 5:46 PM,  "O'Connor, Don" <don.oconnor@us.fuji= tsu.com> wrote:

 
Tom

Section 7  indicates that only one CC mode c= an be used -

"In particular,  once a valid CC Type i= s used by a PE (traffic
   sent  using that encapsulation), the PE MUST NOT sen= d  any
   traffic down another CC Type  encapsulation."
There is no  statement that only one CV Type= can be used. However the current CV  precedence rules in Section 7 imp= ly that there is a restriction that only  one CV mode can be used concu= rrently.

I believe that  it would be useful to have a= CV mode with concurrent LSP Ping and BFD. So my  request is to add a c= ode point for the following

LSP Ping + BFD  for fault detection only

I would also  suggest giving this code point= the highest precedence in the Section 7 CV  precedence table

Regards

Don

 
From:= Thomas D. Nadeau [mailto:tnadeau@ci= sco.com]
Sent:  Thu 1/25/2007 1:15 PM
To: O'Connor, Don
Cc: Stewart  Bryant; pwe3
Subject: Re: [PWE3] VCCV-12 last call



On Jan 23, 2007, at 7:22 PM,  O'Connor, Don wrote:

> My reading of VCCV - 12 is  that
>
> 1) It only supports BFD Base and not MPLS BFD. It can  be noted t= hat
> draft-ietf-bfd-mpls-03.txt. is not listed among the  references
        BFD-base  is only requ= ired because the bootstrapping rules required to
setup  BFD/VCCV are single-hop style.

> 2) It is only possible to  negotiate (by LDP) one CV protocol - I= CMP
> Ping, LSP Ping, or BFD  (Base). So it is not possible to support =
> MPLS BFD which enables  concurrent use of LSP Ping and  BFD<= BR>
        You do not  negotiate = anything per se; you advertise capabilities for
VCCV. You may  advertise none, one or all of the different CC/CV
combinations,
which  means you are willing to accept any of those combinations
(within  the
rules stipulated in the draft). The receiving side is then free to  se= nd
any of those combinations (within the rules stipulated in the  draft),=
but
once one is successfully sent (and acked), no others are  allowed, and= no
"re-negotiation" is allowed without bringing down the PW.  &= nbsp;The latter
comes
specifically from the rules stipulated in RFC  4447.

        --Tom



>
>  Is my understanding accurate ?
>
> Regards
>
>  Don
>
> -----Original Message-----
> From: Stewart Bryant  [mailt= o:stbryant@cisco.com]
>  Sent: Monday, January 22, 2007 7:35 AM
> To: pwe3
> Subject:  [PWE3] VCCV-12 last call
>
>
> This is the start of last  call for
>
> Pseudo Wire Virtual Circuit Connectivity  Verification (VCCV)
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
>
>  last call will end 6th February.
>
> There are a couple of  issues that I have with regard to
> IANA policy that is raised by this  draft, but I will
> ask my questions in another  thread.
>
> Regards
>
> Stewart
>
>  _______________________________________________
> pwe3 mailing  list
> pwe3@ietf.org
>  https://www1.ietf.org/mailman/listinfo/pwe3
>
>  _______________________________________________
> pwe3 mailing  list
> pwe3@ietf.org
>  https://www1.ietf.org/mailman/listinfo/pwe3

 
___________________= ____________________________
pwe3  mailing  list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3



 --B_3252664720_3626385-- --===============0369311474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0369311474==-- From pwe3-bounces@ietf.org Fri Jan 26 14:03:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWMD-0002qE-Gs; Fri, 26 Jan 2007 14:03:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWMC-0002mS-AP; Fri, 26 Jan 2007 14:03:28 -0500 Received: from [213.46.243.15] (helo=amsfep13-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWM7-0004ki-Rz; Fri, 26 Jan 2007 14:03:28 -0500 Received: from [192.168.17.3] (really [62.195.168.62]) by amsfep13-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126190316.TWET13454.amsfep13-int.chello.nl@[192.168.17.3]>; Fri, 26 Jan 2007 20:03:16 +0100 Message-ID: <45BA5072.8060005@chello.nl> Date: Fri, 26 Jan 2007 20:03:14 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [PWE3] Re: Y.1720 liased text References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> In-Reply-To: <003d01c74158$5510a470$4002010a@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mpls@ietf.org, ghani.abbas@ericsson.com, pwe3@ietf.org, Stewart Bryant X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Adrian, You wrote: > Hi Huub, > >>> The implication of the text is that you can have a packet of the >>> form: >>> >>> LSE (RFC3032) >>> Sequence number >>> LSE (RFC3032) >>> Payload >>> >>> Is that correct? >> >> This is also what I read, and apparently Neil does as well. >> >>> If so what is the setting of the S bit (See RFC3032) in each >>> case? >> >> Because the text does not mention any altering of the S-bit >> I assume they do not change. > > Ah, so either setting of the S-bit is allowed? [hvh] the text does also not mention a specific value of the S-bit, so I suppose either value of the S-bit is allowed. If I would try to implement this protection, the LSR providing the protection would build the LSE according to RFC3032 and then add the 4 octet sequence number. >> I agree with Neil (see his 2002 post) that this requires a >> very carefull configuartion of the network. Checking that >> both ends support this feature and closely guard the connectivity >> for both diverse routes. > > With the S-bit, careful config is needed. [hvh] indeed I did mean careful > Without the S-bit it seems like a router that popped a label would > expect the next thing on the stack to also be a label, but would > actually find a magic sequence number. [hvh] if the the config was careful the router that pops the label inserted by the router that is the source of the protection knows that the 4 octets following this popped label is the sequene number and treats it accordingly. > Although you could config around > this (since the pop action must be installed) this is a new MPLS > behavior. At the least it is a new LFIB action that is not previously > described in any MPLS documentation. [hvh] ehh, it was described in http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt This draft was presented and discussed in the IETF53 meeting. The meeting notes nor the discussion afterwards on the MPLS WG list mention the fact that it contains a new LFIB action. >> Note that this text is in an appendix, so it does not form >> an integral part of the recommendation, i.e. it is not mandatory. > > Hmmm. > > Shouldn't there be a specification of: > - what must be supported > - what can also be attempted [hvh] maybe, but apparently when the text was drafted there were no contributions providing/requesting these specifications, and when the recommendation was approved (as usual in ITU-T by consensus) nobody objected, in the meeting of the Q3/13, at the closing plenary, nor during the AAP. > I think Stewart's question is quite helpful here. Do we have any idea of > what deployed implementations do? [hvh] That would be a question to ask on the ITU-T Q9/15 exploder > Cheers, > Adrian Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 14:11:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWTC-0006V0-1u; Fri, 26 Jan 2007 14:10:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWTA-0006Uu-AR for pwe3@ietf.org; Fri, 26 Jan 2007 14:10:40 -0500 Received: from audl953.usa.alcatel.com ([143.209.238.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWT7-0005jX-83 for pwe3@ietf.org; Fri, 26 Jan 2007 14:10:40 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id l0QJAQB0001537; Fri, 26 Jan 2007 13:10:34 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 26 Jan 2007 13:10:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] VCCV-12 last call Date: Fri, 26 Jan 2007 13:09:47 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdAtS9n51FWTsapQtS99gDhKUgHYQAG1h4UACO1QxcABFD3MAAC10jcAABV3gA= References: From: "AISSAOUI Mustapha" To: "Danny Prairie" , "O'Connor, Don" , "Tom Nadeau \(tnadeau\)" X-OriginalArrivalTime: 26 Jan 2007 19:10:29.0849 (UTC) FILETIME=[A502CC90:01C7417D] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.1 (/) X-Scan-Signature: 778b456acd32f555185589e04d062871 Cc: pwe3 , "Stewart Bryant \(stbryant\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1559188157==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1559188157== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7417D.8C62F21D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7417D.8C62F21D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Danny and Tom, if there are no objections, I would like to propose we use the text in the last paragraph in my email below to Section 4 to clarify this behaviour. =20 Mustapha. ________________________________ From: Danny Prairie [mailto:dprairie@cisco.com]=20 Sent: Friday, January 26, 2007 1:59 PM To: AISSAOUI Mustapha; O'Connor, Don; Tom Nadeau (tnadeau) Cc: pwe3; Stewart Bryant (stbryant) Subject: Re: [PWE3] VCCV-12 last call =09 =09 =09 Hi Mustapha, =09 You are correct, we need to change the below text to reflect the behavioural change I suggested in my previous E-mail. =09 Regards, =09 Danny =09 =09 On 1/26/07 1:12 PM, "AISSAOUI Mustapha" wrote: =09 =09 Danny, I made the same proposal in my LC comments. The problem is what you are proposing is not allowed by the text in Section 4. The first and second paragraphs read: " VCCV can support several types of connectivity verification types (CV=20 types) or protocols within several possible control channel as=20 defined by the control channel type (CC types), but it does not=20 support the use of more than one combination of both concurrently.=20 The specific type or types of VCCV packets accepted by a router are indicated during capability advertisement as described in sections=20 5.5 and 6.2. The various VCCV CV types supported MUST be used only when they apply to the context of the PW demultiplexor in use. For example, LSP Ping type should only be used when MPLS is utilized as the PSN. =09 Once a set of capabilities if advertised, the specific one chosen=20 based on the preferred order specified below in section 7. Once=20 a specific CC and CV type combination has been chosen, transmitted=20 and replied to, this type combination MUST be the only one used=20 until such time as the Pseudowire is re-signaled."=20 =09 Then, the first paragraph in Section 7 reads: " When a PE receives a VCCV capability advertisement, the advertisement may potentially contain more than one CC or CV Type. In this case, it MUST use the following rules when=20 choosing which CC or CV type to use. It may only choose one mode based on the rules stipulated in sections 4 and 5 above. In particular, once a valid CC Type is used by a PE (traffic sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation." =09 This suggests that a PE will pick a single CC type, which we want to enforce, and a single CV type, which we want to relax for LSP Ping and BFD type 0x04. =09 Furthermore, I cannot find any text which explicitly states that a PE compares VCCV capabilities it advertized and those it received from its peer to perform the match. After the match is made, then the PE picks up a single CC type from the common set following the precedence orders. For CV types, the PE can pick up more than one as long as you abide by the restrictions governing the use of the BFD types, i.e.,: 1. If both types 0x08 and 0x04 are part of the match, ignore 0x04. 2. If both types 0x10 and 0x20 are part of the match, ignore 0x10 (there is a typo in the paragraph before last in Section 4 which said that 0x20 must be ignored). 3. If 0x08 or 0x20 is selected, status is converyed using BFD. 4. Types 0x08 and 0x020 should not be selected if the PE uses LDP status notifications. =20 5. If type 0x04 or 0x10 is selected, status should still be conveyed using LDP status notifications. =09 Mustapha. =09 =09 =09 =20 =09 ________________________________ From: Danny Prairie [mailto:dprairie@cisco.com] Sent: Friday, January 26, 2007 10:34 AM To: O'Connor, Don; Thomas D. Nadeau Cc: pwe3; Stewart Bryant Subject: Re: [PWE3] VCCV-12 last call =09 =20 Hi Don, =09 Good point about the CV. That being said, I would advocate not encoding the allowed combinations explicitly, but rather advertise the capabilities of the node, and have the peer decide which type of verification operations it will perform, potentially also including the use of BFD and LSP Ping concurrently. =09 Regards, =09 Danny =09 =09 On 1/25/07 5:46 PM, "O'Connor, Don" wrote: =09 =20 =09 Tom =09 Section 7 indicates that only one CC mode can be used -=20 =09 "In particular, once a valid CC Type is used by a PE (traffic=20 sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation." =09 There is no statement that only one CV Type can be used. However the current CV precedence rules in Section 7 imply that there is a restriction that only one CV mode can be used concurrently.=20 =09 I believe that it would be useful to have a CV mode with concurrent LSP Ping and BFD. So my request is to add a code point for the following=20 =09 LSP Ping + BFD for fault detection only =09 I would also suggest giving this code point the highest precedence in the Section 7 CV precedence table =09 Regards =09 Don =09 =20 =09 ________________________________ From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thu 1/25/2007 1:15 PM To: O'Connor, Don Cc: Stewart Bryant; pwe3 Subject: Re: [PWE3] VCCV-12 last call =09 =09 =09 On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: =09 > My reading of VCCV - 12 is that > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that=20 > draft-ietf-bfd-mpls-03.txt. is not listed among the references =09 BFD-base is only required because the bootstrapping rules required to setup BFD/VCCV are single-hop style. =09 > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP=20 > Ping, LSP Ping, or BFD (Base). So it is not possible to support=20 > MPLS BFD which enables concurrent use of LSP Ping and BFD =09 You do not negotiate anything per se; you advertise capabilities for VCCV. You may advertise none, one or all of the different CC/CV=20 combinations, which means you are willing to accept any of those combinations=20 (within the rules stipulated in the draft). The receiving side is then free to send any of those combinations (within the rules stipulated in the draft),=20 but once one is successfully sent (and acked), no others are allowed, and no "re-negotiation" is allowed without bringing down the PW. The latter=20 comes specifically from the rules stipulated in RFC 4447. =09 --Tom =09 =09 =09 > > Is my understanding accurate ? > > Regards > > Don > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, January 22, 2007 7:35 AM > To: pwe3 > Subject: [PWE3] VCCV-12 last call > > > This is the start of last call for > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > last call will end 6th February. > > There are a couple of issues that I have with regard to > IANA policy that is raised by this draft, but I will > ask my questions in another thread. > > Regards > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 =09 =20 =09 ________________________________ =09 _______________________________________________ pwe3 mailing list pwe3@ietf.org =09 https://www1.ietf.org/mailman/listinfo/pwe3 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C7417D.8C62F21D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [PWE3] VCCV-12 last call
Danny and Tom,
if there are no objections, I would like to propose we use the = text in=20 the last paragraph in my email below to Section 4 to clarify this=20 behaviour.
 
Mustapha.

From: Danny Prairie=20 [mailto:dprairie@cisco.com]
Sent: Friday, January 26, 2007 = 1:59=20 PM
To: AISSAOUI Mustapha; O'Connor, Don; Tom Nadeau=20 (tnadeau)
Cc: pwe3; Stewart Bryant = (stbryant)
Subject: Re:=20 [PWE3] VCCV-12 last call


Hi Mustapha,

You are correct, we = need to=20 change the below text to reflect the behavioural change I suggested in = my=20 previous E-mail.

Regards,

Danny


On 1/26/07 = 1:12 PM,=20 "AISSAOUI Mustapha" <Mustapha.Aissaoui@alcatel-lucent.com>=20 wrote:
Danny,
I made=20 the same proposal in my LC comments. The problem is what you are = proposing=20 is not allowed by the text in Section 4. The first and second = paragraphs=20 read:
"  VCCV can support several types of connectivity = verification=20 types (CV
   types) or protocols within several = possible=20 control channel as
   defined by the control = channel type=20 (CC types), but it does not
   support the use of = more=20 than one combination of both concurrently.
   The = specific type or types of VCCV packets accepted by a router=20 are
   indicated during capability advertisement = as=20 described in sections
   5.5 and 6.2. The various = VCCV CV=20 types supported MUST be used
   only when they = apply to=20 the context of the PW demultiplexor in use.
   For = example, LSP Ping type should only be used when MPLS is=20 utilized
   as the PSN.

  Once a set of capabilities if advertised, = the=20 specific one chosen
   based on the preferred = order=20 specified below in section 7. Once
   a specific = CC and=20 CV type combination has been chosen, transmitted =
   and=20 replied to, this type combination MUST be the only one used=20
   until such time as the Pseudowire is = re-signaled."=20

Then, the first paragraph in Section 7 reads:
" =  When a=20 PE receives a VCCV capability = advertisement,
   the=20 advertisement may potentially contain more than one CC=20 or
   CV Type. In this case, it MUST use the = following=20 rules when
   choosing which CC or CV type to = use. It may=20 only choose one mode
   based on the rules = stipulated in=20 sections 4 and 5 above. In
   particular, once a = valid CC=20 Type is used by a PE (traffic
   sent using that=20 encapsulation), the PE MUST NOT send = any
   traffic down=20 another CC Type encapsulation."

This suggests=20 that a PE will pick a single CC type, which we want to enforce, and = a single=20 CV type, which we want to relax for LSP Ping and BFD type=20 0x04.

Furthermore, I cannot find any text which explicitly = states that=20 a PE compares VCCV capabilities it advertized and those it received = from its=20 peer to perform the match. After the match is made, then the PE = picks up a=20 single CC type from the common set following the precedence orders. = For CV=20 types, the PE can pick up more than one as long as you abide by the=20 restrictions governing the use of the BFD types, i.e.,:
1. = If both = types 0x08=20 and 0x04 are part of the match, ignore 0x04.
2.  If both = types 0x10=20 and 0x20 are part of the match, ignore 0x10 (there is a typo in the=20 paragraph before last in Section 4 which said that 0x20 must be=20 ignored).
3. If 0x08 or 0x20 is selected, status is converyed = using=20 BFD.
4. Types 0x08 and 0x020 should not be selected if the PE = uses LDP=20 status notifications.  
5. If type 0x04 or 0x10 is selected, = status=20 should still be conveyed using LDP status = notifications.

Mustapha.

 
From: Danny Prairie  [mailto:dprairie@cisco.com] =
Sent: Friday, January 26, 2007 10:34 =  AM
To:=20 O'Connor, Don; Thomas D. Nadeau
Cc: pwe3; Stewart=20  Bryant
Subject: Re: [PWE3] VCCV-12 last=20 call

 
Hi=20 Don,

Good point about the CV. That being  said, I = would=20 advocate not encoding the allowed combinations explicitly, but=20  rather advertise the capabilities of the node, and have the = peer=20 decide which  type of verification operations it will = perform,=20 potentially also including  the use of BFD and LSP Ping=20  concurrently.

Regards,

Danny


On = 1/25/07=20 5:46 PM,  "O'Connor, Don" <don.oconnor@us.fujitsu.com>=20 wrote:

 
Tom

Section 7=20  indicates that only one CC mode can be used - =

"In=20 particular,  once a valid CC Type is used by a PE (traffic=20
   sent  using that encapsulation), the = PE MUST=20 NOT send  any
   traffic down another CC = Type=20  encapsulation."

There is no=20  statement that only one CV Type can be used. However the = current=20 CV  precedence rules in Section 7 imply that there is a = restriction=20 that only  one CV mode can be used concurrently. =

I believe=20 that  it would be useful to have a CV mode with concurrent = LSP Ping=20 and BFD. So my  request is to add a code point for the = following=20

LSP Ping + BFD  for fault detection = only

I would=20 also  suggest giving this code point the highest precedence = in the=20 Section 7 CV  precedence table

Regards

Don

 
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Se= nt:=20  Thu 1/25/2007 1:15 PM
To: O'Connor, = Don
Cc:=20 Stewart  Bryant; pwe3
Subject: Re: [PWE3] VCCV-12 = last=20 call



On Jan=20 23, 2007, at 7:22 PM,  O'Connor, Don wrote:

> My = reading=20 of VCCV - 12 is  that
>
> 1) It only supports = BFD Base=20 and not MPLS BFD. It can  be noted that
>=20 draft-ietf-bfd-mpls-03.txt. is not listed among the=20 =  references

        B= FD-base=20  is only required because the bootstrapping rules required=20 to
setup  BFD/VCCV are single-hop style.

> 2) = It is=20 only possible to  negotiate (by LDP) one CV protocol - ICMP =
> Ping, LSP Ping, or BFD  (Base). So it is not = possible to=20 support
> MPLS BFD which enables  concurrent use of = LSP Ping=20 and =  BFD

        You=20 do not  negotiate anything per se; you advertise = capabilities=20 for
VCCV. You may  advertise none, one or all of the = different=20 CC/CV
combinations,
which  means you are willing to = accept=20 any of those combinations
(within  the
rules = stipulated in=20 the draft). The receiving side is then free to  send
any = of=20 those combinations (within the rules stipulated in the =  draft),=20
but
once one is successfully sent (and acked), no others = are=20  allowed, and no
"re-negotiation" is allowed without = bringing=20 down the PW.   The latter
comes
specifically = from the=20 rules stipulated in RFC=20 =  4447.

        --Tom<= BR>


>
>=20  Is my understanding accurate ?
>
>=20 Regards
>
>  Don
>
> -----Original=20 Message-----
> From: Stewart Bryant  [mailto:stbryant@cisco.com]
>= ;=20  Sent: Monday, January 22, 2007 7:35 AM
> To: = pwe3
>=20 Subject:  [PWE3] VCCV-12 last call
>
>
> = This is=20 the start of last  call for
>
> Pseudo Wire = Virtual=20 Circuit Connectivity  Verification (VCCV)
> = http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
&g= t;
>=20  last call will end 6th February.
>
> There are = a=20 couple of  issues that I have with regard to
> IANA = policy=20 that is raised by this  draft, but I will
> ask my = questions=20 in another  thread.
>
> Regards
>
> = Stewart
>
>=20  _______________________________________________
> = pwe3=20 mailing  list
> pwe3@ietf.org
>=20 =  https://www1.ietf.org/mailman/listinfo/pwe3
>
>=20  _______________________________________________
> = pwe3=20 mailing  list
> pwe3@ietf.org
>=20 =  https://www1.ietf.org/mailman/listinfo/pwe3

 
_______________________________________________
pwe3=20  mailing=20 =  list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe= 3



------_=_NextPart_001_01C7417D.8C62F21D-- --===============1559188157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1559188157==-- From pwe3-bounces@ietf.org Fri Jan 26 14:32:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWnM-0000k6-WD; Fri, 26 Jan 2007 14:31:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWnK-0000jt-Nw; Fri, 26 Jan 2007 14:31:30 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWnJ-0000QX-Cb; Fri, 26 Jan 2007 14:31:30 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 20:31:27 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QJVQP0020701; Fri, 26 Jan 2007 20:31:26 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QJVNC8009503; Fri, 26 Jan 2007 20:31:23 +0100 (MET) Message-ID: <45BA5707.3070503@cisco.com> Date: Fri, 26 Jan 2007 19:31:19 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort Subject: Re: [PWE3] Re: Y.1720 liased text References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> <45BA5072.8060005@chello.nl> In-Reply-To: <45BA5072.8060005@chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1827; t=1169839886; x=1170703886; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20Re=3A=20Y.1720=20liased=20text |Sender:=20; bh=U6D9CHMHmnK2hVEmn7FOw4ACHxsMec07fEfiIXiggHc=; b=q5H5rjo61hRvpRtX1+KS+i8c5Lv035wZRsSLUPTmLf61Jmn2ge/5+VOMhwbPo5BsLlDEbrTr 2cN0yjuSc4BOh7SB599i5JliVFsiMOOmr5kEGLFn4RDS97TBIG0ounlJ; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > [hvh] the text does also not mention a specific value of the S-bit, > so I suppose either value of the S-bit is allowed. > If I would try to implement this protection, the LSR > providing the protection would build the LSE according to > RFC3032 and then add the 4 octet sequence number. ... but it would not be building a label stack it would be building a something else. > [hvh] if the the config was careful the router that pops the > label inserted by the router that is the source of the protection > knows that the 4 octets following this popped label is the > sequene number and treats it accordingly. You can do lots of things if you are careful, but that does not mean that they should be done. We have no idea what the consequences of stray data in the stack are, or how they impact any developments we might wish to make in the future. > [hvh] ehh, it was described in > http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt > > This draft was presented and discussed in the IETF53 meeting. > The meeting notes nor the discussion afterwards on the MPLS WG list > mention the fact that it contains a new LFIB action. Actually I see that you ran out of time at the meeting, and then not much. > [hvh] maybe, but apparently when the text was drafted there were no > contributions providing/requesting these specifications, and > when the recommendation was approved (as usual in ITU-T by > consensus) nobody objected, in the meeting of the Q3/13, at > the closing plenary, nor during the AAP. > I am not sure that presenting a draft at one IETF meeting - which ran out of time - and then letting the draft die constitutes IETF approval for the design. Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 15:03:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXHg-0001Rc-Lm; Fri, 26 Jan 2007 15:02:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXHe-0001RO-NF; Fri, 26 Jan 2007 15:02:50 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAXHd-0005fT-Bi; Fri, 26 Jan 2007 15:02:50 -0500 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1169841768!10872550!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2827 invoked from network); 26 Jan 2007 20:02:48 -0000 Received: from unknown (HELO attrh8i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 26 Jan 2007 20:02:48 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0QK0CKB001819; Fri, 26 Jan 2007 15:00:13 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0QK048x001715; Fri, 26 Jan 2007 15:00:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Re: Y.1720 liased text Date: Fri, 26 Jan 2007 14:02:36 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0D845794@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45BA5072.8060005@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBfLlXJ3ysepdtRL2eiZpEQ95QZAABJLLw From: "BRUNGARD, DEBORAH A, SBCLABS" To: "Huub van Helvoort" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: mpls@ietf.org, pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org FYI- This 1+1 packet protection scheme was not only in ITU's SG13 work, it was also included in SG15's G.7712, done at the same time (2003). G.7712 doesn't reference Y.1720, probably as they were being done at the same time, though the scheme was of the same origin. G.7712's Appendix IV does say that the implementation is "non-trivial", maybe there have been no attempts. (ITU Recommendations (PDF) can be downloaded for free) Deborah =20 -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: Friday, January 26, 2007 2:03 PM To: Adrian Farrel Cc: mpls@ietf.org; ghani.abbas@ericsson.com; pwe3@ietf.org; Stewart Bryant Subject: Re: [PWE3] Re: Y.1720 liased text Hi Adrian, You wrote: > Hi Huub, >=20 >>> The implication of the text is that you can have a packet of the >>> form: >>> >>> LSE (RFC3032) >>> Sequence number >>> LSE (RFC3032) >>> Payload >>> >>> Is that correct? >> >> This is also what I read, and apparently Neil does as well. >> >>> If so what is the setting of the S bit (See RFC3032) in each >>> case? >> >> Because the text does not mention any altering of the S-bit >> I assume they do not change. >=20 > Ah, so either setting of the S-bit is allowed? [hvh] the text does also not mention a specific value of the S-bit, so I suppose either value of the S-bit is allowed. If I would try to implement this protection, the LSR providing the protection would build the LSE according to RFC3032 and then add the 4 octet sequence number. >> I agree with Neil (see his 2002 post) that this requires a >> very carefull configuartion of the network. Checking that >> both ends support this feature and closely guard the connectivity >> for both diverse routes. >=20 > With the S-bit, careful config is needed. [hvh] indeed I did mean careful > Without the S-bit it seems like a router that popped a label would=20 > expect the next thing on the stack to also be a label, but would=20 > actually find a magic sequence number. [hvh] if the the config was careful the router that pops the label inserted by the router that is the source of the protection knows that the 4 octets following this popped label is the sequene number and treats it accordingly. > Although you could config around=20 > this (since the pop action must be installed) this is a new MPLS=20 > behavior. At the least it is a new LFIB action that is not previously=20 > described in any MPLS documentation. [hvh] ehh, it was described in http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-pro tection-00.txt This draft was presented and discussed in the IETF53 meeting. The meeting notes nor the discussion afterwards on the MPLS WG list mention the fact that it contains a new LFIB action. >> Note that this text is in an appendix, so it does not form >> an integral part of the recommendation, i.e. it is not mandatory. >=20 > Hmmm. >=20 > Shouldn't there be a specification of: > - what must be supported > - what can also be attempted [hvh] maybe, but apparently when the text was drafted there were no contributions providing/requesting these specifications, and when the recommendation was approved (as usual in ITU-T by consensus) nobody objected, in the meeting of the Q3/13, at the closing plenary, nor during the AAP. > I think Stewart's question is quite helpful here. Do we have any idea of=20 > what deployed implementations do? [hvh] That would be a question to ask on the ITU-T Q9/15 exploder > Cheers, > Adrian Cheers, Huub. --=20 =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 http://www.van-helvoort.eu/ =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 Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 15:16:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXUl-00089x-JP; Fri, 26 Jan 2007 15:16:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXUk-00089p-BB for pwe3@ietf.org; Fri, 26 Jan 2007 15:16:22 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAXUh-0007qA-FP for pwe3@ietf.org; Fri, 26 Jan 2007 15:16:22 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2007 15:16:19 -0500 X-IronPort-AV: i="4.13,244,1167627600"; d="scan'208,217"; a="112572915:sNHT111137062" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QKGJLQ001997; Fri, 26 Jan 2007 15:16:19 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QKGIOA009548; Fri, 26 Jan 2007 15:16:18 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 15:16:18 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 15:16:17 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <37A3F764-A25B-4D86-BC9B-9CB1C9C8A437@cisco.com> From: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 last call Date: Fri, 26 Jan 2007 15:16:17 -0500 To: "AISSAOUI Mustapha" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 20:16:17.0779 (UTC) FILETIME=[D6291C30:01C74186] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21414; t=1169842579; x=1170706579; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20 |To:=20=22AISSAOUI=20Mustapha=22=20; bh=7ddoN1XCN+JDhwrvO8z30BPsyN1l4KL3YvMA2lmGUm4=; b=dvBaifammpZS+ZcfFhsi5xkeF8+/nWpcr6Url20y8ARygdGYPgIKr4IyJ07k/JSbu1t9c6qD nYCrHBuAHVy7hNfZa+WC0HNiTvqRu44C/ivRSbtx7482upO4niA4CWyD; Authentication-Results: rtp-dkim-1; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: pwe3 , Stewart Bryant X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1265725314==" Errors-To: pwe3-bounces@ietf.org --===============1265725314== Content-Type: multipart/alternative; boundary=Apple-Mail-14-409332491 --Apple-Mail-14-409332491 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Mustapha, The restrictions in question pertains to re-signaling of the PWs and their associated capabilities AFTER they have been signaled with LDP. This is the references to RFC 4447. We further constrained the use of a CC/CV combination based on that, although it seems this was a bit heavy-handed. So while I still agree that we must not allow re-signaling of capabilities after the PW comes up, we should allow the use of different CC/CV types (as per the advertisement and recommended precedence rules). --Tom > Danny, > I made the same proposal in my LC comments. The problem is what you > are proposing is not allowed by the text in Section 4. The first > and second paragraphs read: > " VCCV can support several types of connectivity verification > types (CV > types) or protocols within several possible control channel as > defined by the control channel type (CC types), but it does not > support the use of more than one combination of both concurrently. > The specific type or types of VCCV packets accepted by a router are > indicated during capability advertisement as described in sections > 5.5 and 6.2. The various VCCV CV types supported MUST be used > only when they apply to the context of the PW demultiplexor in use. > For example, LSP Ping type should only be used when MPLS is > utilized > as the PSN. > > Once a set of capabilities if advertised, the specific one chosen > based on the preferred order specified below in section 7. Once > a specific CC and CV type combination has been chosen, transmitted > and replied to, this type combination MUST be the only one used > until such time as the Pseudowire is re-signaled." > > Then, the first paragraph in Section 7 reads: > " When a PE receives a VCCV capability advertisement, > the advertisement may potentially contain more than one CC or > CV Type. In this case, it MUST use the following rules when > choosing which CC or CV type to use. It may only choose one mode > based on the rules stipulated in sections 4 and 5 above. In > particular, once a valid CC Type is used by a PE (traffic > sent using that encapsulation), the PE MUST NOT send any > traffic down another CC Type encapsulation." > > This suggests that a PE will pick a single CC type, which we want > to enforce, and a single CV type, which we want to relax for LSP > Ping and BFD type 0x04. > > Furthermore, I cannot find any text which explicitly states that a > PE compares VCCV capabilities it advertized and those it received > from its peer to perform the match. After the match is made, then > the PE picks up a single CC type from the common set following the > precedence orders. For CV types, the PE can pick up more than one > as long as you abide by the restrictions governing the use of the > BFD types, i.e.,: > 1. If both types 0x08 and 0x04 are part of the match, ignore 0x04. > 2. If both types 0x10 and 0x20 are part of the match, ignore 0x10 > (there is a typo in the paragraph before last in Section 4 which > said that 0x20 must be ignored). > 3. If 0x08 or 0x20 is selected, status is converyed using BFD. > 4. Types 0x08 and 0x020 should not be selected if the PE uses LDP > status notifications. > 5. If type 0x04 or 0x10 is selected, status should still be > conveyed using LDP status notifications. > > Mustapha. > > From: Danny Prairie [mailto:dprairie@cisco.com] > Sent: Friday, January 26, 2007 10:34 AM > To: O'Connor, Don; Thomas D. Nadeau > Cc: pwe3; Stewart Bryant > Subject: Re: [PWE3] VCCV-12 last call > > Hi Don, > > Good point about the CV. That being said, I would advocate not > encoding the allowed combinations explicitly, but rather advertise > the capabilities of the node, and have the peer decide which type > of verification operations it will perform, potentially also > including the use of BFD and LSP Ping concurrently. > > Regards, > > Danny > > > On 1/25/07 5:46 PM, "O'Connor, Don" > wrote: > > Tom > > Section 7 indicates that only one CC mode can be used - > > "In particular, once a valid CC Type is used by a PE (traffic > sent using that encapsulation), the PE MUST NOT send any > traffic down another CC Type encapsulation." > > There is no statement that only one CV Type can be used. However > the current CV precedence rules in Section 7 imply that there is a > restriction that only one CV mode can be used concurrently. > > I believe that it would be useful to have a CV mode with concurrent > LSP Ping and BFD. So my request is to add a code point for the > following > > LSP Ping + BFD for fault detection only > > I would also suggest giving this code point the highest precedence > in the Section 7 CV precedence table > > Regards > > Don > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thu 1/25/2007 1:15 PM > To: O'Connor, Don > Cc: Stewart Bryant; pwe3 > Subject: Re: [PWE3] VCCV-12 last call > > > > On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > > > My reading of VCCV - 12 is that > > > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that > > draft-ietf-bfd-mpls-03.txt. is not listed among the references > > BFD-base is only required because the bootstrapping rules > required to > setup BFD/VCCV are single-hop style. > > > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP > > Ping, LSP Ping, or BFD (Base). So it is not possible to support > > MPLS BFD which enables concurrent use of LSP Ping and BFD > > You do not negotiate anything per se; you advertise > capabilities for > VCCV. You may advertise none, one or all of the different CC/CV > combinations, > which means you are willing to accept any of those combinations > (within the > rules stipulated in the draft). The receiving side is then free to > send > any of those combinations (within the rules stipulated in the draft), > but > once one is successfully sent (and acked), no others are allowed, > and no > "re-negotiation" is allowed without bringing down the PW. The latter > comes > specifically from the rules stipulated in RFC 4447. > > --Tom > > > > > > > Is my understanding accurate ? > > > > Regards > > > > Don > > > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Monday, January 22, 2007 7:35 AM > > To: pwe3 > > Subject: [PWE3] VCCV-12 last call > > > > > > This is the start of last call for > > > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > > > last call will end 6th February. > > > > There are a couple of issues that I have with regard to > > IANA policy that is raised by this draft, but I will > > ask my questions in another thread. > > > > Regards > > > > Stewart > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > --Apple-Mail-14-409332491 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Mustapha,=A0

The = restrictions in question pertains to re-signaling of the = PWs
and their associated capabilities AFTER they have been = signaled
with LDP. This is the references to RFC 4447.=A0 We = further constrained
the use of a CC/CV combination based on = that, although it seems
this was a bit heavy-handed.=A0 So = while I still agree that we must not
allow re-signaling of = capabilities after the PW comes up, we should
allow the use of = different CC/CV types (as per the advertisement
and = recommended=A0precedence rules).

= --Tom


Danny,
I made the same proposal in my LC comments. The problem is = what you are proposing is not allowed by the text in=A0Section 4. The = first and second paragraphs read:
"=A0 VCCV can support several types of connectivity = verification types (CV
=A0=A0 types) or protocols within several = possible control channel as
=A0=A0 defined by the control channel = type (CC types), but it does not
=A0=A0 support the use of more than = one combination of both concurrently.
=A0=A0 The specific type or = types of VCCV packets accepted by a router are
=A0=A0 indicated = during capability advertisement as described in sections
=A0=A0 5.5 = and 6.2. The various VCCV CV types supported MUST be used
=A0=A0 only = when they apply to the context of the PW demultiplexor in use.
=A0=A0 = For example, LSP Ping type should only be used when MPLS is = utilized
=A0=A0 as the PSN.
=A0
=A0=A0 Once = a set of capabilities if advertised, the specific one chosen
=A0=A0 = based on the preferred order specified below in section 7. Once
=A0=A0= a specific CC and CV type combination has been chosen, transmitted =
=A0=A0 and replied to, this type combination MUST be the only one = used
=A0=A0 until such time as the Pseudowire is = re-signaled."=A0
=A0
Then, the = first paragraph in Section 7 reads:
"=A0 When a PE receives a VCCV capability = advertisement,
=A0=A0 the advertisement may potentially contain more = than one CC or
=A0=A0 CV Type. In this case, it MUST use the = following rules when
=A0=A0 choosing which CC or CV type to use. It = may only choose one mode
=A0=A0 based on the rules stipulated in = sections 4 and 5 above. In
=A0=A0 particular, once a valid CC Type is = used by a PE (traffic
=A0=A0 sent using that encapsulation), the PE = MUST NOT send any
=A0=A0 traffic down another CC Type = encapsulation."
=A0
This = suggests that a PE will pick a single CC type, which we want to enforce, = and a single CV type, which we=A0want to relax for LSP Ping and BFD type = 0x04.
=A0
Furthermore, = I cannot find any=A0text=A0which explicitly states that a PE compares = VCCV capabilities it advertized and those it received from its peer to = perform the match. After the match is made, then the PE picks up a = single CC type from the common set following the precedence orders. For = CV types,=A0the PE=A0can pick up more than one as long as=A0you abide by = the restrictions governing the use of the BFD types, = i.e.,:
1.=A0=A0If both types = 0x08 and 0x04 are part of the match, ignore 0x04.
=
2.=A0 If both types 0x10 and 0x20 are part of = the match, ignore 0x10 (there is a typo in the paragraph before last in = Section 4 which said that 0x20 must be ignored).
=
3. If 0x08 or 0x20 is selected, status is = converyed using BFD.
4. Types 0x08 and 0x020=A0should not=A0be selected if the PE = uses LDP status notifications.=A0=A0
5. If type 0x04 or 0x10 is selected, status should still be = conveyed using LDP status notifications.
=A0
Mustapha.

From: Danny Prairie [mailto:dprairie@cisco.com] =
Sent: Friday, January 26, 2007 10:34 AM
To: = O'Connor, Don; Thomas D. Nadeau
Cc: pwe3; Stewart = Bryant
Subject: Re: [PWE3] VCCV-12 last = call

Hi Don,

Good point about = the CV. That being said, I would advocate not encoding the allowed = combinations explicitly, but rather advertise the capabilities of the = node, and have the peer decide which type of verification operations = it will perform, potentially also including the use of BFD and LSP = Ping concurrently.

Regards,

Danny


On 1/25/07 = 5:46 PM, "O'Connor, Don" <don.oconnor@us.fujitsu.com&= gt; wrote:
Tom

Section 7 = indicates that only one CC mode can be used -

"In = particular, once a valid CC Type is used by a PE (traffic =
=A0=A0=A0sent using that encapsulation), the PE MUST NOT send = any
=A0=A0=A0traffic down another CC Type = encapsulation."

There is no statement that = only one CV Type can be used. However the current CV precedence = rules in Section 7 imply that there is a restriction that only one = CV mode can be used concurrently.

I believe that it = would be useful to have a CV mode with concurrent LSP Ping and BFD. So = my request is to add a code point for the following

LSP = Ping + BFD for fault detection only

I would also = suggest giving this code point the highest precedence in the Section 7 = CV precedence table

Regards

Don

= From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sen= t: Thu 1/25/2007 1:15 PM
To: O'Connor, = Don
Cc: Stewart Bryant; pwe3
Subject: Re: [PWE3] = VCCV-12 last call



On Jan 23, 2007, at 7:22 PM, O'Connor, Don = wrote:

> My reading of VCCV - 12 is that
>
> = 1) It only supports BFD Base and not MPLS BFD. It can be noted that =
> draft-ietf-bfd-mpls-03.txt. is not listed among the = references

=A0=A0=A0=A0=A0=A0=A0=A0BFD-base is only required = because the bootstrapping rules required to
setup BFD/VCCV are = single-hop style.

> 2) It is only possible to negotiate = (by LDP) one CV protocol - ICMP
> Ping, LSP Ping, or BFD = (Base). So it is not possible to support
> MPLS BFD which enables = concurrent use of LSP Ping and BFD

=A0=A0=A0=A0=A0=A0=A0=A0= You do not negotiate anything per se; you advertise capabilities = for
VCCV. You may advertise none, one or all of the different = CC/CV
combinations,
which means you are willing to accept any = of those combinations
(within the
rules stipulated in the = draft). The receiving side is then free to send
any of those = combinations (within the rules stipulated in the draft), =
but
once one is successfully sent (and acked), no others are = allowed, and no
"re-negotiation" is allowed without bringing down the = PW. =A0The latter
comes
specifically from the rules = stipulated in RFC = 4447.

=A0=A0=A0=A0=A0=A0=A0=A0--Tom



>
> = Is my understanding accurate ?
>
> Regards
>
> = Don
>
> -----Original Message-----
> From: Stewart = Bryant [mailto:stbryant@cisco.com]
>= Sent: Monday, January 22, 2007 7:35 AM
> To: pwe3
> = Subject: [PWE3] VCCV-12 last call
>
>
> This is = the start of last call for
>
> Pseudo Wire Virtual = Circuit Connectivity Verification (VCCV)
> h= ttp://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
>=
> last call will end 6th February.
>
> There are = a couple of issues that I have with regard to
> IANA policy = that is raised by this draft, but I will
> ask my questions in = another thread.
>
> Regards
>
> = Stewart
>
> = _______________________________________________
> pwe3 mailing = list
> pwe3@ietf.org
> = https://www1.ietf.org= /mailman/listinfo/pwe3
>
> = _______________________________________________
> pwe3 mailing = list
> pwe3@ietf.org
> = https://www1.ietf.org= /mailman/listinfo/pwe3

_______________________________________________
pwe3 = mailing list
pwe3@ietf.org
https://www1.ietf.org/m= ailman/listinfo/pwe3


= --Apple-Mail-14-409332491-- --===============1265725314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1265725314==-- From pwe3-bounces@ietf.org Fri Jan 26 15:29:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXhS-0006k0-Aj; Fri, 26 Jan 2007 15:29:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXhR-0006jr-2a; Fri, 26 Jan 2007 15:29:29 -0500 Received: from [213.46.243.15] (helo=amsfep12-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAXhP-0001G4-KZ; Fri, 26 Jan 2007 15:29:29 -0500 Received: from [192.168.17.3] (really [62.195.168.62]) by amsfep12-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126202921.BNZV1957.amsfep12-int.chello.nl@[192.168.17.3]>; Fri, 26 Jan 2007 21:29:21 +0100 Message-ID: <45BA649F.7070703@chello.nl> Date: Fri, 26 Jan 2007 21:29:19 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stewart Bryant Subject: Re: [PWE3] Re: Y.1720 liased text References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> <45BA5072.8060005@chello.nl> <45BA5707.3070503@cisco.com> In-Reply-To: <45BA5707.3070503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, You replied: >> [hvh] the text does also not mention a specific value of the S-bit, >> so I suppose either value of the S-bit is allowed. >> If I would try to implement this protection, the LSR >> providing the protection would build the LSE according to >> RFC3032 and then add the 4 octet sequence number. > > ... but it would not be building a label stack it would be > building a something else. [hvh] then I suggest that you/your company writes a contribution explaining this and sent it to q9/15 proposing a correction to Y.1720 >> [hvh] if the the config was careful the router that pops the >> label inserted by the router that is the source of the protection >> knows that the 4 octets following this popped label is the >> sequene number and treats it accordingly. > > You can do lots of things if you are careful, but that does > not mean that they should be done. We have no idea what > the consequences of stray data in the stack are, or how > they impact any developments we might wish to make in the > future. > >> [hvh] ehh, it was described in >> http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt >> >> This draft was presented and discussed in the IETF53 meeting. >> The meeting notes nor the discussion afterwards on the MPLS WG list >> mention the fact that it contains a new LFIB action. > > Actually I see that you ran out of time at the meeting, and then > not much. ==================== diclaimer ==================================== I (Huub van Helvoort), did not write/present this draft. So I could not run out of time. (IETF64 was the first meeting I attended). I am editor of Y.1720 since 2004 when this text was already in the appendix. As an editor I can only change text by consensus based on contributions and discussion during drafting. =================================================================== I regret that I tried to help resolve this issue. >> [hvh] maybe, but apparently when the text was drafted there were no >> contributions providing/requesting these specifications, and >> when the recommendation was approved (as usual in ITU-T by >> consensus) nobody objected, in the meeting of the Q3/13, at >> the closing plenary, nor during the AAP. > > I am not sure that presenting a draft at one IETF meeting - which > ran out of time - and then letting the draft die constitutes > IETF approval for the design. Before the contribution proposing the addition of this text reached the ITU-T it has passed the USA approval process (maybe ANSI, but at least SGB). Is was contributed as a USA contribution so no US companies objected against the text. Is it wrong to assume that these companies will ask their experts to review such documents? and that some of these experts attend IETF meetings? Regards, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jan 26 15:52:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY3D-0002lF-OL; Fri, 26 Jan 2007 15:51:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY3C-0002l7-AM for pwe3@ietf.org; Fri, 26 Jan 2007 15:51:58 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAY3B-0004e4-6S for pwe3@ietf.org; Fri, 26 Jan 2007 15:51:58 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2007 12:51:56 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0QKpuU9007251; Fri, 26 Jan 2007 12:51:56 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0QKpjnP011030; Fri, 26 Jan 2007 12:51:55 -0800 (PST) Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 15:51:51 -0500 Received: from 161.44.193.137 ([161.44.193.137]) by xmb-rtp-202.amer.cisco.com ([64.102.31.52]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 20:51:51 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Jan 2007 15:51:46 -0500 Subject: Re: [PWE3] VCCV-12 last call From: Danny Prairie To: "Tom Nadeau (tnadeau)" , AISSAOUI Mustapha Message-ID: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdBhtZrQfruBNcUSLidIGlojSRquQABPRB4 In-Reply-To: <37A3F764-A25B-4D86-BC9B-9CB1C9C8A437@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 26 Jan 2007 20:51:51.0567 (UTC) FILETIME=[CDFF51F0:01C7418B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23323; t=1169844716; x=1170708716; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dprairie@cisco.com; z=From:=20Danny=20Prairie=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20; bh=tIHR0lx/IbOAFvgaLEjbMMyhQoRLX/6Jt0XnYpcqIBY=; b=PBKQdMTkJSFHk4NG/xbiQ7mp0Dat/PcMRx7AuBfagEmFNPyQO9W8xm4lSo5SdWZuWtCpm4c6 QczOMakFjXmcBLKaRnxI5wIZXcxh6fYajhMF7XnlPnp2qmwAJbYMdwb7; Authentication-Results: sj-dkim-5; header.From=dprairie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 1.7 (+) X-Scan-Signature: 94ddbad0060c343c23e74ba9bbebbccf Cc: pwe3 , "Stewart Bryant \(stbryant\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0287241471==" Errors-To: pwe3-bounces@ietf.org > 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. --===============0287241471== Content-type: multipart/alternative; boundary="B_3252671507_4030881" > 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_3252671507_4030881 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable In regards to the CC, I would still like to see there be an ordering to ensure there is no discrepancy with the expectation of a control word being present on the packet. Regards, Danny On 1/26/07 3:16 PM, "Tom Nadeau (tnadeau)" wrote: >=20 > Mustapha,=A0 >=20 > The restrictions in question pertains to re-signaling of the PWs > and their associated capabilities AFTER they have been signaled > with LDP. This is the references to RFC 4447.=A0 We further constrained > the use of a CC/CV combination based on that, although it seems > this was a bit heavy-handed.=A0 So while I still agree that we must not > allow re-signaling of capabilities after the PW comes up, we should > allow the use of different CC/CV types (as per the advertisement > and recommended=A0precedence rules). >=20 > --Tom >=20 >=20 >> =20 >> Danny, >> =20 >> I made the same proposal in my LC comments. The problem is what you are >> proposing is not allowed by the text in=A0Section 4. The first and second >> paragraphs read: >> =20 >> "=A0 VCCV can support several types of connectivity verification types (CV >> =A0=A0 types) or protocols within several possible control channel as >> =A0=A0 defined by the control channel type (CC types), but it does not >> =A0=A0 support the use of more than one combination of both concurrently. >> =A0=A0 The specific type or types of VCCV packets accepted by a router are >> =A0=A0 indicated during capability advertisement as described in sections >> =A0=A0 5.5 and 6.2. The various VCCV CV types supported MUST be used >> =A0=A0 only when they apply to the context of the PW demultiplexor in use. >> =A0=A0 For example, LSP Ping type should only be used when MPLS is utilized >> =A0=A0 as the PSN. >> =20 >> =A0 >> =20 >> =A0=A0 Once a set of capabilities if advertised, the specific one chosen >> =A0=A0 based on the preferred order specified below in section 7. Once >> =A0=A0 a specific CC and CV type combination has been chosen, transmitted >> =A0=A0 and replied to, this type combination MUST be the only one used >> =A0=A0 until such time as the Pseudowire is re-signaled."=A0 >> =20 >> =A0 >> =20 >> Then, the first paragraph in Section 7 reads: >> =20 >> "=A0 When a PE receives a VCCV capability advertisement, >> =A0=A0 the advertisement may potentially contain more than one CC or >> =A0=A0 CV Type. In this case, it MUST use the following rules when >> =A0=A0 choosing which CC or CV type to use. It may only choose one mode >> =A0=A0 based on the rules stipulated in sections 4 and 5 above. In >> =A0=A0 particular, once a valid CC Type is used by a PE (traffic >> =A0=A0 sent using that encapsulation), the PE MUST NOT send any >> =A0=A0 traffic down another CC Type encapsulation." >> =20 >> =A0 >> =20 >> This suggests that a PE will pick a single CC type, which we want to enf= orce, >> and a single CV type, which we=A0want to relax for LSP Ping and BFD type 0= x04. >> =20 >> =A0 >> =20 >> Furthermore, I cannot find any=A0text=A0which explicitly states that a PE >> compares VCCV capabilities it advertized and those it received from its = peer >> to perform the match. After the match is made, then the PE picks up a si= ngle >> CC type from the common set following the precedence orders. For CV >> types,=A0the PE=A0can pick up more than one as long as=A0you abide by the >> restrictions governing the use of the BFD types, i.e.,: >> =20 >> 1.=A0=A0If both types 0x08 and 0x04 are part of the match, ignore 0x04. >> =20 >> 2.=A0 If both types 0x10 and 0x20 are part of the match, ignore 0x10 (ther= e is >> a typo in the paragraph before last in Section 4 which said that 0x20 mu= st be >> ignored). >> =20 >> 3. If 0x08 or 0x20 is selected, status is converyed using BFD. >> =20 >> 4. Types 0x08 and 0x020=A0should not=A0be selected if the PE uses LDP status >> notifications.=A0=A0 >> =20 >> 5. If type 0x04 or 0x10 is selected, status should still be conveyed usi= ng >> LDP status notifications. >> =20 >> =A0 >> =20 >> Mustapha. >>=20 >> =20 >>> =20 >>> =20 >>>=20 >>> From: Danny Prairie [mailto:dprairie@cisco.com] >>> Sent: Friday, January 26, 2007 10:34 AM >>> To: O'Connor, Don; Thomas D. Nadeau >>> Cc: pwe3; Stewart Bryant >>> Subject: Re: [PWE3] VCCV-12 last call >>>=20 >>> =20 >>> Hi Don, >>>=20 >>> Good point about the CV. That being said, I would advocate not encodi= ng >>> the allowed combinations explicitly, but rather advertise the capabil= ities >>> of the node, and have the peer decide which type of verification >>> operations it will perform, potentially also including the use of BFD= and >>> LSP Ping concurrently. >>>=20 >>> Regards, >>>=20 >>> Danny >>>=20 >>>=20 >>> On 1/25/07 5:46 PM, "O'Connor, Don" wrot= e: >>>=20 >>> =20 >>>> Tom >>>>=20 >>>> Section 7 indicates that only one CC mode can be used - >>>>=20 >>>> "In particular, once a valid CC Type is used by a PE (traffic >>>> =A0=A0=A0sent using that encapsulation), the PE MUST NOT send any >>>> =A0=A0=A0traffic down another CC Type encapsulation." >>>>=20 >>>> There is no statement that only one CV Type can be used. However t= he >>>> current CV precedence rules in Section 7 imply that there is a >>>> restriction that only one CV mode can be used concurrently. >>>>=20 >>>> I believe that it would be useful to have a CV mode with concurren= t LSP >>>> Ping and BFD. So my request is to add a code point for the followi= ng >>>>=20 >>>> LSP Ping + BFD for fault detection only >>>>=20 >>>> I would also suggest giving this code point the highest precedence= in >>>> the Section 7 CV precedence table >>>>=20 >>>> Regards >>>>=20 >>>> Don >>>>=20 >>>> =20 >>>>=20 >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>> Sent: Thu 1/25/2007 1:15 PM >>>> To: O'Connor, Don >>>> Cc: Stewart Bryant; pwe3 >>>> Subject: Re: [PWE3] VCCV-12 last call >>>>=20 >>>>=20 >>>>=20 >>>> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: >>>>=20 >>>>> > My reading of VCCV - 12 is that >>>>> > >>>>> > 1) It only supports BFD Base and not MPLS BFD. It can be noted = that >>>>> > draft-ietf-bfd-mpls-03.txt. is not listed among the references >>>>=20 >>>> =A0=A0=A0=A0=A0=A0=A0=A0BFD-base is only required because the bootstrapping rules >>>> required to >>>> setup BFD/VCCV are single-hop style. >>>>=20 >>>>> > 2) It is only possible to negotiate (by LDP) one CV protocol - = ICMP >>>>> > Ping, LSP Ping, or BFD (Base). So it is not possible to support >>>>> > MPLS BFD which enables concurrent use of LSP Ping and BFD >>>>=20 >>>> =A0=A0=A0=A0=A0=A0=A0=A0You do not negotiate anything per se; you advertise >>>> capabilities for >>>> VCCV. You may advertise none, one or all of the different CC/CV >>>> combinations, >>>> which means you are willing to accept any of those combinations >>>> (within the >>>> rules stipulated in the draft). The receiving side is then free to = send >>>> any of those combinations (within the rules stipulated in the draf= t), >>>> but >>>> once one is successfully sent (and acked), no others are allowed, = and >>>> no >>>> "re-negotiation" is allowed without bringing down the PW. =A0The lat= ter >>>> comes >>>> specifically from the rules stipulated in RFC 4447. >>>>=20 >>>> =A0=A0=A0=A0=A0=A0=A0=A0--Tom >>>>=20 >>>>=20 >>>>=20 >>>>> > >>>>> > Is my understanding accurate ? >>>>> > >>>>> > Regards >>>>> > >>>>> > Don >>>>> > >>>>> > -----Original Message----- >>>>> > From: Stewart Bryant [mailto:stbryant@cisco.com] >>>>> > Sent: Monday, January 22, 2007 7:35 AM >>>>> > To: pwe3 >>>>> > Subject: [PWE3] VCCV-12 last call >>>>> > >>>>> > >>>>> > This is the start of last call for >>>>> > >>>>> > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >>>>> > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >>>>> > >>>>> > last call will end 6th February. >>>>> > >>>>> > There are a couple of issues that I have with regard to >>>>> > IANA policy that is raised by this draft, but I will >>>>> > ask my questions in another thread. >>>>> > >>>>> > Regards >>>>> > >>>>> > Stewart >>>>> > >>>>> > _______________________________________________ >>>>> > pwe3 mailing list >>>>> > pwe3@ietf.org >>>>> > https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> > >>>>> > _______________________________________________ >>>>> > pwe3 mailing list >>>>> > pwe3@ietf.org >>>>> > https://www1.ietf.org/mailman/listinfo/pwe3 >>>>=20 >>>> =20 >>>>=20 >>>> _______________________________________________ >>>> pwe3 mailing list >>>> pwe3@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>=20 >=20 >=20 --B_3252671507_4030881 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] VCCV-12 last call
In regards to the CC, I would still like to see there be an ordering to ens= ure there is no discrepancy with the expectation of a control word being pre= sent on the packet.

Regards,

Danny


On 1/26/07 3:16 PM, "Tom Nadeau (tnadeau)" <tnadeau@cisco.com&= gt; wrote:


Mustapha,=A0

The restrictions in question pertains to re-signaling of the PWs
and their associated capabilities AFTER they have been signaled
with LDP. This is the references to RFC 4447.=A0 We further constrained
the use of a CC/CV combination based on that, although it seems
this was a bit heavy-handed.=A0 So while I still agree that we must not
allow re-signaling of capabilities after the PW comes up, we should
allow the use of different CC/CV types (as per the advertisement
and recommended=A0precedence rules).

--Tom


 
Danny,
I made the same proposal in my LC comments. The p= roblem is what you are proposing is not allowed by the text in=A0Section 4. Th= e first and second paragraphs read:
"=A0 VCCV can support several types of connect= ivity verification types (CV
=A0=A0 types) or protocols within several possible control channel as
=A0=A0 defined by the control channel type (CC types), but it does not
=A0=A0 support the use of more than one combination of both concurrently.
=A0=A0 The specific type or types of VCCV packets accepted by a router are
=A0=A0 indicated during capability advertisement as described in sections
=A0=A0 5.5 and 6.2. The various VCCV CV types supported MUST be used
=A0=A0 only when they apply to the context of the PW demultiplexor in use.
=A0=A0 For example, LSP Ping type should only be used when MPLS is utilized
=A0=A0 as the PSN.
=A0
 
=A0=A0 Once a set of capabilities if advertised, the = specific one chosen
=A0=A0 based on the preferred order specified below in section 7. Once
=A0=A0 a specific CC and CV type combination has been chosen, transmitted
=A0=A0 and replied to, this type combination MUST be the only one used
=A0=A0 until such time as the Pseudowire is re-signaled."=A0
=A0
 
Then, the first paragraph in Section 7 reads:
"=A0 When a PE receives a VCCV capability adve= rtisement,
=A0=A0 the advertisement may potentially contain more than one CC or
=A0=A0 CV Type. In this case, it MUST use the following rules when
=A0=A0 choosing which CC or CV type to use. It may only choose one mode
=A0=A0 based on the rules stipulated in sections 4 and 5 above. In
=A0=A0 particular, once a valid CC Type is used by a PE (traffic
=A0=A0 sent using that encapsulation), the PE MUST NOT send any
=A0=A0 traffic down another CC Type encapsulation."
=A0
 
This suggests that a PE will pick a single CC typ= e, which we want to enforce, and a single CV type, which we=A0want to relax fo= r LSP Ping and BFD type 0x04.
=A0
 
Furthermore, I cannot find any=A0text=A0which explici= tly states that a PE compares VCCV capabilities it advertized and those it r= eceived from its peer to perform the match. After the match is made, then th= e PE picks up a single CC type from the common set following the precedence = orders. For CV types,=A0the PE=A0can pick up more than one as long as=A0you abide = by the restrictions governing the use of the BFD types, i.e.,:
1.=A0= =A0If both types 0x08 and 0x04 are part of the match= , ignore 0x04.
2.=A0 If both types 0x10 and 0x20 are part of the m= atch, ignore 0x10 (there is a typo in the paragraph before last in Section 4= which said that 0x20 must be ignored).
3. If 0x08 or 0x20 is selected, status is convery= ed using BFD.
4. Types 0x08 and 0x020=A0should not=A0be selected if= the PE uses LDP status notifications.=A0=A0
5. If type 0x04 or 0x10 is selected, status shoul= d still be conveyed using LDP status notifications.
=A0
 
Mustapha.

 
 
  
 From: Danny Prairie   [m= ailto:dprairie@cisco.com]
Sent: Friday, January 26, 2007 10:34   AM
To: O'Connor, Don; Thomas D. Nadeau
Cc: pwe3; Stewart   Bryant
Subject: Re: [PWE3] VCCV-12 last call

  
Hi Don,

Good point about the CV. That being   said, I would advocate not = encoding the allowed combinations explicitly, but   rather adverti= se the capabilities of the node, and have the peer decide which   = type of verification operations it will perform, potentially also including =   the use of BFD and LSP Ping   concurrently.

Regards,

Danny


On 1/25/07 5:46 PM,   "O'Connor, Don" <don.oconnor@u= s.fujitsu.com> wrote:

  
Tom

Section 7     indicates that = only one CC mode can be used -

"In particular,     once= a valid CC Type is used by a PE (traffic
=A0=A0=A0sent     using that encapsulation), the PE MUST NOT = send     any
=A0=A0=A0traffic down another CC Type     encapsulation."= ;

There is no     statement tha= t only one CV Type can be used. However the current CV    &nb= sp;precedence rules in Section 7 imply that there is a restriction that only=     one CV mode can be used concurrently.

I believe that     it would b= e useful to have a CV mode with concurrent LSP Ping and BFD. So my  &nb= sp;  request is to add a code point for the following

LSP Ping + BFD     for fault = detection only

I would also     suggest givi= ng this code point the highest precedence in the Section 7 CV   &n= bsp; precedence table

Regards

Don

    
   From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent:     Thu 1/25/2007 1:15 PM
To: O'Connor, Don
Cc: Stewart     Bryant; pwe3
Subject: Re: [PWE3] VCCV-12 last call



On Jan 23, 2007, at 7:22 PM,     O'Connor, Don wrote:
> My reading of VCCV - 12 is     that
>
> 1) It only supports BFD Base and not MPLS BFD. It can   &nbs= p; be noted that
> draft-ietf-bfd-mpls-03.txt. is not listed among the    =  references

=A0=A0=A0=A0=A0=A0=A0=A0BFD-base     is only required because the boots= trapping rules required to
setup     BFD/VCCV are single-hop style.

> 2) It is only possible to     negotiate (by LDP) o= ne CV protocol - ICMP
> Ping, LSP Ping, or BFD     (Base). So it is not po= ssible to support
> MPLS BFD which enables     concurrent use of LSP P= ing and     BFD

=A0=A0=A0=A0=A0=A0=A0=A0You do not     negotiate anything per se; you a= dvertise capabilities for
VCCV. You may     advertise none, one or all of the dif= ferent CC/CV
combinations,
which     means you are willing to accept any of those = combinations
(within     the
rules stipulated in the draft). The receiving side is then free to  &n= bsp;  send
any of those combinations (within the rules stipulated in the   &= nbsp; draft),
but
once one is successfully sent (and acked), no others are    =  allowed, and no
"re-negotiation" is allowed without bringing down the PW.  &= nbsp;  =A0The latter
comes
specifically from the rules stipulated in RFC     4447.=

=A0=A0=A0=A0=A0=A0=A0=A0--Tom



>
>     Is my understanding accurate ?
>
> Regards
>
>     Don
>
> -----Original Message-----
> From: Stewart Bryant     [mailto:stbryant@cisco.com]
>     Sent: Monday, January 22, 2007 7:35 AM
> To: pwe3
> Subject:     [PWE3] VCCV-12 last call
>
>
> This is the start of last     call for
>
> Pseudo Wire Virtual Circuit Connectivity     Verif= ication (VCCV)
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
>
>     last call will end 6th February.
>
> There are a couple of     issues that I have with = regard to
> IANA policy that is raised by this     draft, but = I will
> ask my questions in another     thread.
>
> Regards
>
> Stewart
>
>     ______________________________________________= _
> pwe3 mailing     list
> pwe3@ietf.org
>     https://www1.ietf.org/mailman/listinfo/pwe3 >
>     ______________________________________________= _
> pwe3 mailing     list
> pwe3@ietf.org
>     https://www1.ietf.org/mailman/listinfo/pwe3
    
   _= ______________________________________________
pwe3     mailing     list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3




 --B_3252671507_4030881-- --===============0287241471== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0287241471==-- From pwe3-bounces@ietf.org Fri Jan 26 16:28:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYbO-00047R-8v; Fri, 26 Jan 2007 16:27:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYbM-00047L-3b for pwe3@ietf.org; Fri, 26 Jan 2007 16:27:16 -0500 Received: from audl951.usa.alcatel.com ([143.209.238.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAYbL-0001rh-3S for pwe3@ietf.org; Fri, 26 Jan 2007 16:27:16 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id l0QLR8am028590; Fri, 26 Jan 2007 15:27:09 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 26 Jan 2007 15:27:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] VCCV-12 last call Date: Fri, 26 Jan 2007 15:26:30 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdBhtZrQfruBNcUSLidIGlojSRquQABPRB4AADJp/A= References: <37A3F764-A25B-4D86-BC9B-9CB1C9C8A437@cisco.com> From: "AISSAOUI Mustapha" To: "Danny Prairie" , "Tom Nadeau \(tnadeau\)" X-OriginalArrivalTime: 26 Jan 2007 21:27:08.0625 (UTC) FILETIME=[BBDCBC10:01C74190] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.1 (/) X-Scan-Signature: c72c29da2ca4b2bd12d89dfc936ad645 Cc: pwe3 , "Stewart Bryant \(stbryant\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0522775213==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0522775213== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74190.A6A7D1A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74190.A6A7D1A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Absolutely. Only a single CC mode should be selected from the matching set and if more than one match, use the precedence indicated in the draft. For the CV type, it is allowed to select more than one as long as one abides by the restrictions below. =20 Mustapha. ________________________________ From: Danny Prairie [mailto:dprairie@cisco.com]=20 Sent: Friday, January 26, 2007 3:52 PM To: Tom Nadeau (tnadeau); AISSAOUI Mustapha Cc: O'Connor, Don; pwe3; Stewart Bryant (stbryant) Subject: Re: [PWE3] VCCV-12 last call =09 In regards to the CC, I would still like to see there be an ordering to ensure there is no discrepancy with the expectation of a control word being present on the packet. =09 Regards, =09 Danny =09 =09 On 1/26/07 3:16 PM, "Tom Nadeau (tnadeau)" wrote: =09 =09 =09 Mustapha,=20 =09 The restrictions in question pertains to re-signaling of the PWs and their associated capabilities AFTER they have been signaled with LDP. This is the references to RFC 4447. We further constrained the use of a CC/CV combination based on that, although it seems this was a bit heavy-handed. So while I still agree that we must not allow re-signaling of capabilities after the PW comes up, we should allow the use of different CC/CV types (as per the advertisement and recommended precedence rules). =09 --Tom =09 =09 =09 =09 Danny, =09 I made the same proposal in my LC comments. The problem is what you are proposing is not allowed by the text in Section 4. The first and second paragraphs read: =09 " VCCV can support several types of connectivity verification types (CV=20 types) or protocols within several possible control channel as=20 defined by the control channel type (CC types), but it does not=20 support the use of more than one combination of both concurrently.=20 The specific type or types of VCCV packets accepted by a router are indicated during capability advertisement as described in sections=20 5.5 and 6.2. The various VCCV CV types supported MUST be used only when they apply to the context of the PW demultiplexor in use. For example, LSP Ping type should only be used when MPLS is utilized as the PSN. =09 =20 =20 Once a set of capabilities if advertised, the specific one chosen=20 based on the preferred order specified below in section 7. Once=20 a specific CC and CV type combination has been chosen, transmitted=20 and replied to, this type combination MUST be the only one used=20 until such time as the Pseudowire is re-signaled."=20 =09 =20 =20 Then, the first paragraph in Section 7 reads: =09 " When a PE receives a VCCV capability advertisement, the advertisement may potentially contain more than one CC or CV Type. In this case, it MUST use the following rules when=20 choosing which CC or CV type to use. It may only choose one mode based on the rules stipulated in sections 4 and 5 above. In particular, once a valid CC Type is used by a PE (traffic sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation." =09 =20 =20 This suggests that a PE will pick a single CC type, which we want to enforce, and a single CV type, which we want to relax for LSP Ping and BFD type 0x04. =09 =20 =20 Furthermore, I cannot find any text which explicitly states that a PE compares VCCV capabilities it advertized and those it received from its peer to perform the match. After the match is made, then the PE picks up a single CC type from the common set following the precedence orders. For CV types, the PE can pick up more than one as long as you abide by the restrictions governing the use of the BFD types, i.e.,: =09 1. If both types 0x08 and 0x04 are part of the match, ignore 0x04. =09 2. If both types 0x10 and 0x20 are part of the match, ignore 0x10 (there is a typo in the paragraph before last in Section 4 which said that 0x20 must be ignored). =09 3. If 0x08 or 0x20 is selected, status is converyed using BFD. =09 4. Types 0x08 and 0x020 should not be selected if the PE uses LDP status notifications. =20 =09 5. If type 0x04 or 0x10 is selected, status should still be conveyed using LDP status notifications. =09 =20 =20 Mustapha. =09 =20 =09 =09 =20 =09 ________________________________ From: Danny Prairie [mailto:dprairie@cisco.com]=20 Sent: Friday, January 26, 2007 10:34 AM To: O'Connor, Don; Thomas D. Nadeau Cc: pwe3; Stewart Bryant Subject: Re: [PWE3] VCCV-12 last call =09 =20 Hi Don, =09 Good point about the CV. That being said, I would advocate not encoding the allowed combinations explicitly, but rather advertise the capabilities of the node, and have the peer decide which type of verification operations it will perform, potentially also including the use of BFD and LSP Ping concurrently. =09 Regards, =09 Danny =09 =09 On 1/25/07 5:46 PM, "O'Connor, Don" wrote: =09 =20 =09 Tom =09 Section 7 indicates that only one CC mode can be used -=20 =09 "In particular, once a valid CC Type is used by a PE (traffic=20 sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation." =09 There is no statement that only one CV Type can be used. However the current CV precedence rules in Section 7 imply that there is a restriction that only one CV mode can be used concurrently.=20 =09 I believe that it would be useful to have a CV mode with concurrent LSP Ping and BFD. So my request is to add a code point for the following=20 =09 LSP Ping + BFD for fault detection only =09 I would also suggest giving this code point the highest precedence in the Section 7 CV precedence table =09 Regards =09 Don =09 =20 =09 ________________________________ From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thu 1/25/2007 1:15 PM To: O'Connor, Don Cc: Stewart Bryant; pwe3 Subject: Re: [PWE3] VCCV-12 last call =09 =09 =09 On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: =09 > My reading of VCCV - 12 is that > > 1) It only supports BFD Base and not MPLS BFD. It can be noted that=20 > draft-ietf-bfd-mpls-03.txt. is not listed among the references =09 BFD-base is only required because the bootstrapping rules required to setup BFD/VCCV are single-hop style. =09 > 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP=20 > Ping, LSP Ping, or BFD (Base). So it is not possible to support=20 > MPLS BFD which enables concurrent use of LSP Ping and BFD =09 You do not negotiate anything per se; you advertise capabilities for VCCV. You may advertise none, one or all of the different CC/CV=20 combinations, which means you are willing to accept any of those combinations=20 (within the rules stipulated in the draft). The receiving side is then free to send any of those combinations (within the rules stipulated in the draft),=20 but once one is successfully sent (and acked), no others are allowed, and no "re-negotiation" is allowed without bringing down the PW. The latter=20 comes specifically from the rules stipulated in RFC 4447. =09 --Tom =09 =09 =09 > > Is my understanding accurate ? > > Regards > > Don > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, January 22, 2007 7:35 AM > To: pwe3 > Subject: [PWE3] VCCV-12 last call > > > This is the start of last call for > > Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > last call will end 6th February. > > There are a couple of issues that I have with regard to > IANA policy that is raised by this draft, but I will > ask my questions in another thread. > > Regards > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 =09 =20 =09 ________________________________ =09 _______________________________________________ pwe3 mailing list pwe3@ietf.org =09 https://www1.ietf.org/mailman/listinfo/pwe3 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C74190.A6A7D1A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [PWE3] VCCV-12 last call
Absolutely. Only a single CC mode should be selected from the = matching=20 set and if more than one match, use the precedence indicated in the = draft. For=20 the CV type, it is allowed to select more than one as long as one abides = by the=20 restrictions below.
 
Mustapha.
From: Danny Prairie = [mailto:dprairie@cisco.com]=20
Sent: Friday, January 26, 2007 3:52 PM
To: Tom = Nadeau=20 (tnadeau); AISSAOUI Mustapha
Cc: O'Connor, Don; pwe3; Stewart = Bryant=20 (stbryant)
Subject: Re: [PWE3] VCCV-12 last = call


In regards to the CC, I would still like = to see=20 there be an ordering to ensure there is no discrepancy with the = expectation of=20 a control word being present on the=20 packet.

Regards,

Danny


On 1/26/07 3:16 PM, = "Tom=20 Nadeau (tnadeau)" <tnadeau@cisco.com> = wrote:

Mustapha, 

The = restrictions in=20 question pertains to re-signaling of the PWs
and their associated = capabilities AFTER they have been signaled
with LDP. This is the=20 references to RFC 4447.  We further constrained
the use of a = CC/CV=20 combination based on that, although it seems
this was a bit=20 heavy-handed.  So while I still agree that we must not
allow = re-signaling of capabilities after the PW comes up, we = should
allow the=20 use of different CC/CV types (as per the advertisement
and=20 recommended precedence = rules).

--Tom

Danny,

I = made the=20 same proposal in my LC comments. The problem is what you are = proposing is=20 not allowed by the text in Section 4. The first and second = paragraphs=20 read:

"  VCCV can support several types of = connectivity=20 verification types (CV
   types) or protocols within = several=20 possible control channel as
   defined by the = control=20 channel type (CC types), but it does not
   support = the use=20 of more than one combination of both concurrently. =
   The=20 specific type or types of VCCV packets accepted by a router=20 are
   indicated during capability advertisement as = described=20 in sections
   5.5 and 6.2. The various VCCV CV = types=20 supported MUST be used
   only when they apply to the = context=20 of the PW demultiplexor in use.
   For example, LSP = Ping type=20 should only be used when MPLS is utilized
   as the=20 PSN.

 
 
   Once a set of capabilities if = advertised, the=20 specific one chosen
   based on the preferred order=20 specified below in section 7. Once
   a specific CC = and CV=20 type combination has been chosen, transmitted
   and = replied=20 to, this type combination MUST be the only one used =
   until=20 such time as the Pseudowire is re-signaled." 

 
 
Then, the first paragraph in Section 7 = reads:

"  When=20 a PE receives a VCCV capability advertisement,
   the = advertisement may potentially contain more than one CC = or
  =20 CV Type. In this case, it MUST use the following rules when=20
   choosing which CC or CV type to use. It may only = choose=20 one mode
   based on the rules stipulated in sections = 4 and 5=20 above. In
   particular, once a valid CC Type is used = by a PE=20 (traffic
   sent using that encapsulation), the PE = MUST NOT=20 send any
   traffic down another CC Type=20 encapsulation."

 
 
This suggests that a PE will pick a single CC type, = which we=20 want to enforce, and a single CV type, which we want to relax = for LSP=20 Ping and BFD type 0x04.

 
 
Furthermore, I cannot find any text which = explicitly=20 states that a PE compares VCCV capabilities it advertized and = those it=20 received from its peer to perform the match. After the match is = made, then=20 the PE picks up a single CC type from the common set following the = precedence orders. For CV types, the PE can pick up more = than=20 one as long as you abide by the restrictions governing the = use of the=20 BFD types, i.e.,:

1.  If both=20 types 0x08 and 0x04 are part of the match, ignore = 0x04.

2.  If=20 both types 0x10 and 0x20 are part of the match, ignore 0x10 (there = is a=20 typo in the paragraph before last in Section 4 which said that = 0x20 must=20 be ignored).

3. If 0x08 or=20 0x20 is selected, status is converyed using BFD.

4. Types 0x08=20 and 0x020 should not be selected if the PE uses LDP = status=20 notifications.  

5. If type=20 0x04 or 0x10 is selected, status should still be conveyed using = LDP status=20 notifications.

 
 
Mustapha.

 

  
 From: Danny Prairie=20   [mailto:dprairie@cisco.com]=20
Sent: Friday, January 26, 2007 10:34=20   AM
To: O'Connor, Don; Thomas D.=20 Nadeau
Cc: pwe3; Stewart =   Bryant
Subject:=20 Re: [PWE3] VCCV-12 last call

  
Hi = Don,

Good=20 point about the CV. That being   said, I would = advocate not=20 encoding the allowed combinations explicitly, but =   rather=20 advertise the capabilities of the node, and have the peer decide = which=20   type of verification operations it will perform, = potentially=20 also including   the use of BFD and LSP Ping=20 =   concurrently.

Regards,

Danny


On=20 1/25/07 5:46 PM,   "O'Connor, Don"=20 <don.oconnor@us.fujitsu.com>=20 wrote:

  
Tom

Section 7=20     indicates that only one CC mode can be = used -=20

"In particular,     once a = valid CC=20 Type is used by a PE (traffic
   sent=20     using that encapsulation), the PE MUST = NOT=20 send     any
   traffic = down=20 another CC Type=20     encapsulation."

There is=20 no     statement that only one CV Type can = be=20 used. However the current CV =     precedence rules=20 in Section 7 imply that there is a restriction that only=20     one CV mode can be used concurrently.=20

I believe that     it would = be useful=20 to have a CV mode with concurrent LSP Ping and BFD. So my=20     request is to add a code point for the = following

LSP Ping=20 + BFD     for fault detection = only

I would=20 also     suggest giving this code point = the=20 highest precedence in the Section 7 CV=20     precedence table

Regards

Don

    
   From: = Thomas D.=20 Nadeau [mailto:tnadeau@cisco.com]
Se= nt:=20     Thu 1/25/2007 1:15 PM
To: = O'Connor,=20 Don
Cc: Stewart     Bryant;=20 pwe3
Subject: Re: [PWE3] VCCV-12 last = call



On Jan 23, = 2007, at 7:22=20 PM,     O'Connor, Don wrote:

> = My=20 reading of VCCV - 12 is =     that
>
>=20 1) It only supports BFD Base and not MPLS BFD. It can=20     be noted that
>=20 draft-ietf-bfd-mpls-03.txt. is not listed among the=20 =     references

     &= nbsp;  BFD-base=20     is only required because the = bootstrapping=20 rules required to
setup     BFD/VCCV = are=20 single-hop style.

> 2) It is only possible to=20     negotiate (by LDP) one CV protocol - = ICMP=20
> Ping, LSP Ping, or BFD =     (Base). So it=20 is not possible to support
> MPLS BFD which enables=20     concurrent use of LSP Ping and=20 =     BFD

      &n= bsp; You=20 do not     negotiate anything per se; you=20 advertise capabilities for
VCCV. You may=20     advertise none, one or all of the = different=20 CC/CV
combinations,
which     means = you are=20 willing to accept any of those combinations
(within=20     the
rules stipulated in the draft). = The=20 receiving side is then free to =     send
any of=20 those combinations (within the rules stipulated in the=20     draft),
but
once one is = successfully=20 sent (and acked), no others are =     allowed, and=20 no
"re-negotiation" is allowed without bringing down the = PW.=20      The latter =
comes
specifically=20 from the rules stipulated in RFC=20 =     4447.

      =   --Tom



>
>=20     Is my understanding accurate = ?
>
>=20 Regards
>
> =     Don
>
>=20 -----Original Message-----
> From: Stewart Bryant=20     [mailto:stbryant@cisco.com]
>= ;=20     Sent: Monday, January 22, 2007 7:35 = AM
>=20 To: pwe3
> Subject:     [PWE3] = VCCV-12 last=20 call
>
>
> This is the start of last=20     call for
>
> Pseudo Wire = Virtual=20 Circuit Connectivity     Verification=20 (VCCV)
> = http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
&g= t;
>=20     last call will end 6th=20 February.
>
> There are a couple of=20     issues that I have with regard = to
> IANA=20 policy that is raised by this     draft, = but I=20 will
> ask my questions in another=20     thread.
>
>=20 Regards
>
> Stewart
>
>=20 =     _______________________________________________>=20 pwe3 mailing     list
>=20 pwe3@ietf.org
>=20 =     https://www1.ietf.org/mailman/listinfo/pwe3
&g= t;
>=20 =     _______________________________________________>=20 pwe3 mailing     list
>=20 pwe3@ietf.org
>=20 =     https://www1.ietf.org/mailman/listinfo/pwe3
    
   _______________________________________________
pwe3=20     mailing=20 =     list
pwe3@ietf.org
https://www1.ietf.org/ma= ilman/listinfo/pwe3




------_=_NextPart_001_01C74190.A6A7D1A1-- --===============0522775213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0522775213==-- From pwe3-bounces@ietf.org Fri Jan 26 22:25:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAeAa-0007e4-Gj; Fri, 26 Jan 2007 22:24:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAeAY-0007Wb-ME for pwe3@ietf.org; Fri, 26 Jan 2007 22:23:58 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAeAY-0008WV-6H for pwe3@ietf.org; Fri, 26 Jan 2007 22:23:58 -0500 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l0R3NvJ02037; Fri, 26 Jan 2007 22:23:57 -0500 (EST) Received: from [10.83.216.147] (rtp-cpignata-vpn2.cisco.com [10.83.216.147]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with SMTP id l0R3Ntq00842; Fri, 26 Jan 2007 22:23:55 -0500 (EST) Message-ID: <45BAC5CB.7070003@cisco.com> Date: Fri, 26 Jan 2007 22:23:55 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: AISSAOUI Mustapha Subject: Re: [PWE3] VCCV-12 last call References: <37A3F764-A25B-4D86-BC9B-9CB1C9C8A437@cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: "Tom Nadeau \(tnadeau\)" , pwe3 , "Stewart Bryant \(stbryant\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org It seems there should be one further restriction. Only CC Type 1 (PW ACH) has a PID (i.e, the Channel Type); for CC Types 2 and 3 (RA and TTL), if wanting to have BFD and LSP Ping, BFD without IP/UDP headers should not be used as a CV Type -- BFD with IP/UDP can be discriminated from LSP Ping and ICMP using the IP Protocol/UDP Port numbers in that case. Thanks, --Carlos. On 1/26/2007 4:26 PM, AISSAOUI Mustapha allegedly said the following: > Absolutely. Only a single CC mode should be selected from the matching > set and if more than one match, use the precedence indicated in the > draft. For the CV type, it is allowed to select more than one as long as > one abides by the restrictions below. > > Mustapha. > ------------------------------------------------------------------------ > *From:* Danny Prairie [mailto:dprairie@cisco.com] > *Sent:* Friday, January 26, 2007 3:52 PM > *To:* Tom Nadeau (tnadeau); AISSAOUI Mustapha > *Cc:* O'Connor, Don; pwe3; Stewart Bryant (stbryant) > *Subject:* Re: [PWE3] VCCV-12 last call > > > In regards to the CC, I would still like to see there be an ordering > to ensure there is no discrepancy with the expectation of a control > word being present on the packet. > > Regards, > > Danny > > > On 1/26/07 3:16 PM, "Tom Nadeau (tnadeau)" wrote: > > > Mustapha, > > The restrictions in question pertains to re-signaling of the PWs > and their associated capabilities AFTER they have been signaled > with LDP. This is the references to RFC 4447. We further > constrained > the use of a CC/CV combination based on that, although it seems > this was a bit heavy-handed. So while I still agree that we > must not > allow re-signaling of capabilities after the PW comes up, we should > allow the use of different CC/CV types (as per the advertisement > and recommended precedence rules). > > --Tom > > > > Danny, > > I made the same proposal in my LC comments. The problem is > what you are proposing is not allowed by the text in Section > 4. The first and second paragraphs read: > > " VCCV can support several types of connectivity > verification types (CV > types) or protocols within several possible control > channel as > defined by the control channel type (CC types), but it > does not > support the use of more than one combination of both > concurrently. > The specific type or types of VCCV packets accepted by a > router are > indicated during capability advertisement as described in > sections > 5.5 and 6.2. The various VCCV CV types supported MUST be used > only when they apply to the context of the PW > demultiplexor in use. > For example, LSP Ping type should only be used when MPLS > is utilized > as the PSN. > > > > Once a set of capabilities if advertised, the specific > one chosen > based on the preferred order specified below in section > 7. Once > a specific CC and CV type combination has been chosen, > transmitted > and replied to, this type combination MUST be the only > one used > until such time as the Pseudowire is re-signaled." > > > > Then, the first paragraph in Section 7 reads: > > " When a PE receives a VCCV capability advertisement, > the advertisement may potentially contain more than one CC or > CV Type. In this case, it MUST use the following rules when > choosing which CC or CV type to use. It may only choose > one mode > based on the rules stipulated in sections 4 and 5 above. In > particular, once a valid CC Type is used by a PE (traffic > sent using that encapsulation), the PE MUST NOT send any > traffic down another CC Type encapsulation." > > > > This suggests that a PE will pick a single CC type, which we > want to enforce, and a single CV type, which we want to > relax for LSP Ping and BFD type 0x04. > > > > Furthermore, I cannot find any text which explicitly states > that a PE compares VCCV capabilities it advertized and those > it received from its peer to perform the match. After the > match is made, then the PE picks up a single CC type from > the common set following the precedence orders. For CV > types, the PE can pick up more than one as long as you abide > by the restrictions governing the use of the BFD types, i.e.,: > > 1. If both types 0x08 and 0x04 are part of the match, > ignore 0x04. > > 2. If both types 0x10 and 0x20 are part of the match, > ignore 0x10 (there is a typo in the paragraph before last in > Section 4 which said that 0x20 must be ignored). > > 3. If 0x08 or 0x20 is selected, status is converyed using BFD. > > 4. Types 0x08 and 0x020 should not be selected if the PE > uses LDP status notifications. > > 5. If type 0x04 or 0x10 is selected, status should still be > conveyed using LDP status notifications. > > > > Mustapha. > > > > > > ------------------------------------------------------------------------ > *From:* Danny Prairie [mailto:dprairie@cisco.com] > *Sent:* Friday, January 26, 2007 10:34 AM > *To:* O'Connor, Don; Thomas D. Nadeau > *Cc:* pwe3; Stewart Bryant > *Subject:* Re: [PWE3] VCCV-12 last call > > > Hi Don, > > Good point about the CV. That being said, I would > advocate not encoding the allowed combinations > explicitly, but rather advertise the capabilities of > the node, and have the peer decide which type of > verification operations it will perform, potentially > also including the use of BFD and LSP Ping concurrently. > > Regards, > > Danny > > > On 1/25/07 5:46 PM, "O'Connor, Don" > wrote: > > > > Tom > > Section 7 indicates that only one CC mode can be > used - > > "In particular, once a valid CC Type is used by > a PE (traffic > sent using that encapsulation), the PE MUST > NOT send any > traffic down another CC Type encapsulation." > > There is no statement that only one CV Type can > be used. However the current CV precedence rules > in Section 7 imply that there is a restriction that > only one CV mode can be used concurrently. > > I believe that it would be useful to have a CV > mode with concurrent LSP Ping and BFD. So my > request is to add a code point for the following > > LSP Ping + BFD for fault detection only > > I would also suggest giving this code point the > highest precedence in the Section 7 CV > precedence table > > Regards > > Don > > > ------------------------------------------------------------------------ > *From:* Thomas D. Nadeau [mailto:tnadeau@cisco.com] > *Sent:* Thu 1/25/2007 1:15 PM > *To:* O'Connor, Don > *Cc:* Stewart Bryant; pwe3 > *Subject:* Re: [PWE3] VCCV-12 last call > > > > On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: > > > My reading of VCCV - 12 is that > > > > 1) It only supports BFD Base and not MPLS BFD. It > can be noted that > > draft-ietf-bfd-mpls-03.txt. is not listed among the > references > > BFD-base is only required because the > bootstrapping rules required to > setup BFD/VCCV are single-hop style. > > > 2) It is only possible to negotiate (by LDP) > one CV protocol - ICMP > > Ping, LSP Ping, or BFD (Base). So it is not > possible to support > > MPLS BFD which enables concurrent use of LSP > Ping and BFD > > You do not negotiate anything per se; > you advertise capabilities for > VCCV. You may advertise none, one or all of the > different CC/CV > combinations, > which means you are willing to accept any of > those combinations > (within the > rules stipulated in the draft). The receiving side > is then free to send > any of those combinations (within the rules > stipulated in the draft), > but > once one is successfully sent (and acked), no others > are allowed, and no > "re-negotiation" is allowed without bringing down > the PW. The latter > comes > specifically from the rules stipulated in RFC 4447. > > --Tom > > > > > > > Is my understanding accurate ? > > > > Regards > > > > Don > > > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Monday, January 22, 2007 7:35 AM > > To: pwe3 > > Subject: [PWE3] VCCV-12 last call > > > > > > This is the start of last call for > > > > Pseudo Wire Virtual Circuit Connectivity > Verification (VCCV) > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt > > > > last call will end 6th February. > > > > There are a couple of issues that I have with > regard to > > IANA policy that is raised by this draft, but I > will > > ask my questions in another thread. > > > > Regards > > > > Stewart > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > ------------------------------------------------------------------------ > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sat Jan 27 05:40:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAkxE-0001B0-Oo; Sat, 27 Jan 2007 05:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAkxC-0001Aj-Ff; Sat, 27 Jan 2007 05:38:38 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAkx2-0004fM-MN; Sat, 27 Jan 2007 05:38:38 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 10:38:16 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 Jan 2007 10:38:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] RE: [PWE3] Re: Y.1720 liased text Date: Sat, 27 Jan 2007 10:38:15 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AF50933@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RE: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBfLlXJ3ysepdtRL2eiZpEQ95QZAABJLLwABcCmIA= From: To: , X-OriginalArrivalTime: 27 Jan 2007 10:38:15.0937 (UTC) FILETIME=[4095BF10:01C741FF] X-Spam-Score: 0.2 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: mpls@ietf.org, pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Deborah, Think it's high time we distinguished the symptom from the cause here. The problem is NOT the 1+1 prot-sw scheme...indeed this could be ANY function.....this is simply a symptom. So let's first be clear on this aspect. The real problem is the way MPLS has been designed. However, because of the amount of MPLS deployed to date I believe we will almost certainly end-up attacking/deprecating things that expose these design problems....like the 1+1 prot-sw scheme under discussion here. Despite this we should, IMO at least, attempt to accurately explain WHY it's creating a problem.....else we are not providing an objective technical analysis to the larger community. The real causal problem here is the MPLS stack. Stacked LSPs do NOT form a client/server relationship....they are all functionally coupled....and the functional coupling itself is not consistent. A key observation here is that MPLS does not treat its clients consistently...that is: - if IP then =3D> null encaps *OR* peer PDU.....which when coldly analysed means that a cl-ps IP layer network and (something that looks like) a co-ps layer network (ie MPLS) are co-existing in the *same layer network* space.....and for those folks familiar with functional architecture this should immediately ring alarm bells as 'a bit of a problem'.....this BTW is one of the reasons why some folks are pushing T-MPLS...however I don't want to get into that particular symptom here. - if MPLS then =3D> digital wrapper.....this holds the tantalising illusion that one can create topology on the fly by simply adding another MPLS header.....this, however, does not work. - if 'other' then =3D> PW encapsulation. This is a direct consequence of the above. Its practical impact however was fairly benign when PWs were restricted to 1-hop as we could treat these largely as a form of 'adaptation'. However, when PW entities become multi-hop we have no choice but to start off down the road of creating a new co-ps mode PW layer network above the hybrid IP/MPLS layer network. That is just the way it is. Now let's return to the 1+1 prot-sw symptom and try and understand why it exposes a design problem for MPLS against the above background. - the MPLS digital wrapper stack uses the rules: (i) if S=3D0 then another MPLS header follows and (ii) if S=3D1 another MPLS header does = not follow.....so what does follow? - well, it might be an IP packet or it might be a PW encapsulated packet. Noting that because of the different way MPLS treats its clients (including itself as a digital wrapper) AND the fact that ECMP mechanisms use the 1st nibble of an IP packet to distinguish v4 and v6 variants, the PW encapsulated packet must have a way to distinguish itself from the IP packet in the 1st nibble. Ergo the control-word structure of PW adaptation....at least the 1st nibble therein. Same distinguishing issue arises with the VCCV stuff....which is now yet another client type but only applicable with PWs (ie PW and VCCV clients are muxed together). - a critical question we should ask at this point is 'what happens if MPLS LSPs get misconnected?' And the first architectural design observation we can make here is that the functional fields in traffic units SHOULD (though I would say MUST) have consistent semantics if, under misconnectivity, the consequential behaviour is to be consistent/predictable....this should be especially obvious as a requirement for the OAM mechanisms if nothing else! - so let's look at MPLS itself here. The S/EXP/TTL fields do remain fairly consistent but the label field does not. The 1st functional split relates to the 0-15 reserved labels (that imply an 'action') and the rest of the labels.....nothing wrong here in concept as the semantics are clear and not assigned to arbitrary labels. Now in normal co-ps mode destination forwarding the label is a locally-significant (ie link connection) proxy for the trail's globally-significant destination address (DA). However, in MPLS we also permit mp2p merging behaviour (both LDP and PHP create merging). This requires that labels must also be able to take on a different functional 'demerging' role of being a proxy for a trail's globally-significant source address (SA). Further, there are 2 subtle spins on this: * if the client is a PW then the demerging label provides a 1:1 identification of the ultimate client instance; * if the client is a rfc4364 (ex rfc2547) IP VPN then the demerging label only resolves to a specific client VRF instance within a certain VPN.....the ultimate (IP) client is then always resolvable within its VPN instance because cl-ps mode traffic units MUST always carry globally-significant (ie with the layer network of interest...here a VPN) SA label. - so we already see we do not have consistent label semantics in MPLS per se. And because LSPs can be stacked and are functionally coupled, then not only can we have misconnectivity between LSPs at the same level in the stack but also between LSPs at different levels in the stack. So under misconnectivity the way in which the receiving LSR regards the semantics of the label field may not be consistent. - now let's now look at the 1+1 prot-sw function mentioned in Y.1720 in the context of the above; =20 - if the 1+1 function is below (ie payload to) an MPLS header with S=3D1 (ie no more MPLS headers follow) then there is no problem if there is no misconnectivity. However, under misconnectivity to a non 1+1 receiving LSR, that LSR will attempt to parse the payload as either an IP packet or a PW packet.....and the consequential behaviour will not be consistent/predictable because it will depend what is in the 1st nibble of the payload as the receiving LSR interprets this. Note however that if we ran, for example, a Y.1711 OAM CV flow on this LSP (actually ALL LSPs because we do not know which LSPs will experience misconnectivity ahead of the event) we should be able to detect the problem. Note also the importance of running the SAME OAM mechanism on all LSPs.....it is NOT sufficient to have OAM only associated with PWs! - if the 1+1 function can exist immediately following an MPLS header with S=3D0 then this is IMO a direct violation of the MPLS = stacking rules *irrespective* of the effects of misconnectivity. Why? Because normally this (ie S=3D0) indicates that this is not the bottom of the = MPLS header stack and that a further MPLS header follows.....but here it is not an MPLS header that follows but (in this case) a 1+1 prot-sw function. - now consider what happens under misconnectivity in the S=3D0 case. This is NOT like the previous S=3D1 case because the receiving LSR will attempt to parse the next 4 octets as an MPLS client header (and not an IP or PW client as in the S=3D1 case). However, it seems this case = would also be detectable if one ran a Y.1711 OAM CV flow (and on ALL LSPs for the reasons noted previously). Note again the importance of running the SAME OAM mechanism on all LSPs.....it is NOT sufficient to have OAM only associated with PWs! So what do we conclude/learn from all this. 1 Well, the real problem lies with MPLS and not the 1+1 scheme per se. 2 But it's far too late now to go back and re-spin MPLS (maybe the T-MPLS advocates disagree?) 3 If we ran a consistent OAM CV flow that contains a true SA on ALL LSPs (and not just PWs) (eg as described in Y.1711 say) we should be OK.....however, nothing works well in the context mp2p merging constructs, and its not just the OAM efficacy that is impacted but it also forces us to use varying labels semantics as I discussed above that also creates a problem itself under misconnectivity....just a fact. 4 Perhaps the easiest solution is to attack/deprecate the Y.1720 symptom and ban it from MPLS?.....all the above stuff does not 'go away' of course but it may be the simplest expedient course of action. Sorry for the length of this mail....but I think it important to try and properly explain what is going on here (at least as I see/understand it). regards, Neil =20 > -----Original Message----- > From: BRUNGARD, DEBORAH A, SBCLABS [mailto:dbrungard@att.com]=20 > Sent: 26 January 2007 20:03 > To: Huub van Helvoort > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: [mpls] RE: [PWE3] Re: Y.1720 liased text >=20 >=20 > FYI- > This 1+1 packet protection scheme was not only in ITU's SG13=20 > work, it was also included in SG15's G.7712, done at the same=20 > time (2003). G.7712 doesn't reference Y.1720, probably as=20 > they were being done at the same time, though the scheme was=20 > of the same origin. >=20 > G.7712's Appendix IV does say that the implementation is=20 > "non-trivial", maybe there have been no attempts. >=20 > (ITU Recommendations (PDF) can be downloaded for free) >=20 > Deborah =20 >=20 > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 > Sent: Friday, January 26, 2007 2:03 PM > To: Adrian Farrel > Cc: mpls@ietf.org; ghani.abbas@ericsson.com; pwe3@ietf.org;=20 > Stewart Bryant > Subject: Re: [PWE3] Re: Y.1720 liased text >=20 > Hi Adrian, >=20 > You wrote: >=20 > > Hi Huub, > >=20 > >>> The implication of the text is that you can have a packet of the > >>> form: > >>> > >>> LSE (RFC3032) > >>> Sequence number > >>> LSE (RFC3032) > >>> Payload > >>> > >>> Is that correct? > >> > >> This is also what I read, and apparently Neil does as well. > >> > >>> If so what is the setting of the S bit (See RFC3032) in each case? > >> > >> Because the text does not mention any altering of the=20 > S-bit I assume=20 > >> they do not change. > >=20 > > Ah, so either setting of the S-bit is allowed? >=20 > [hvh] the text does also not mention a specific value of the S-bit, > so I suppose either value of the S-bit is allowed. > If I would try to implement this protection, the LSR > providing the protection would build the LSE according to > RFC3032 and then add the 4 octet sequence number. >=20 > >> I agree with Neil (see his 2002 post) that this requires a very=20 > >> carefull configuartion of the network. Checking that both ends=20 > >> support this feature and closely guard the connectivity for both=20 > >> diverse routes. > >=20 > > With the S-bit, careful config is needed. >=20 > [hvh] indeed I did mean careful >=20 > > Without the S-bit it seems like a router that popped a label would > > expect the next thing on the stack to also be a label, but would=20 > > actually find a magic sequence number. >=20 > [hvh] if the the config was careful the router that pops the=20 > label inserted by the router that is the source of the=20 > protection knows that the 4 octets following this popped=20 > label is the sequene number and treats it accordingly. >=20 > > Although you could config around > > this (since the pop action must be installed) this is a new MPLS=20 > > behavior. At the least it is a new LFIB action that is not=20 > previously=20 > > described in any MPLS documentation. >=20 > [hvh] ehh, it was described in=20 > http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls- > packet-pro > tection-00.txt > This draft was presented and discussed in the IETF53 meeting. > The meeting notes nor the discussion afterwards on the=20 > MPLS WG list > mention the fact that it contains a new LFIB action. >=20 > >> Note that this text is in an appendix, so it does not form an=20 > >> integral part of the recommendation, i.e. it is not mandatory. > >=20 > > Hmmm. > >=20 > > Shouldn't there be a specification of: > > - what must be supported > > - what can also be attempted >=20 > [hvh] maybe, but apparently when the text was drafted there were no > contributions providing/requesting these specifications, and > when the recommendation was approved (as usual in ITU-T by > consensus) nobody objected, in the meeting of the Q3/13, at > the closing plenary, nor during the AAP. >=20 > > I think Stewart's question is quite helpful here. Do we=20 > have any idea > of=20 > > what deployed implementations do? >=20 > [hvh] That would be a question to ask on the ITU-T Q9/15 exploder >=20 > > Cheers, > > Adrian >=20 > Cheers, Huub. >=20 > --=20 > = =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 > http://www.van-helvoort.eu/=20 > = =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 > Always remember that you are unique...just like everyone else... >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 29 06:42:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUsK-0006nY-8V; Mon, 29 Jan 2007 06:40:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAtn8-00063h-CI; Sat, 27 Jan 2007 15:04:50 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAtn1-0004FI-Qg; Sat, 27 Jan 2007 15:04:50 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE8842048E; Sat, 27 Jan 2007 21:04:26 +0100 (CET) X-AuditID: c1b4fb3e-afed3bb0000007e1-12-45bbb04ab68b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A92F22007E; Sat, 27 Jan 2007 21:04:26 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 21:04:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Re: Y.1720 liased text Date: Sat, 27 Jan 2007 21:04:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBWFhuHwMpAiD+QUKxB6F2Y06rUAA9RFuV References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> From: "Ghani Abbas \(BE/ETL\)" To: "Adrian Farrel" , "Huub van Helvoort" , "Stewart Bryant" X-OriginalArrivalTime: 27 Jan 2007 20:04:26.0338 (UTC) FILETIME=[58859420:01C7424E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Mon, 29 Jan 2007 06:40:37 -0500 Cc: neil.2.harrison@bt.com, pwe3@ietf.org, mpls@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Adrain and Stewart, =20 It seems to me the discussion about an issue in Y.1720 which has been in = the public domain for a long time. In order to resolve the issue I suggest that a contribution be submitted = to the next Q9/15 meeting ( either 12th., Feb or 10th.,April meetings). = Q9/15 can discuss the issue and may recommend a way forward. =20 Ghani =20 ________________________________ From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Fri 26/01/2007 15:39 To: Huub van Helvoort; Stewart Bryant Cc: neil.2.harrison@bt.com; Ghani Abbas (BE/ETL); pwe3@ietf.org; = mpls@ietf.org Subject: Re: [PWE3] Re: Y.1720 liased text Hi Huub, >> The implication of the text is that you can have a packet of the >> form: >> >> LSE (RFC3032) >> Sequence number >> LSE (RFC3032) >> Payload >> >> Is that correct? > > This is also what I read, and apparently Neil does as well. > >> If so what is the setting of the S bit (See RFC3032) in each >> case? > > Because the text does not mention any altering of the S-bit > I assume they do not change. Ah, so either setting of the S-bit is allowed? > I agree with Neil (see his 2002 post) that this requires a > very carefull configuartion of the network. Checking that > both ends support this feature and closely guard the connectivity > for both diverse routes. With the S-bit, careful config is needed. Without the S-bit it seems like a router that popped a label would = expect the next thing on the stack to also be a label, but would actually find = a magic sequence number. Although you could config around this (since the = pop action must be installed) this is a new MPLS behavior. At the least it = is a new LFIB action that is not previously described in any MPLS = documentation. > Note that this text is in an appendix, so it does not form > an integral part of the recommendation, i.e. it is not mandatory. Hmmm. Shouldn't there be a specification of: - what must be supported - what can also be attempted I think Stewart's question is quite helpful here. Do we have any idea of what deployed implementations do? Cheers, Adrian _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 29 07:19:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVSv-0004yD-O2; Mon, 29 Jan 2007 07:18:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVSv-0004y5-8i; Mon, 29 Jan 2007 07:18:29 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBVSt-0005KG-UJ; Mon, 29 Jan 2007 07:18:29 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2007 13:18:27 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0TCIRX8011530; Mon, 29 Jan 2007 13:18:27 +0100 Received: from [10.61.65.32] (ams3-vpn-dhcp288.cisco.com [10.61.65.32]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0TCIQC8008121; Mon, 29 Jan 2007 13:18:26 +0100 (MET) Message-ID: <45BDE60C.2090806@cisco.com> Date: Mon, 29 Jan 2007 12:18:20 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: multipart/mixed; boundary="------------090100010008070300050104" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1631; t=1170073107; x=1170937107; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20FW=3A=20[OSPF]=20New=20draft=3A=20Dynamic=20PW=20ro uting=20using=20OSPF=20extensions] |Sender:=20; bh=PZR/uXVULj6Nh1RVQ2PbOeb+Wo77jXXPilyXnn+9h+s=; b=B73aDHPktLKpuOUOS09MEokLrPJhwwu9NLSmW6YLMihK2cMlU6viZAoMdiTB1/HIkZZLwbH0 g9n4RZDFHP/eMpEKpGSP72rv4FDQIdpYcMYZptsnHSHCnyxRiDhv1Tti; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ospf@ietf.org, Andrew.Dolganow@alcatel-lucent.com Subject: [PWE3] [Fwd: FW: [OSPF] New draft: Dynamic PW routing using OSPF extensions] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --------------090100010008070300050104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sent to PWE3, but got lost Resending Stewart ------------------------------------------------------------------------ From: DOLGANOW Andrew [mailto:Andrew.Dolganow@alcatel-lucent.com] Sent: Thursday, January 18, 2007 11:40 AM To: pwe3@ietf.org; OSPF List Subject: [OSPF] New draft: Dynamic PW routing using OSPF extensions Hi, A new draft draft-dolganow-pwe3-ospf-ms-pw (http://www.ietf.org/internet-drafts/draft-dolganow-pwe3-ospf-ms-pw-ext-00.txt) has been submitted. The draft proposes a solution to dynamically route multi-segment pseudowires in a metro area (comprising of a single OSPF AS) using OSPF extensions. As discussed with the chairs of both OSPF and PWE3 groups, I would like to request that you: 1. Focus any comments/discussion regarding proposed OSPF mechanisms to the OSPF WG 2. Focus any comment/discussion regarding applicability/usability/scope of the OSPF-assisted solution proposed in the draft for dynamically placing multi-segment pseudowires to the PWE3 WG. Regards, Andrew --------------090100010008070300050104 Content-Type: text/plain; name="ATT665717.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ATT665717.txt" _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --------------090100010008070300050104 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --------------090100010008070300050104-- From pwe3-bounces@ietf.org Mon Jan 29 14:48:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcTd-000835-Fm; Mon, 29 Jan 2007 14:47:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcTb-00082q-4B; Mon, 29 Jan 2007 14:47:39 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBcTX-0003t7-Kb; Mon, 29 Jan 2007 14:47:39 -0500 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1170100052!19569747!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24145 invoked from network); 29 Jan 2007 19:47:32 -0000 Received: from unknown (HELO attrh8i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 29 Jan 2007 19:47:32 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0TJis32021259; Mon, 29 Jan 2007 14:44:56 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0TJikLq021187; Mon, 29 Jan 2007 14:44:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] RE: [PWE3] Re: Y.1720 liased text Date: Mon, 29 Jan 2007 13:47:25 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0D88BD07@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353891AF50933@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RE: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBfLlXJ3ysepdtRL2eiZpEQ95QZAABJLLwABcCmIAAf0IaoA== From: "BRUNGARD, DEBORAH A, SBCLABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mpls@ietf.org, pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Neil, Good analysis - we still don't have the perfect technology;-) Though as you say I am not sure what can be done of the last four options - especially the last - by IETF. It seems to be set in stone from the other emails on the list. At most, IETF can mention concern (as Stewart captured in his proposal). And encourage cross-SDO review and use of RFC4775 when considering applying/extending MPLS. Deborah _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jan 29 15:40:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdIU-0003ux-U4; Mon, 29 Jan 2007 15:40:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdIT-0003u1-4g for pwe3@ietf.org; Mon, 29 Jan 2007 15:40:13 -0500 Received: from fncnmp04.fnc.fujitsu.com ([168.127.0.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdIR-0004jj-AV for pwe3@ietf.org; Mon, 29 Jan 2007 15:40:13 -0500 Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp04.fnc.fujitsu.com with ESMTP; 29 Jan 2007 14:40:01 -0600 X-IronPort-AV: i="4.13,253,1167631200"; d="scan'208"; a="58850841:sNHT25944604" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] VCCV-12 last call Date: Mon, 29 Jan 2007 14:40:01 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] VCCV-12 last call Thread-Index: AcdBXAedZ6+zL1qpS+SnMFgXFH/hrwCdmK+g From: "O'Connor, Don" To: "Thomas D. Nadeau" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: pwe3@ietf.org, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org With respect to the topic raised by Neil, I think that for multi-segment = pseudowires, the same CV type should be used for each pseudowire segment = and the end to end pseudowire. The VCCV capability negotiation for = multi-segment pseudowires should insure this uniformity. I also believe that for multi-segment pseudowires, it should be possible = to use concurrent LSP Ping + BFD. BFD for a continuous continuity check = and LSP Ping for ping and path trace. For multi-domain MS-PW = applications, ideally it should be possible to have an EE BFD session = and additional BFD sessions for the portions of the MS-PW that traverse = each provider's domain. On the subject of MS-PW OAM, the minutes of the November PWE3 session = indicate - draft-ietf-pwe3-segmented-pw-04.txt - "Will be published = shortly". In there any word on when -04 will appear? I would still suggest that Multi-Segment VCCV should be in separate = draft and should address both single domain and multi-domain. For = multi-domain, security issues should be considered.=20 Regards Don -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, January 26, 2007 9:08 AM To: neil.2.harrison@bt.com Cc: pwe3@ietf.org; stbryant@cisco.com Subject: Re: [PWE3] VCCV-12 last call > Sorry Tom that I was not clear.....what I meant was what happens if =20 > you > use different OAM options on different LSPs/PWs and then one has > misconnectivity between them? I presume this has been considered? Yes, I think it has. I think the choice of which type of VCCV to use for each PW is up to the PW/configuration. I don't see how mandating that all PWs that ride on the same LSP use the same VCCV mode needs to be mandatory. If you want to configure this once deployed based on local policy, that is possible. However, there might be other reasons why people might want to deploy different modes on different PWs (say based on the AC type), which I think is reasonable to allow as well. > Note - If one is using a consistent OAM function on all LSPs/PWs then > one should (however see later) have predictable behaviour under > misconnectivity, ie the traffic unit fields relating to the OAM =20 > function > have a consistent semantic. However, this is a more general point for > all the fields in a traffic unit, and not just OAM (any network > mode/technology). For example, also see my post of yesterday on the > thread "RE: [PWE3] Y.1720 liased text".....I attach the text for =20 > ease of > reference below: Again, I think that the spec. does allow for making things consistent, if you so choose to configure your LSRs this way. I do know of other operators however, that wish to use different methods on different PWs based on the AC type. But in the end the spec. is flexible enough to accommodate both your and their requirements. --Tom > > =3D=3D=3D > > Well, there are certainly some issues when the semantic of a specific > field in a traffic unit is NOT consistent in any layer network. For > example, the MPLS label field can currently take on at least 3 =20 > different > semantics, viz: > - a proxy for destination identifier (ie the usual > label-swapping/forwarding paradigm) > - a proxy for a source identifier (ie a necessary consequence of > (lower level) LSP merging) > - a 'functional action', eg various labels in the reserved > code-space 0-15. > > This is not good practice IMO....and one observation here would be =20 > that > under misconnectivity incorrect downstream decisions could arise =20 > (noting > that this may not simply be between LSPs at the same level but also > across LSPs at different levels). Though to be strictly accurate, =20 > since > the 'functional action' labels (0-15) are partitioned from the rest of > the label space the consequence has some certainty of (incorrect) > action. > > I am not familiar with the content of Y.1720, but from what you =20 > describe > below it seems we can add yet another semantic to the label =20 > field.....or > at least *its interpretation as a label field*, under misconnectivity, > by some LSR that unexpectedly receives it (but also see Note below). > Does not sound very good to me. > > Note - If S=3D1 in the preceding MPLS header then there seems less of = a > problem than if S=3D0.....which may appear an odd observation to =20 > make, but > I do so because of this specific text Stewart extracted from Y.1720 > Appendix II (note the highlighted word 'any'): > > "Note that packet 1+1 can be provided at *any* level of the =20 > hierarchy of > a nested LSP." > > =3D=3D=3D > > regards, Neil > > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: 25 January 2007 21:11 >> To: Harrison,N,Neil,JCGA1 R >> Cc: don.oconnor@us.fujitsu.com; pwe3@ietf.org; stbryant@cisco.com >> Subject: Re: [PWE3] VCCV-12 last call >> >> >> >> I don't understand what you mean. Can you be >> more specific in your example? >> >> --Tom >> >> >>> what happens if you subsequently get misconnectivity between LSPs >>> using >>> different options? >>> >>> regards, Neil >>> >>>> -----Original Message----- >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>> Sent: 25 January 2007 19:15 >>>> To: O'Connor, Don >>>> Cc: pwe3; Stewart Bryant >>>> Subject: Re: [PWE3] VCCV-12 last call >>>> >>>> >>>> >>>> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: >>>> >>>>> My reading of VCCV - 12 is that >>>>> >>>>> 1) It only supports BFD Base and not MPLS BFD. It can be >> noted that >>>>> draft-ietf-bfd-mpls-03.txt. is not listed among the references >>>> >>>> BFD-base is only required because the bootstrapping >>>> rules required to setup BFD/VCCV are single-hop style. >>>> >>>>> 2) It is only possible to negotiate (by LDP) one CV >> protocol - ICMP >>>>> Ping, LSP Ping, or BFD (Base). So it is not possible to >> support MPLS >>>>> BFD which enables concurrent use of LSP Ping and BFD >>>> >>>> You do not negotiate anything per se; you advertise >> capabilities for >>>> VCCV. You may advertise none, one or all of the different CC/CV >>>> combinations, >>>> which means you are willing to accept any of those combinations >>>> (within the >>>> rules stipulated in the draft). The receiving side is then >>>> free to send any of those combinations (within the rules >>>> stipulated in the draft), >>>> but >>>> once one is successfully sent (and acked), no others are >>>> allowed, and no "re-negotiation" is allowed without bringing >>>> down the PW. The latter >>>> comes >>>> specifically from the rules stipulated in RFC 4447. >>>> >>>> --Tom >>>> >>>> >>>> >>>>> >>>>> Is my understanding accurate ? >>>>> >>>>> Regards >>>>> >>>>> Don >>>>> >>>>> -----Original Message----- >>>>> From: Stewart Bryant [mailto:stbryant@cisco.com] >>>>> Sent: Monday, January 22, 2007 7:35 AM >>>>> To: pwe3 >>>>> Subject: [PWE3] VCCV-12 last call >>>>> >>>>> >>>>> This is the start of last call for >>>>> >>>>> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >>>>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >>>>> >>>>> last call will end 6th February. >>>>> >>>>> There are a couple of issues that I have with regard to >> IANA policy >>>>> that is raised by this draft, but I will ask my questions >> in another >>>>> thread. >>>>> >>>>> Regards >>>>> >>>>> Stewart >>>>> >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >>>> _______________________________________________ >>>> pwe3 mailing list >>>> pwe3@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >> _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jan 30 14:00:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByB5-0001ST-5u; Tue, 30 Jan 2007 13:57:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByB3-0001S2-5C for pwe3@ietf.org; Tue, 30 Jan 2007 13:57:57 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HByAU-0003Gx-82 for pwe3@ietf.org; Tue, 30 Jan 2007 13:57:57 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Jan 2007 13:57:22 -0500 X-IronPort-AV: i="4.13,258,1167627600"; d="scan'208"; a="112768299:sNHT60384626" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0UIvLYX022413; Tue, 30 Jan 2007 13:57:21 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0UIvLVT007344; Tue, 30 Jan 2007 13:57:21 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 13:57:21 -0500 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 13:57:20 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <326BD5F5-F8D2-48F3-9E6A-0C4027129983@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] VCCV-12 last call Date: Tue, 30 Jan 2007 13:57:18 -0500 To: "O'Connor, Don" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jan 2007 18:57:20.0426 (UTC) FILETIME=[782168A0:01C744A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9166; t=1170183441; x=1171047441; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20VCCV-12=20last=20call |Sender:=20 |To:=20=22O'Connor,=20Don=22=20; bh=8C8FX55QgS5KVOiMj0tom5ve79G7oR6xH0aqCwodmj8=; b=fVRPJ8ZNIKj8Osuc5QOH8tcH6u4BD2cqLevRQRCeo8JvgObOM5rNRin8B2eKO10tbZq8VSal +zHtOqi7du3PMX0ZuOdCSuIrKUPUOZJW5KFZeX+Fppe3RdQ6LBwkXc2o; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: neil.2.harrison@bt.com, pwe3@ietf.org, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > With respect to the topic raised by Neil, I think that for multi- > segment pseudowires, the same CV type should be used for each > pseudowire segment and the end to end pseudowire. The VCCV > capability negotiation for multi-segment pseudowires should insure > this uniformity. In practice, I see this as quite difficult to enforce given how MH PWs work. Remember that the LSP used to get traffic across of one AS can change, as long as the end points are the same. This means that the PE would have to monitor the LSPs used, and make sure that no LSPs are picked with PWs that have mixed CC/CV types. If an operator like Neil would like consistency, I suggest doing this through configuration, of which there are a number of options. For example, you can set up TE tunnels between the PEs, and explicitly tell one subset of PWs to use one tunnel, and another the other tunnel. Each tunnel could represent a different CC/CV configuration. > I also believe that for multi-segment pseudowires, it should be > possible to use concurrent LSP Ping + BFD. BFD for a continuous > continuity check and LSP Ping for ping and path trace. For multi- > domain MS-PW applications, ideally it should be possible to have an > EE BFD session and additional BFD sessions for the portions of the > MS-PW that traverse each provider's domain. > > On the subject of MS-PW OAM, the minutes of the November PWE3 > session indicate - draft-ietf-pwe3-segmented-pw-04.txt - "Will be > published shortly". In there any word on when -04 will appear? Still editing. > I would still suggest that Multi-Segment VCCV should be in separate > draft and should address both single domain and multi-domain. I leave this up to the chairs/WG. > For multi-domain, security issues should be considered. Good point. --Tom > > Regards > > Don > > > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, January 26, 2007 9:08 AM > To: neil.2.harrison@bt.com > Cc: pwe3@ietf.org; stbryant@cisco.com > Subject: Re: [PWE3] VCCV-12 last call > > > >> Sorry Tom that I was not clear.....what I meant was what happens if >> you >> use different OAM options on different LSPs/PWs and then one has >> misconnectivity between them? I presume this has been considered? > > Yes, I think it has. I think the choice of which type of > VCCV to use for each PW is up to the PW/configuration. I don't > see how mandating that all PWs that ride on the same LSP use > the same VCCV mode needs to be mandatory. If you want to configure > this once deployed based on local policy, that is possible. > However, there might be other reasons why people might want > to deploy different modes on different PWs (say based on the > AC type), which I think is reasonable to allow as well. > >> Note - If one is using a consistent OAM function on all LSPs/PWs then >> one should (however see later) have predictable behaviour under >> misconnectivity, ie the traffic unit fields relating to the OAM >> function >> have a consistent semantic. However, this is a more general point >> for >> all the fields in a traffic unit, and not just OAM (any network >> mode/technology). For example, also see my post of yesterday on the >> thread "RE: [PWE3] Y.1720 liased text".....I attach the text for >> ease of >> reference below: > > Again, I think that the spec. does allow for making > things consistent, if you so choose to configure your LSRs > this way. I do know of other operators however, that wish > to use different methods on different PWs based on the AC > type. But in the end the spec. is flexible enough to > accommodate both your and their requirements. > > --Tom > > >> >> === >> >> Well, there are certainly some issues when the semantic of a specific >> field in a traffic unit is NOT consistent in any layer network. For >> example, the MPLS label field can currently take on at least 3 >> different >> semantics, viz: >> - a proxy for destination identifier (ie the usual >> label-swapping/forwarding paradigm) >> - a proxy for a source identifier (ie a necessary consequence of >> (lower level) LSP merging) >> - a 'functional action', eg various labels in the reserved >> code-space 0-15. >> >> This is not good practice IMO....and one observation here would be >> that >> under misconnectivity incorrect downstream decisions could arise >> (noting >> that this may not simply be between LSPs at the same level but also >> across LSPs at different levels). Though to be strictly accurate, >> since >> the 'functional action' labels (0-15) are partitioned from the >> rest of >> the label space the consequence has some certainty of (incorrect) >> action. >> >> I am not familiar with the content of Y.1720, but from what you >> describe >> below it seems we can add yet another semantic to the label >> field.....or >> at least *its interpretation as a label field*, under >> misconnectivity, >> by some LSR that unexpectedly receives it (but also see Note below). >> Does not sound very good to me. >> >> Note - If S=1 in the preceding MPLS header then there seems less of a >> problem than if S=0.....which may appear an odd observation to >> make, but >> I do so because of this specific text Stewart extracted from Y.1720 >> Appendix II (note the highlighted word 'any'): >> >> "Note that packet 1+1 can be provided at *any* level of the >> hierarchy of >> a nested LSP." >> >> === >> >> regards, Neil >> >> >>> -----Original Message----- >>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>> Sent: 25 January 2007 21:11 >>> To: Harrison,N,Neil,JCGA1 R >>> Cc: don.oconnor@us.fujitsu.com; pwe3@ietf.org; stbryant@cisco.com >>> Subject: Re: [PWE3] VCCV-12 last call >>> >>> >>> >>> I don't understand what you mean. Can you be >>> more specific in your example? >>> >>> --Tom >>> >>> >>>> what happens if you subsequently get misconnectivity between LSPs >>>> using >>>> different options? >>>> >>>> regards, Neil >>>> >>>>> -----Original Message----- >>>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>>> Sent: 25 January 2007 19:15 >>>>> To: O'Connor, Don >>>>> Cc: pwe3; Stewart Bryant >>>>> Subject: Re: [PWE3] VCCV-12 last call >>>>> >>>>> >>>>> >>>>> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote: >>>>> >>>>>> My reading of VCCV - 12 is that >>>>>> >>>>>> 1) It only supports BFD Base and not MPLS BFD. It can be >>> noted that >>>>>> draft-ietf-bfd-mpls-03.txt. is not listed among the references >>>>> >>>>> BFD-base is only required because the bootstrapping >>>>> rules required to setup BFD/VCCV are single-hop style. >>>>> >>>>>> 2) It is only possible to negotiate (by LDP) one CV >>> protocol - ICMP >>>>>> Ping, LSP Ping, or BFD (Base). So it is not possible to >>> support MPLS >>>>>> BFD which enables concurrent use of LSP Ping and BFD >>>>> >>>>> You do not negotiate anything per se; you advertise >>> capabilities for >>>>> VCCV. You may advertise none, one or all of the different CC/CV >>>>> combinations, >>>>> which means you are willing to accept any of those combinations >>>>> (within the >>>>> rules stipulated in the draft). The receiving side is then >>>>> free to send any of those combinations (within the rules >>>>> stipulated in the draft), >>>>> but >>>>> once one is successfully sent (and acked), no others are >>>>> allowed, and no "re-negotiation" is allowed without bringing >>>>> down the PW. The latter >>>>> comes >>>>> specifically from the rules stipulated in RFC 4447. >>>>> >>>>> --Tom >>>>> >>>>> >>>>> >>>>>> >>>>>> Is my understanding accurate ? >>>>>> >>>>>> Regards >>>>>> >>>>>> Don >>>>>> >>>>>> -----Original Message----- >>>>>> From: Stewart Bryant [mailto:stbryant@cisco.com] >>>>>> Sent: Monday, January 22, 2007 7:35 AM >>>>>> To: pwe3 >>>>>> Subject: [PWE3] VCCV-12 last call >>>>>> >>>>>> >>>>>> This is the start of last call for >>>>>> >>>>>> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt >>>>>> >>>>>> last call will end 6th February. >>>>>> >>>>>> There are a couple of issues that I have with regard to >>> IANA policy >>>>>> that is raised by this draft, but I will ask my questions >>> in another >>>>>> thread. >>>>>> >>>>>> Regards >>>>>> >>>>>> Stewart >>>>>> >>>>>> _______________________________________________ >>>>>> pwe3 mailing list >>>>>> pwe3@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>>>> >>>>>> _______________________________________________ >>>>>> pwe3 mailing list >>>>>> pwe3@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Jan 31 12:17:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ3x-0006AL-KR; Wed, 31 Jan 2007 12:16:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ3u-00069T-FX; Wed, 31 Jan 2007 12:15:58 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCJ3u-0006N9-7a; Wed, 31 Jan 2007 12:15:58 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BF6A3175E5; Wed, 31 Jan 2007 17:15:25 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCJ3N-00016H-CD; Wed, 31 Jan 2007 12:15:25 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 31 Jan 2007 12:15:25 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: draft-ietf-pwe3-wildcard-pw-type (Wildcard Pseudowire Type) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Wildcard Pseudowire Type ' 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 2007-02-14. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-wildcard-pw-type-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14171&rfc_flag=0 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3