Draft-delord-pwe3-oam-applications-01.txt

Stewart,<= /DIV>

Thanks for the comments. W= e're past=20 the submission window, so I'll get another revision ready in time for when = it=20 reopens. Do you want to see it first before I resubmit it?

Cheers,

Andy

From: Stewart Bryant=20 [mailto:stbryant@cisco.com]
Sent: Fri 7/22/2005 11:23
To:=20 Malis, Andrew G.
Cc: pwe3
Subject: comments on=20 draft-ietf-pwe3-fcs-retention-03.txt

Andy

I was doing a final check on

Document:=20 draft-ietf-pwe3-fcs-retention-03.txt
PWE3 Frame Check Sequence=20 Retention

- Stewart

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The draft does not pass=20 the nits checker

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Sinc= e the draft covers frame relay=20 and the FR draft
says that the PW MAY change the FECN and/or BECN
bit= s, it=20 is probably worth noting that the FCS
will have to change. It may also b= e=20 worth noting
that to preserve data integrity this means
checking the = FCS=20 at the egress PE (perhaps with
an overlapping check=20 method).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As defined f= or MPLS, not only can a=20 PW-aware device
internally corrupt an encapsulated payload, but ANY MPLS= LSR=20 in the
path can corrupt the encapsulated payload.

SB> This app= lies=20 to both IP and MPLS PSNs.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
4. Signaling FCS=20 Retention With MPLS-based Pseudowires

     When = using=20 the signaling procedures in [4], there is a=20 Pseudowire
     Interface Parameter Identifier value= used=20 to signal the desire to
     retain the FCS when=20 advertising a VC label [5]:

SB> It is now called a
SB>=20 Pseudowire Interface Parameter Sub-TLV type

8. IANA=20 Considerations

     This document does not speci= fy=20 any new registries for IANA to
    =20 maintain.

     This document requires IANA to=20 allocate a PWE3 Virtual Circuit FEC
     element=20 parameter ID [5].

It might be better to say that [5] - which is a=20 blocking
ref does this - so no additional IANA action=20 needed.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&= nbsp;   This=20 specification also requires one value within the L2TP=20 "Control
     Message Attribute Value Pairs" section= to=20 be assigned by IANA as
     per [8]. The new AVP is=20 encoded as L2TP-TBA-1 in this document, and
     sho= uld=20 be referred to in the IANA L2TP parameters registry as=20 "FCS
     Retention."

... but make it clear t= hat=20 IANA does have an action here.
Does this allocation need review and sign= off=20 by the L2TPext WG?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C58ED2.6CF6A6FF-- --===============1430537215== 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 --===============1430537215==-- From pwe3-bounces@ietf.org Fri Jul 22 14:21:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw29R-0007gS-FM; Fri, 22 Jul 2005 14:21:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw29P-0007gN-JL for pwe3@megatron.ietf.org; Fri, 22 Jul 2005 14:21:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07690 for ; Fri, 22 Jul 2005 14:21:33 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw2dg-0008TN-KJ for pwe3@ietf.org; Fri, 22 Jul 2005 14:52:53 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2005 11:21:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,135,1120460400"; d="scan'208"; a="3002478:sNHT20572180" Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6MILOVu016484; Fri, 22 Jul 2005 14:21:24 -0400 (EDT) Message-Id: <200507221821.j6MILOVu016484@rtp-core-2.cisco.com> To: Alex Zinin Subject: Re: [PWE3] PWE3 IANA policy In-reply-to: Your message of Thu, 21 Jul 2005 13:34:21 -0700. <979766055.20050721133421@psg.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Jul 2005 14:21:24 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org I disagree with one aspect of your statement: "I consider other things like long delays, biased reviewer etc. a bug that can be dealt with and wouldn't optimize for it." Experience in a wide variety of settings (including, but not limited to, the IETF), shows that no matter how well-intended a process is, the process can be deflected from its intended goal by politics and bureaucracy. This isn't a "bug" that creeps in unexpectedly, it is an inherent characteristic of process, and it is something that is to be expected. That's why process A is usually associated with a second process B whose purpose is to allow the reversal of process A. ("Don't worry if the reviewer turns you down because he works for one of your competitors, you can appeal to the IESG. Don't worry if the IESG turns you down because they are resistant to unorthodox ideas, you can appeal to the IAB. Just fill out these forms in triplicate and wait six years.") So if you are considering a process which provides "sanity by expert review", you can't defend it just by saying "review is good", you also have to take into account the likelihood that the process will be delayed and/or deflected by bureaucratic and/or political considerations. Of course, the folks in charge of running the process never take this seriously, and always insist that everything is working fine, or at least will be working fine starting tomorrow, after the last bug is removed. On the purported disadvantages of "freedom": - SPs don't benefit from sanity checking This is a little overstated, it would be more accurate to say "SPs are not forced to await the results of the IETF processes". Of course, if you put it that way, it doesn't sound so bad ;-) - Potential proliferation of proprietary solutions, Actual marketplace competition before a single standard is chosen? Heavens. Note also that "sanity checking" does not prevent proliferation of standard solutions, as we certainly know in the MPLS-related areas. - other SDOs can work on their versions of PWs. And why shouldn't they? > Regarding the specific proposal of FCFS + I-D. I think it does not solve > any problem On the contrary, it solved the problem of finding something to which the WG could agree ;-) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jul 22 14:42:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2TH-0007M1-59; Fri, 22 Jul 2005 14:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2TE-0007Lw-RS for pwe3@megatron.ietf.org; Fri, 22 Jul 2005 14:42:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09194 for ; Fri, 22 Jul 2005 14:42:02 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw2xW-0000nM-Ip for pwe3@ietf.org; Fri, 22 Jul 2005 15:13:23 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j6MIfrYH014112; Fri, 22 Jul 2005 14:41:53 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14201; Fri, 22 Jul 2005 14:41:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Jul 2005 14:41:52 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885D3A@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'erosen@cisco.com'" , Alex Zinin Subject: RE: [PWE3] PWE3 IANA policy Date: Fri, 22 Jul 2005 14:41:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Folks, Based on Alex's "fresh eye" (and in particular, the reference to TCP/UDP port numbers), Eric Rosen's comments and all the earlier discussions I have seen or been a part of, I wonder if it might not be acceptable as a compromise to allocate a significantly smaller chunk to "Expert Review" (including a-piori assignments), possibly a similar size chunk as "Reserved" and the remainder as FCFS? One thing that is certain - both from past discussion and from this debate - is that a much smaller assignment space is needed for allocation based on any form of dialogue more complex than "Please" and "Thankyou". Allocating this much smaller space may make some people more comfortable with setting aside a similar size space that might be used either way later on - as long as the combination of "Expert Review" and "Reserved" is (possibly significantly) smaller than the currently suggested half of the proposed available space. -- Eric Gray --> -----Original Message----- --> From: pwe3-bounces@ietf.org --> [mailto:pwe3-bounces@ietf.org]On Behalf Of --> Eric Rosen --> Sent: Friday, July 22, 2005 2:21 PM --> To: Alex Zinin --> Cc: pwe3@ietf.org --> Subject: Re: [PWE3] PWE3 IANA policy --> --> --> --> I disagree with one aspect of your statement: --> --> "I consider other things like long delays, biased --> reviewer etc. --> a bug that can be dealt with and wouldn't optimize --> for it." --> --> Experience in a wide variety of settings (including, but --> not limited to, the --> IETF), shows that no matter how well-intended a process --> is, the process can --> be deflected from its intended goal by politics and --> bureaucracy. This isn't --> a "bug" that creeps in unexpectedly, it is an inherent --> characteristic of --> process, and it is something that is to be expected. --> --> That's why process A is usually associated with a second --> process B whose --> purpose is to allow the reversal of process A. --> ("Don't worry if the --> reviewer turns you down because he works for one of your --> competitors, you --> can appeal to the IESG. Don't worry if the IESG turns you --> down because they --> are resistant to unorthodox ideas, you can appeal to the --> IAB. Just fill --> out these forms in triplicate and wait six years.") --> --> So if you are considering a process which provides --> "sanity by expert --> review", you can't defend it just by saying "review is --> good", you also have --> to take into account the likelihood that the process will --> be delayed and/or --> deflected by bureaucratic and/or political considerations. --> Of course, the --> folks in charge of running the process never take this --> seriously, and always --> insist that everything is working fine, or at least will --> be working fine --> starting tomorrow, after the last bug is removed. --> --> On the purported disadvantages of "freedom": --> --> - SPs don't benefit from sanity checking --> --> This is a little overstated, it would be more accurate to --> say "SPs are not --> forced to await the results of the IETF processes". Of --> course, if you put --> it that way, it doesn't sound so bad ;-) --> --> - Potential proliferation of proprietary solutions, --> --> Actual marketplace competition before a single --> standard is chosen? --> Heavens. --> --> Note also that "sanity checking" does not prevent --> proliferation of --> standard solutions, as we certainly know in the --> MPLS-related areas. --> --> - other SDOs can work on their versions of PWs. --> --> And why shouldn't they? --> --> > Regarding the specific proposal of FCFS + I-D. I think it --> does not solve --> > any problem --> --> On the contrary, it solved the problem of finding --> something to which the WG --> could agree ;-) --> --> --> --> _______________________________________________ --> 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 Jul 22 17:43:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5IY-0001UW-G6; Fri, 22 Jul 2005 17:43:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5IW-0001U2-KV for pwe3@megatron.ietf.org; Fri, 22 Jul 2005 17:43:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00410 for ; Fri, 22 Jul 2005 17:43:09 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5mp-0001Zl-HE for pwe3@ietf.org; Fri, 22 Jul 2005 18:14:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2005 23:43:01 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6MLgrDg003487; Fri, 22 Jul 2005 23:42:54 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4725.cisco.com [10.61.82.116]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA20258; Fri, 22 Jul 2005 22:42:52 +0100 (BST) Message-ID: <42E1685B.4060505@cisco.com> Date: Fri, 22 Jul 2005 22:42:51 +0100 From: Stewart Bryant 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: "Gray, Eric" Subject: Re: [PWE3] PWE3 IANA policy References: <313680C9A886D511A06000204840E1CF0C885D3A@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885D3A@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , "'erosen@cisco.com'" , 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Gray, Eric wrote: > Folks, > > Based on Alex's "fresh eye" (and in particular, the reference to > TCP/UDP port numbers), Eric Rosen's comments and all the earlier > discussions I have seen or been a part of, I wonder if it might > not be acceptable as a compromise to allocate a significantly > smaller chunk to "Expert Review" (including a-piori assignments), > possibly a similar size chunk as "Reserved" and the remainder as > FCFS? Well UDP/TCP works with The Well Known Ports are those from 0 through 1023. The Registered Ports are those from 1024 through 49151 The Dynamic and/or Private Ports are those from 49152 through 65535 Would something similar work for us? i.e. expert review from 0 to 1023, vendor specific from 1024 to 4915, do as you please from 49152 to 65535 - Stewart > > One thing that is certain - both from past discussion and from > this debate - is that a much smaller assignment space is needed > for allocation based on any form of dialogue more complex than > "Please" and "Thankyou". Allocating this much smaller space may > make some people more comfortable with setting aside a similar > size space that might be used either way later on - as long as > the combination of "Expert Review" and "Reserved" is (possibly > significantly) smaller than the currently suggested half of the > proposed available space. > > -- > Eric Gray > > --> -----Original Message----- > --> From: pwe3-bounces@ietf.org > --> [mailto:pwe3-bounces@ietf.org]On Behalf Of > --> Eric Rosen > --> Sent: Friday, July 22, 2005 2:21 PM > --> To: Alex Zinin > --> Cc: pwe3@ietf.org > --> Subject: Re: [PWE3] PWE3 IANA policy > --> > --> > --> > --> I disagree with one aspect of your statement: > --> > --> "I consider other things like long delays, biased > --> reviewer etc. > --> a bug that can be dealt with and wouldn't optimize > --> for it." > --> > --> Experience in a wide variety of settings (including, but > --> not limited to, the > --> IETF), shows that no matter how well-intended a process > --> is, the process can > --> be deflected from its intended goal by politics and > --> bureaucracy. This isn't > --> a "bug" that creeps in unexpectedly, it is an inherent > --> characteristic of > --> process, and it is something that is to be expected. > --> > --> That's why process A is usually associated with a second > --> process B whose > --> purpose is to allow the reversal of process A. > --> ("Don't worry if the > --> reviewer turns you down because he works for one of your > --> competitors, you > --> can appeal to the IESG. Don't worry if the IESG turns you > --> down because they > --> are resistant to unorthodox ideas, you can appeal to the > --> IAB. Just fill > --> out these forms in triplicate and wait six years.") > --> > --> So if you are considering a process which provides > --> "sanity by expert > --> review", you can't defend it just by saying "review is > --> good", you also have > --> to take into account the likelihood that the process will > --> be delayed and/or > --> deflected by bureaucratic and/or political considerations. > --> Of course, the > --> folks in charge of running the process never take this > --> seriously, and always > --> insist that everything is working fine, or at least will > --> be working fine > --> starting tomorrow, after the last bug is removed. > --> > --> On the purported disadvantages of "freedom": > --> > --> - SPs don't benefit from sanity checking > --> > --> This is a little overstated, it would be more accurate to > --> say "SPs are not > --> forced to await the results of the IETF processes". Of > --> course, if you put > --> it that way, it doesn't sound so bad ;-) > --> > --> - Potential proliferation of proprietary solutions, > --> > --> Actual marketplace competition before a single > --> standard is chosen? > --> Heavens. > --> > --> Note also that "sanity checking" does not prevent > --> proliferation of > --> standard solutions, as we certainly know in the > --> MPLS-related areas. > --> > --> - other SDOs can work on their versions of PWs. > --> > --> And why shouldn't they? > --> > --> > Regarding the specific proposal of FCFS + I-D. I think it > --> does not solve > --> > any problem > --> > --> On the contrary, it solved the problem of finding > --> something to which the WG > --> could agree ;-) > --> > --> > --> > --> _______________________________________________ > --> 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 Jul 22 19:09:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6eD-0003JY-Ff; Fri, 22 Jul 2005 19:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6eB-0003JQ-Lm for pwe3@megatron.ietf.org; Fri, 22 Jul 2005 19:09:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09963 for ; Fri, 22 Jul 2005 19:09:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw78U-0005Lh-T5 for pwe3@ietf.org; Fri, 22 Jul 2005 19:41:00 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j6MN9MYH019592; Fri, 22 Jul 2005 19:09:23 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10849; Fri, 22 Jul 2005 19:09:12 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Jul 2005 19:09:11 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885D41@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Stewart Bryant'" Subject: RE: [PWE3] PWE3 IANA policy Date: Fri, 22 Jul 2005 19:09:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Alex Zinin , "'erosen@cisco.com'" , 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Stewart, One question for clarification: does the second range end at 4915 and the third start at 4915, is it 49152 for both or is it intended that there should be a gap from 4916 to 49151? I think the sense is that most people would like to have as large an unconstrained range as possible. Also, what is the policy for Vendor Specific - i.e. - how does it differ from Expert Review and FCFS? I was thinking more along the lines of: 0-1024 expert review 1025-4096 Reserved 4097- FCFS -- Eric --> -----Original Message----- --> From: Stewart Bryant [mailto:stbryant@cisco.com] --> Sent: Friday, July 22, 2005 5:43 PM --> To: Gray, Eric --> Cc: 'erosen@cisco.com'; Alex Zinin; pwe3@ietf.org --> Subject: Re: [PWE3] PWE3 IANA policy --> --> --> --> --> Gray, Eric wrote: --> --> > Folks, --> > --> > Based on Alex's "fresh eye" (and in particular, the reference to --> > TCP/UDP port numbers), Eric Rosen's comments and all the earlier --> > discussions I have seen or been a part of, I wonder if it might --> > not be acceptable as a compromise to allocate a significantly --> > smaller chunk to "Expert Review" (including a-piori assignments), --> > possibly a similar size chunk as "Reserved" and the remainder as --> > FCFS? --> --> Well UDP/TCP works with --> --> The Well Known Ports are those from 0 through 1023. --> The Registered Ports are those from 1024 through 49151 --> The Dynamic and/or Private Ports are those from 49152 through 65535 --> --> Would something similar work for us? --> --> i.e. expert review from 0 to 1023, vendor specific from --> 1024 to 4915, do as you please from 49152 to 65535 --> --> - Stewart --> --> > --> > One thing that is certain - both from past discussion and from --> > this debate - is that a much smaller assignment space is needed --> > for allocation based on any form of dialogue more complex than --> > "Please" and "Thankyou". Allocating this much smaller space may --> > make some people more comfortable with setting aside a similar --> > size space that might be used either way later on - as long as --> > the combination of "Expert Review" and "Reserved" is (possibly --> > significantly) smaller than the currently suggested half of the --> > proposed available space. --> > --> > -- --> > Eric Gray --> > --> > --> -----Original Message----- --> > --> From: pwe3-bounces@ietf.org --> > --> [mailto:pwe3-bounces@ietf.org]On Behalf Of --> > --> Eric Rosen --> > --> Sent: Friday, July 22, 2005 2:21 PM --> > --> To: Alex Zinin --> > --> Cc: pwe3@ietf.org --> > --> Subject: Re: [PWE3] PWE3 IANA policy --> > --> --> > --> --> > --> --> > --> I disagree with one aspect of your statement: --> > --> --> > --> "I consider other things like long delays, biased --> > --> reviewer etc. --> > --> a bug that can be dealt with and wouldn't optimize --> > --> for it." --> > --> --> > --> Experience in a wide variety of settings (including, but --> > --> not limited to, the --> > --> IETF), shows that no matter how well-intended a process --> > --> is, the process can --> > --> be deflected from its intended goal by politics and --> > --> bureaucracy. This isn't --> > --> a "bug" that creeps in unexpectedly, it is an inherent --> > --> characteristic of --> > --> process, and it is something that is to be expected. --> > --> --> > --> That's why process A is usually associated with a second --> > --> process B whose --> > --> purpose is to allow the reversal of process A. --> > --> ("Don't worry if the --> > --> reviewer turns you down because he works for one of your --> > --> competitors, you --> > --> can appeal to the IESG. Don't worry if the IESG turns you --> > --> down because they --> > --> are resistant to unorthodox ideas, you can appeal to the --> > --> IAB. Just fill --> > --> out these forms in triplicate and wait six years.") --> > --> --> > --> So if you are considering a process which provides --> > --> "sanity by expert --> > --> review", you can't defend it just by saying "review is --> > --> good", you also have --> > --> to take into account the likelihood that the process will --> > --> be delayed and/or --> > --> deflected by bureaucratic and/or political considerations. --> > --> Of course, the --> > --> folks in charge of running the process never take this --> > --> seriously, and always --> > --> insist that everything is working fine, or at least will --> > --> be working fine --> > --> starting tomorrow, after the last bug is removed. --> > --> --> > --> On the purported disadvantages of "freedom": --> > --> --> > --> - SPs don't benefit from sanity checking --> > --> --> > --> This is a little overstated, it would be more accurate to --> > --> say "SPs are not --> > --> forced to await the results of the IETF processes". Of --> > --> course, if you put --> > --> it that way, it doesn't sound so bad ;-) --> > --> --> > --> - Potential proliferation of proprietary solutions, --> > --> --> > --> Actual marketplace competition before a single --> > --> standard is chosen? --> > --> Heavens. --> > --> --> > --> Note also that "sanity checking" does not prevent --> > --> proliferation of --> > --> standard solutions, as we certainly know in the --> > --> MPLS-related areas. --> > --> --> > --> - other SDOs can work on their versions of PWs. --> > --> --> > --> And why shouldn't they? --> > --> --> > --> > Regarding the specific proposal of FCFS + I-D. I think it --> > --> does not solve --> > --> > any problem --> > --> --> > --> On the contrary, it solved the problem of finding --> > --> something to which the WG --> > --> could agree ;-) --> > --> --> > --> --> > --> --> > --> _______________________________________________ --> > --> 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 Jul 22 22:20:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw9ch-0006yZ-13; Fri, 22 Jul 2005 22:20:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw9ce-0006y1-MI for pwe3@megatron.ietf.org; Fri, 22 Jul 2005 22:20:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00725 for ; Fri, 22 Jul 2005 22:20:14 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwA6z-0002bi-KG for pwe3@ietf.org; Fri, 22 Jul 2005 22:51:39 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2005 19:20:02 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,136,1120460400"; d="scan'208"; a="3052514:sNHT18096148" Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6N2K0Vu025494; Fri, 22 Jul 2005 22:20:00 -0400 (EDT) Message-Id: <200507230220.j6N2K0Vu025494@rtp-core-2.cisco.com> To: Stewart Bryant Subject: Re: [PWE3] PWE3 IANA policy In-reply-to: Your message of Fri, 22 Jul 2005 22:42:51 +0100. <42E1685B.4060505@cisco.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Jul 2005 22:20:00 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Alex Zinin , pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org There's not much point in having a "do what you want" range that has more than a handful of values, if "do what you want" is taken to mean "not assigned by IANA". "Vendor specific" is also usually taken to mean "not assigned by IANA". What we want is to have most of the space be assignable by IANA, using the FCFS policy. This is captured well in Eric Gray's proposal. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 03:36:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwb1s-0006Rg-NB; Sun, 24 Jul 2005 03:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwb1q-0006RY-RQ for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 03:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10998 for ; Sun, 24 Jul 2005 03:36:05 -0400 (EDT) Received: from corfw.corrigent.com ([213.31.203.2] helo=tlvmail1.corrigent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwbWR-0006KH-NE for pwe3@ietf.org; Sun, 24 Jul 2005 04:07:44 -0400 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Draft Charter Date: Sun, 24 Jul 2005 10:35:55 +0200 Message-ID: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> Thread-Topic: [PWE3] Draft Charter Thread-Index: AcWMc8D8OPfbj7eMQHGvw8rFaij5tAA0da4wALfa2fA= From: "Moran Roth" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Danny, The first objective of the WG states: "Specify the following PW types and consider specification of additional PW types contingent on WG consensus and AD approval: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET." We would like to add Fibre Channel to the list of PW types, as we have identified a requirement from network operators to carry Fibre Channel over PW. This will allow the transparent transport of Fibre Channel services over the PSN, along with the data and TDM services already specified in the list. This will facilitate the extension of storage area networks to support mission critical applications such as disaster recovery and business continuity. Thanks, Moran -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of Danny McPherson Sent: Tuesday, July 19, 2005 4:05 PM To: pwe3 Subject: [PWE3] Draft Charter Folks, Please give the following charter a review and let Stewart and I (and/or the entire mailing list) know if you have any comments. The window for comments will close July 29, 2005. http://pwe3.tcb.net/pwe3-charter-2005071901.txt Thanks! -danny --------- Pseudo Wire Emulation Edge to Edge (PWE3) WG Description of Working Group: Network operators and their subscribers are seeking to rationalize their networks by migrating to a single IP or MPLS based packet switched network (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF specified PSNs. A pseudowire emulates a point-to-point link, and provides a service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions will include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the two endpoints of the PW. PWE3 will investigate mechanisms necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and RTP will be used where appropriate. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts. WG Objectives (in order of priority): Specify the following PW types and consider specification of additional PW types contingent on WG consensus and AD approval: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET. PWE3 will evaluate the use of PW mechanisms for an "MPLS Pseudowire" to transparently carry an MPLS label stack and payload between two PE routers. Specify a PW type that supports transparent carriage of IP payloads between disparate access services (e.g., ATM and Ethernet). Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. Specify OAM mechanisms for all PW types, suitable for operation over both IP and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Enhance packet-based PW specifications as necessary to allow the emulated service to be carried transparently over the PSN, for example by the retention of the FCS across the PW. Define mechanisms to permit the operation of a PW over a PSN that employs equal cost multiple path (ECMP) packet switching mechanism. A PW operating over a shared PSN does not have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. Whilst a service provider may traffic engineer their network is such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define the reqiurements for and mechanisms needed to allow the operation of switched virtual circuits over a PSN. _______________________________________________ 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 Sun Jul 24 10:09:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwhAM-0001ys-IJ; Sun, 24 Jul 2005 10:09:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwhAK-0001v1-Pr for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 10:09:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29554 for ; Sun, 24 Jul 2005 10:09:14 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwhey-0003gD-Ut for pwe3@ietf.org; Sun, 24 Jul 2005 10:40:58 -0400 Received: from default.mail.com (c-24-61-134-169.hsd1.ma.comcast.net[24.61.134.169]) by comcast.net (sccrmhc13) with SMTP id <20050724140904013008q2mie>; Sun, 24 Jul 2005 14:09:04 +0000 Message-Id: <6.2.1.2.2.20050724100808.0418cb50@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Jul 2005 10:09:00 -0400 To: Stewart Bryant From: "Andrew G. Malis" Subject: Re: [PWE3] comments on draft-ietf-pwe3-fcs-retention-03.txt In-Reply-To: <42E10F5E.3000407@cisco.com> References: <42E10F5E.3000407@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.6 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Stewart, Thanks for the comments. We're past the submission window, so I'll get another revision ready in time for when it reopens. Cheers, Andy ------- At 7/22/2005 16:23 +0100, Stewart Bryant wrote: >Andy > >I was doing a final check on > >Document: draft-ietf-pwe3-fcs-retention-03.txt >PWE3 Frame Check Sequence Retention > >- Stewart > >============= > >The draft does not pass the nits checker > >============= > >Since the draft covers frame relay and the FR draft >says that the PW MAY change the FECN and/or BECN >bits, it is probably worth noting that the FCS >will have to change. It may also be worth noting >that to preserve data integrity this means >checking the FCS at the egress PE (perhaps with >an overlapping check method). > >============= > >As defined for MPLS, not only can a PW-aware device >internally corrupt an encapsulated payload, but ANY MPLS LSR in the >path can corrupt the encapsulated payload. > >SB> This applies to both IP and MPLS PSNs. > >============= > > 4. Signaling FCS Retention With MPLS-based Pseudowires > > When using the signaling procedures in [4], there is a Pseudowire > Interface Parameter Identifier value used to signal the desire to > retain the FCS when advertising a VC label [5]: > >SB> It is now called a >SB> Pseudowire Interface Parameter Sub-TLV type > > > 8. IANA Considerations > > This document does not specify any new registries for IANA to > maintain. > > This document requires IANA to allocate a PWE3 Virtual Circuit FEC > element parameter ID [5]. > >It might be better to say that [5] - which is a blocking >ref does this - so no additional IANA action needed. > >=============== > > This specification also requires one value within the L2TP "Control > Message Attribute Value Pairs" section to be assigned by IANA as > per [8]. The new AVP is encoded as L2TP-TBA-1 in this document, and > should be referred to in the IANA L2TP parameters registry as "FCS > Retention." > >... but make it clear that IANA does have an action here. >Does this allocation need review and signoff by the L2TPext WG? > >=============== _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 16:44:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKo-0003kO-Dm; Sun, 24 Jul 2005 16:44:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKm-0003k1-FG for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 16:44:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23857 for ; Sun, 24 Jul 2005 16:44:25 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwnpS-0005fT-31 for pwe3@ietf.org; Sun, 24 Jul 2005 17:16:13 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 193F3142A3 for ; Sun, 24 Jul 2005 16:44:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter Date: Sun, 24 Jul 2005 14:44:11 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 19, 2005, at 8:57 AM, benjamin.niven-jenkins@bt.com wrote: > > Can I suggest a rewording to something like "Network operators and > their > subscribers are seeking to rationalize their networks by migrating > their > existing services and platforms onto IP or MPLS based packet switched > networks (PSN)." OK, I've implemented this recommendation... > >> PWE3 will evaluate the use of PW mechanisms for an "MPLS Pseudowire" >> to transparently carry an MPLS label stack and payload between two >> PE routers. > >> Specify a PW type that supports transparent carriage of IP payloads >> between disparate access services (e.g., ATM and Ethernet). > >> Enhance packet-based PW specifications as necessary to allow >> the emulated service to be carried transparently over the PSN, >> for example by the retention of the FCS across the PW. > > I think I've asked this before, but forgive me because I have forgotten > the answer. What is meant in these contexts by transparent. I > interpret transparent (with my ITU background) to mean the client is > not > modified/altered by the server (PW) over which is it transported. I > completely agree with transparently transferring clients (for my/the > ITU > understanding of transparent) but this seems to be at odds to some > existing PW drafts/implementations where client modification currently > takes place. > > Can I intepret these statements to mean that PWs used/designed (in > future) to transport IP or MPLS client payloads will transport those > payloads tranparently (according to my/the ITU understanding of > transparent), and that work will be undertaken to 'retrofit' > transparent > modes to existing PW types where necessary/demanded (e.g. by > enabling/allowing FCS retention etc.)? Sure.. We're all never going to agree on the complete set of terminology or exact language used in the charter, I believe the current text there suffices. >> Specify OAM mechanisms for all PW types, suitable for >> operation over both IP and MPLS PSNs, and capable of >> providing the necessary interworking with the OAM mechanisms >> of the emulated service. > > What is meant by 'suitable for operation over both IP and MPLS PSNs'? > Does this mean a single set of (identical) OAM mechanismx will be > specified that covers both the IP and MPLS PSN cases, or that OAM must > be specified for the IP and MPLS PSN cases individually and that the PW > OAM mechanisms specified for an IP PSN may differ from those specified > for an MPLS PSN? The charter isn't intended to define this, the subsequent requirements and WG efforts in the area will. > >> Define the reqiurements for and mechanisms needed to allow >> the operation of switched virtual circuits over a PSN. > > Correction: reqiurements => requirements Thanks for taking the time to review the charter and provide your feedback Ben! -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 16:44:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKp-0003ku-5X; Sun, 24 Jul 2005 16:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKm-0003k7-KY for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 16:44:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23863 for ; Sun, 24 Jul 2005 16:44:26 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwnpS-0005fS-2d for pwe3@ietf.org; Sun, 24 Jul 2005 17:16:13 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 316151429E for ; Sun, 24 Jul 2005 16:44:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5351e97a94494dc50bdc32cc97a9cd93@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter Date: Sun, 24 Jul 2005 14:44:05 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 21, 2005, at 1:53 PM, Matthew.Bocci@alcatel.co.uk wrote: > Danny, > > The last paragraph states the following: > > "Define the reqiurements for and mechanisms needed to allow > the operation of switched virtual circuits over a PSN." > > If I recall, we discussed this point on the list back in March. I think > that the meaning of this was related to interworking between, say, ATM > or > Frame Relay signalling, and PWE3. However, there are already a number > of > existing specifications either in existence or in an advanced state of > development (e.g. in the ITU-T and the MFA Forum). > > A number of people commented that this item should be removed, so I was > surprised to see that it is still in the draft charter. > > Please could you clarify the situation, Matthew, As you well know, simply because other organizations begin working on something before we formally pick it up it's no reason for us to defer control to them unless we have no interest in performing work on the item. If this weren't the case, adoption of most PWE3 work taken on by those organizations would have required complete disbanding of PWE3 :-) As you might well suspect, we absolutely welcome participation and contributions (individual or formal) from those organizations regarding these items. If folks believe there are other reasons why we should not take on this work, please bring it up on the mailing list under a different thread - but as of the last check and feedback we've collected, there seems to be general interest in performing this work in PWE3. Thanks! -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 16:44:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKp-0003lK-Ny; Sun, 24 Jul 2005 16:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKm-0003k9-Nb for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 16:44:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23860 for ; Sun, 24 Jul 2005 16:44:26 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwnpS-0005fV-2p for pwe3@ietf.org; Sun, 24 Jul 2005 17:16:13 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 46043142A6 for ; Sun, 24 Jul 2005 16:44:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <27A0F290348F8E45AEF79889DDE65A52050F8FB6@exrad2.ad.rad.co.il> References: <27A0F290348F8E45AEF79889DDE65A52050F8FB6@exrad2.ad.rad.co.il> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7c00f8fcb64ead59f7e7984a693f0ad3@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter - opening Date: Sun, 24 Jul 2005 14:44:15 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 20, 2005, at 3:58 AM, Yaakov Stein wrote: > > I am going to break my comments up by subject > in order to facilitate discussion. > > Network operators and their subscribers ... > > The present versions talks about service providers > and now we have "network operators" (i.e. PTOs) > and "subscribers" (an archaic term from the time > when clients were inextricably tied to a single provider). > > Is this progress? If that's a good thing, sure :-) > migrating to a single IP or MPLS based packet > switched network (PSN) > > Why are we keeping up the pretense of IP and MPLS? > The IP part is now handled by the l2tpext unless you are > refering to RFC4023 PWs or TDMoIP's use of UDP ports. I used Ben's proposed text here, I hope it will suffice. > ... and BTW, there is a statement about division of labor > with l2vpn, but no similar statement about l2tpext. I've added L2TPEXT explicitly here as well.. Thanks for the feedback Yaakov! -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 16:44:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKq-0003lk-A3; Sun, 24 Jul 2005 16:44:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKm-0003kH-Q8 for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 16:44:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23859 for ; Sun, 24 Jul 2005 16:44:26 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwnpS-0005fi-2x for pwe3@ietf.org; Sun, 24 Jul 2005 17:16:13 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id F3667142AB for ; Sun, 24 Jul 2005 16:44:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42DE1E6F.90908@cisco.com> References: <27A0F290348F8E45AEF79889DDE65A52050F8FB6@exrad2.ad.rad.co.il> <42DE1E6F.90908@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0661cbb448895646c253c96ebe6532a1@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter - opening Date: Sun, 24 Jul 2005 14:44:19 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 20, 2005, at 3:50 AM, Scott W Brim wrote: > > "Network operators" is good because "service" means much more than > carrying IP traffic these days, so it's too ambiguous. If you want to > be completely specific you could say "network transport service > providers". > > "Subscribers" is not good because "subscriber" is a business > relationship, not a traffic flow relationship -- the people or > whatever actually using the connections can be different from those > who pay for them. "User" is better. "network transport service providers" and "user" it is, assuming no suitable [tbd] objections. -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 16:44:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKt-0003mA-Fj; Sun, 24 Jul 2005 16:44:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnKo-0003kY-Fr for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 16:44:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23868 for ; Sun, 24 Jul 2005 16:44:28 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwnpX-0005fo-6W for pwe3@ietf.org; Sun, 24 Jul 2005 17:16:15 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id D6A67142AD for ; Sun, 24 Jul 2005 16:44:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <27A0F290348F8E45AEF79889DDE65A52050F8FB7@exrad2.ad.rad.co.il> References: <27A0F290348F8E45AEF79889DDE65A52050F8FB7@exrad2.ad.rad.co.il> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <82a0c89a617dcf675861f3123c67ce74@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] MPLS PWs Date: Sun, 24 Jul 2005 14:44:23 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 20, 2005, at 4:03 AM, Yaakov Stein wrote: > > PWE3 will evaluate the use of PW mechanisms for an "MPLS > Pseudowire" > to transparently carry an MPLS label stack and payload > between two > PE routers. > > I just received an email from Shahram pointing out to me > that this idea, which the two of us were pursuing a while back, > is now here for evaluation. > > Will the CW be obligatory for this PW type? > If not, what we have is an pseudo MPLS stack > with more than one S=1 header. Yes, indeed.. > While I think this is a great idea > (for example, for allowing transparent transport through > another domain), will the MPLS WG allow us to > standardize this? A brief discussion with the chairs a while back suggests yes. Thanks again! -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 16:48:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnOt-0004eT-0i; Sun, 24 Jul 2005 16:48:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnOm-0004aH-Q2 for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 16:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24163 for ; Sun, 24 Jul 2005 16:48:34 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwntV-0005ne-4E for pwe3@ietf.org; Sun, 24 Jul 2005 17:20:21 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 3627E142A3 for ; Sun, 24 Jul 2005 16:48:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <27A0F290348F8E45AEF79889DDE65A52050F9095@exrad2.ad.rad.co.il> References: <27A0F290348F8E45AEF79889DDE65A52050F9095@exrad2.ad.rad.co.il> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter nits Date: Sun, 24 Jul 2005 14:48:35 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Yaakov et al., I've incorporated a couple of the suggestions in the text below, but I'm purposely avoiding lots of rewording as a result of individual semantical interpretations that vary widely. Thanks for the careful review.. I'll send an updated rev in just a bit and if folks have comments that are far beyond semantics and personal preference please share them - else let's just move this along. -danny (reminded of why this was stalled many months ago and not willing to let that happen again) On Jul 21, 2005, at 1:39 AM, Yaakov Stein wrote: > > It is not intended that an emulated service will be > indistinguishable > from the service that is being emulated. > > I think a subjunctive form is required here: > > It is not intended for the emulated service to be indistinguishable > from the service being emulated. > > ================================================== > > Emulation necessarily involves a degree cost-performance trade-off. > > I think there is a degree of superfluousness here. > > Emulation necessarily involves a cost-performance trade-off. > > ================================================== > > All emulated service definitions will include an > applicability statement describing the faithfulness of the > emulation. > > I think a requirement is better than a prophecy. > > All emulated service definitions must include > applicability statements describing the faithfulness of the > emulation. > > ================================================== > > Switching, multiplexing, modification or other > operation on the traditional service, unless required as > part of the emulation, is out of the scope of the PWE3 WG. > > Indeed there is an "or", but it is being used as a conjunction. > ... and I never liked "out of the scope" either. > > > Switching, multiplexing, modification or other > operation on the traditional service, unless required as > part of the emulation, are out of scope. > > ================================================== > > PWE3 will make use of existing IETF specified mechanisms > unless there are technical reasons why the existing mechanisms > are insufficient or unnecessary. > > Clarity and frugality. > > PWE3 will utilize (exploit?) existing IETF-specified mechanisms > unless these are technically deficient or unnecessary. > > ================================================== > > PWE3 will investigate mechanisms necessary to perform clock > recovery and other real-time signaling functions. This work will > be coordinated with the AVT WG and RTP will be used where > appropriate. > > How about > > PWE3 will investigate mechanisms necessary to emulate real-time > signals, including clock recovery, handling of packet loss and > support for signaling. This work will be coordinated with the AVT WG > as appropriate. > > ================================================== > > PWE3 will work closely with the L2VPN WG to ensure a clear > demarcation is defined for where PWE3 stops and L2VPN starts. > > for clarity > > PWE3 will coordinate closely with the L2VPN WG, and work towards > a clear demarcation between the two WGs. > > ================================================== > > Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET. > > We don't want non-Americans to feel left out, do we? > > Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET/SDH. > > ================================================== > > Specify a PW type that supports transparent carriage of IP payloads > between disparate access services (e.g., ATM and Ethernet). > > (I am sure this one originated with Stewart.) > Isn't carriage something that turns into a pumpkin at midnight? > > Specify a PW type that supports transparent transport of IP payloads > between disparate access services (e.g., ATM and Ethernet). > > ================================================== > > Whilst a service provider may traffic engineer their network > is such a way that PW traffic will not cause significant ... > > their -> its ? (we don't want to say "his") > is -> in > is "traffic engineer" a compound verb? > will -> would (I don't know about whilst, but I believe while needs a > subjunctive). > > Whilst a service provider may employ traffic engineering > in order to reduce PW-induced congestion ... > > > Y(J)S > > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 16:58:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnXz-0006RQ-KV; Sun, 24 Jul 2005 16:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnXy-0006RL-3a for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 16:58:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24740 for ; Sun, 24 Jul 2005 16:58:03 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwo2g-00063L-QD for pwe3@ietf.org; Sun, 24 Jul 2005 17:29:51 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id BCCCE142A3 for ; Sun, 24 Jul 2005 16:58:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39170c8225f602142cb536a5691ac7aa@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter Date: Sun, 24 Jul 2005 14:58:05 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 24, 2005, at 2:35 AM, Moran Roth wrote: > Danny, > > The first objective of the WG states: > "Specify the following PW types and consider specification of > additional > PW types contingent on WG consensus and AD approval: > Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET." > > We would like to add Fibre Channel to the list of PW types, as we have > identified a requirement from network operators to carry Fibre Channel > over PW. This will allow the transparent transport of Fibre Channel > services over the PSN, along with the data and TDM services already > specified in the list. This will facilitate the extension of storage > area networks to support mission critical applications such as disaster > recovery and business continuity. Are other folks interested in this becoming a WG item? We've heard this from Moran a bit in the past, if there's additional support within the WG we can add it to the charter now... -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 17:25:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwny6-0002zG-0h; Sun, 24 Jul 2005 17:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwny4-0002z6-MK for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 17:25:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26127 for ; Sun, 24 Jul 2005 17:25:01 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwoSn-0006in-AD for pwe3@ietf.org; Sun, 24 Jul 2005 17:56:49 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 2569C142A3 for ; Sun, 24 Jul 2005 17:25:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: pwe3 From: Danny McPherson Date: Sun, 24 Jul 2005 15:25:03 -0600 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Subject: [PWE3] Second Draft of Charter 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Folks, Here's another draft of the charter incorporating a good bit of feedback received to date - thanks to everyone who has contributed. If you've got feedback on the functional components please let me know ASAP and I'll attempt to correct. I'm very much trying to avoid this being stalled again.. http://pwe3.tcb.net/pwe3-charter-2005072401.txt Thanks! -danny ----------------------- Pseudo Wire Emulation Edge to Edge (PWE3) WG Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS based packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF specified PSNs. A pseudowire emulates a point-to-point link, and provides a service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the two endpoints of the PW. PWE3 will investigate mechanisms necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and RTP will be used where appropriate. PWE3 will work closely with the L2VPN and L2TPEXT WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. WG Objectives (in order of priority): Specify the following PW types and consider specification of additional PW types contingent on WG consensus: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET. PWE3 may also specify a PW type which can be used for carrying a user's MPLS packets from one end of the PW to the other. In general, PWE3 will not specify mechanisms by which a PW may connect two different access services. However, PWE3 may specify such mechanisms for the special case where the access service payloads at both ends are known to consist entirely of IP packets. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. Specify OAM mechanisms for all PW types, suitable for operation over both IP and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Enhance packet-based PW specifications as necessary to allow the emulated service to be carried transparently over the PSN, for example by the retention of the FCS across the PW. Define mechanisms to permit the operation of a PW over a PSN that employs equal cost multiple path (ECMP) packet switching mechanism. A PW operating over a shared PSN does not have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define the requirements for and mechanisms needed to allow the operation of switched virtual circuits over a PSN. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jul 24 23:11:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtNe-0005rM-5L; Sun, 24 Jul 2005 23:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtNc-0005rH-1E for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 23:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16973 for ; Sun, 24 Jul 2005 23:11:45 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwtsN-0007SS-H5 for pwe3@ietf.org; Sun, 24 Jul 2005 23:43:35 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j6P3BisC008287; Sun, 24 Jul 2005 22:11:45 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 24 Jul 2005 23:11:44 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Danny McPherson'" , pwe3 Date: Sun, 24 Jul 2005 23:11:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [PWE3] Switched virtual circuits over a PSN 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Danny, I fully agree with Matthew. The requirements for and mechanisms needed to allow the operation of switched virtual circuits over a PSN have nothing to do with PSNs or Pseudo Wires and everthing with the control protocols that manage those switched virtual connections. I don't think the PWE3 WG is the right place to discuss the intricacies of PNNI. Peter > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: Sunday, July 24, 2005 4:44 PM > To: pwe3 > Subject: Re: [PWE3] Draft Charter > > > > On Jul 21, 2005, at 1:53 PM, Matthew.Bocci@alcatel.co.uk wrote: > > > Danny, > > > > The last paragraph states the following: > > > > "Define the reqiurements for and mechanisms needed to allow > > the operation of switched virtual circuits over a PSN." > > > > If I recall, we discussed this point on the list back in > March. I think > > that the meaning of this was related to interworking > between, say, ATM > > or > > Frame Relay signalling, and PWE3. However, there are > already a number > > of > > existing specifications either in existence or in an > advanced state of > > development (e.g. in the ITU-T and the MFA Forum). > > > > A number of people commented that this item should be > removed, so I was > > surprised to see that it is still in the draft charter. > > > > Please could you clarify the situation, > > Matthew, > As you well know, simply because other organizations begin working > on something before we formally pick it up it's no reason for us > to defer control to them unless we have no interest in performing > work on the item. If this weren't the case, adoption of most > PWE3 work taken on by those organizations would have required > complete disbanding of PWE3 :-) > > As you might well suspect, we absolutely welcome participation and > contributions (individual or formal) from those organizations > regarding > these items. If folks believe there are other reasons why we should > not take on this work, please bring it up on the mailing list under > a different thread - but as of the last check and feedback we've > collected, there seems to be general interest in performing this work > in PWE3. > > Thanks! > > -danny > > > _______________________________________________ > 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 Sun Jul 24 23:14:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtQ2-00069L-5w; Sun, 24 Jul 2005 23:14:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtPz-00068h-Vc for pwe3@megatron.ietf.org; Sun, 24 Jul 2005 23:14:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17145 for ; Sun, 24 Jul 2005 23:14:11 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwtug-0007We-OA for pwe3@ietf.org; Sun, 24 Jul 2005 23:46:02 -0400 Received: from [205.168.100.50] (unknown [10.0.12.156]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 66C83142B3 for ; Sun, 24 Jul 2005 23:13:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <294bee4896b0eda4b365c956c02f48e1@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Sun, 24 Jul 2005 21:13:50 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [PWE3] Re: Switched virtual circuits over a PSN 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 24, 2005, at 9:11 PM, Busschbach, Peter B (Peter) wrote: > Danny, > > I fully agree with Matthew. The requirements for and mechanisms needed > to allow the operation of switched virtual circuits over a PSN have > nothing to do with PSNs or Pseudo Wires and everthing with the control > protocols that manage those switched virtual connections. I don't > think the PWE3 WG is the right place to discuss the intricacies of > PNNI. Thanks for the feedback Peter. Could those in favor of adding SVCs to the PWE3 WG charter please support your position on the mailing list... -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 07:11:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0rn-00038Q-Is; Mon, 25 Jul 2005 07:11:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0rm-00037g-9N for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 07:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07055 for ; Mon, 25 Jul 2005 07:11:23 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx1Mc-0005ND-3m for pwe3@ietf.org; Mon, 25 Jul 2005 07:43:18 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 13:11:17 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PBBCDg015980; Mon, 25 Jul 2005 13:11:13 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA00982; Mon, 25 Jul 2005 12:11:11 +0100 (BST) Message-ID: <42E4C8CF.6010702@cisco.com> Date: Mon, 25 Jul 2005 12:11:11 +0100 From: Stewart Bryant 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: "Gray, Eric" Subject: Re: [PWE3] PWE3 IANA policy References: <313680C9A886D511A06000204840E1CF0C885D41@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885D41@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , "'erosen@cisco.com'" , 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Gray, Eric wrote: > Stewart, > > One question for clarification: does the second range end > at 4915 and the third start at 4915, is it 49152 for both or is > it intended that there should be a gap from 4916 to 49151? > I was just using the TCP/UDP ranges as an example to show how it worked elsewhere > I think the sense is that most people would like to have > as large an unconstrained range as possible. > > Also, what is the policy for Vendor Specific - i.e. - how > does it differ from Expert Review and FCFS? I was thinking more > along the lines of: > VS is the same as FCFS, however I think that the name VS was proposed by the IESG to state that other SDOs should not use it. > 0-1024 expert review > 1025-4096 Reserved > 4097- FCFS That would be fine with me. - Stewart > > -- > Eric > > --> -----Original Message----- > --> From: Stewart Bryant [mailto:stbryant@cisco.com] > --> Sent: Friday, July 22, 2005 5:43 PM > --> To: Gray, Eric > --> Cc: 'erosen@cisco.com'; Alex Zinin; pwe3@ietf.org > --> Subject: Re: [PWE3] PWE3 IANA policy > --> > --> > --> > --> > --> Gray, Eric wrote: > --> > --> > Folks, > --> > > --> > Based on Alex's "fresh eye" (and in particular, the reference to > --> > TCP/UDP port numbers), Eric Rosen's comments and all the earlier > --> > discussions I have seen or been a part of, I wonder if it might > --> > not be acceptable as a compromise to allocate a significantly > --> > smaller chunk to "Expert Review" (including a-piori assignments), > --> > possibly a similar size chunk as "Reserved" and the remainder as > --> > FCFS? > --> > --> Well UDP/TCP works with > --> > --> The Well Known Ports are those from 0 through 1023. > --> The Registered Ports are those from 1024 through 49151 > --> The Dynamic and/or Private Ports are those from 49152 through 65535 > --> > --> Would something similar work for us? > --> > --> i.e. expert review from 0 to 1023, vendor specific from > --> 1024 to 4915, do as you please from 49152 to 65535 > --> > --> - Stewart > --> > --> > > --> > One thing that is certain - both from past discussion and from > --> > this debate - is that a much smaller assignment space is needed > --> > for allocation based on any form of dialogue more complex than > --> > "Please" and "Thankyou". Allocating this much smaller space may > --> > make some people more comfortable with setting aside a similar > --> > size space that might be used either way later on - as long as > --> > the combination of "Expert Review" and "Reserved" is (possibly > --> > significantly) smaller than the currently suggested half of the > --> > proposed available space. > --> > > --> > -- > --> > Eric Gray > --> > > --> > --> -----Original Message----- > --> > --> From: pwe3-bounces@ietf.org > --> > --> [mailto:pwe3-bounces@ietf.org]On Behalf Of > --> > --> Eric Rosen > --> > --> Sent: Friday, July 22, 2005 2:21 PM > --> > --> To: Alex Zinin > --> > --> Cc: pwe3@ietf.org > --> > --> Subject: Re: [PWE3] PWE3 IANA policy > --> > --> > --> > --> > --> > --> > --> > --> I disagree with one aspect of your statement: > --> > --> > --> > --> "I consider other things like long delays, biased > --> > --> reviewer etc. > --> > --> a bug that can be dealt with and wouldn't optimize > --> > --> for it." > --> > --> > --> > --> Experience in a wide variety of settings (including, but > --> > --> not limited to, the > --> > --> IETF), shows that no matter how well-intended a process > --> > --> is, the process can > --> > --> be deflected from its intended goal by politics and > --> > --> bureaucracy. This isn't > --> > --> a "bug" that creeps in unexpectedly, it is an inherent > --> > --> characteristic of > --> > --> process, and it is something that is to be expected. > --> > --> > --> > --> That's why process A is usually associated with a second > --> > --> process B whose > --> > --> purpose is to allow the reversal of process A. > --> > --> ("Don't worry if the > --> > --> reviewer turns you down because he works for one of your > --> > --> competitors, you > --> > --> can appeal to the IESG. Don't worry if the IESG turns you > --> > --> down because they > --> > --> are resistant to unorthodox ideas, you can appeal to the > --> > --> IAB. Just fill > --> > --> out these forms in triplicate and wait six years.") > --> > --> > --> > --> So if you are considering a process which provides > --> > --> "sanity by expert > --> > --> review", you can't defend it just by saying "review is > --> > --> good", you also have > --> > --> to take into account the likelihood that the process will > --> > --> be delayed and/or > --> > --> deflected by bureaucratic and/or political considerations. > --> > --> Of course, the > --> > --> folks in charge of running the process never take this > --> > --> seriously, and always > --> > --> insist that everything is working fine, or at least will > --> > --> be working fine > --> > --> starting tomorrow, after the last bug is removed. > --> > --> > --> > --> On the purported disadvantages of "freedom": > --> > --> > --> > --> - SPs don't benefit from sanity checking > --> > --> > --> > --> This is a little overstated, it would be more accurate to > --> > --> say "SPs are not > --> > --> forced to await the results of the IETF processes". Of > --> > --> course, if you put > --> > --> it that way, it doesn't sound so bad ;-) > --> > --> > --> > --> - Potential proliferation of proprietary solutions, > --> > --> > --> > --> Actual marketplace competition before a single > --> > --> standard is chosen? > --> > --> Heavens. > --> > --> > --> > --> Note also that "sanity checking" does not prevent > --> > --> proliferation of > --> > --> standard solutions, as we certainly know in the > --> > --> MPLS-related areas. > --> > --> > --> > --> - other SDOs can work on their versions of PWs. > --> > --> > --> > --> And why shouldn't they? > --> > --> > --> > --> > Regarding the specific proposal of FCFS + I-D. I think it > --> > --> does not solve > --> > --> > any problem > --> > --> > --> > --> On the contrary, it solved the problem of finding > --> > --> something to which the WG > --> > --> could agree ;-) > --> > --> > --> > --> > --> > --> > --> > --> _______________________________________________ > --> > --> 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 Mon Jul 25 09:13:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2ln-000424-Cb; Mon, 25 Jul 2005 09:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwzEK-0000ml-JY for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 05:26:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00652 for ; Mon, 25 Jul 2005 05:26:34 -0400 (EDT) From: Jean-Loup.Ferrant@alcatel.fr Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwzj8-00028a-NJ for pwe3@ietf.org; Mon, 25 Jul 2005 05:58:28 -0400 Received: from frmail19.netfr.alcatel.fr (frmail19.netfr.alcatel.fr [155.132.251.19]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j6P9QVrd008106; Mon, 25 Jul 2005 11:26:31 +0200 To: pwe3@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Mon, 25 Jul 2005 11:26:30 +0200 X-MIMETrack: Serialize by Router on FRMAIL19/FR/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 07/25/2005 11:26:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 1.4 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 25 Jul 2005 09:13:21 -0400 Cc: Silvana.Rodrigues@Zarlink.Com, Tim.Frost@Zarlink.Com Subject: [PWE3] comment on "draft-frost-pwe3-timing-pw-reqs-00.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Dear sirs, I would like to address a comment on the following document: draft-frost-pwe3-timing-pw-reqs-00.txt In section 3 related to applications, the paragraph related to CE Synchronised Networks requires some clarification. It is explained that PE2 is loop timed to the AC input signal coming from CE2. As CE2 recovers its clock from the signal passing through PE2, this scenario seems to generate a timing loop situation between PE2 and CE2. I suggest that the text of this application scenario is modified to explain in more details how it works. Best regards Jean-Loup Ferrant NB: Sorry the previous mail had no title. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 09:32:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx34I-0005kk-RL; Mon, 25 Jul 2005 09:32:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx34G-0005Yv-H1 for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 09:32:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19548 for ; Mon, 25 Jul 2005 09:32:27 -0400 (EDT) From: Tim.Frost@Zarlink.Com Received: from cangate.zarlink.com ([209.226.172.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx3Z5-0002V4-3X for pwe3@ietf.org; Mon, 25 Jul 2005 10:04:22 -0400 Received: from semigate.zarlink.com (semigate.zarlink.com [134.199.97.245]) by cangate.zarlink.com (8.12.10/8.12.10) with ESMTP id j6PDWBK7018606; Mon, 25 Jul 2005 09:32:11 -0400 Received: from OTTMTA01.zarlink.com (ottmta01 [134.199.14.110]) by semigate.zarlink.com (8.11.6+Sun/8.11.6) with ESMTP id j6PDW4O21545; Mon, 25 Jul 2005 09:32:04 -0400 (EDT) In-Reply-To: To: Jean-Loup.Ferrant@alcatel.fr MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Mon, 25 Jul 2005 14:30:57 +0100 X-MIMETrack: Serialize by Router on ottmta01/Zarlink(Release 6.5.4|March 27, 2005) at 07/25/2005 09:32:04 AM, Serialize complete at 07/25/2005 09:32:04 AM X-Spam-Score: -95.52 () APPLICATION_RULE, DEAR_SOMETHING, HTML_40_50, HTML_MESSAGE, NO_REAL_NAME, RATE_RULE, USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.38 X-Spam-Score: 1.9 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: Silvana.Rodrigues@Zarlink.Com, pwe3@ietf.org Subject: [PWE3] Re: comment on "draft-frost-pwe3-timing-pw-reqs-00.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: , Content-Type: multipart/mixed; boundary="===============0537768358==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multipart message in MIME format. --===============0537768358== Content-Type: multipart/alternative; boundary="=_alternative 004A3EE680257049_=" This is a multipart message in MIME format. --=_alternative 004A3EE680257049_= Content-Type: text/plain; charset="US-ASCII" Hi Jean Loup, Thanks for the comment. Looking at it again, I think I can see how it might imply a timing loop, although this is not intended. I'll try and re-word it next time. I hope the revised figure 2 gives the idea better. Regards, Tim |<-------- Pseudo-wires -------->| | | | |<-- PSN Tunnel -->| | V V V V +-----+ AC +------+ +------+ AC +-----+ | CE1 | | | PE1 |==================| PE2 | | | CE2 | | |<---------|< ............PW1............. -|<---------|<- | | | | | | | | | | | | | | | ->|--------->|- ............PW2............. >|--------->| | | | | | | | | | | | | | | +-----+ | | | | +-----| ^ | | | | ^ |A | | | | G| +------------>| .............PW3.............. |-------------- | | |==================| | +-+ +------+ +------+ |L| +-+ Figure 2: Relationship to the CE Synchronized Scenario Jean-Loup.Ferrant@alcatel.fr 25/07/2005 10:26 To pwe3@ietf.org cc Silvana.Rodrigues@Zarlink.Com, Tim.Frost@Zarlink.Com Subject comment on "draft-frost-pwe3-timing-pw-reqs-00.txt" Dear sirs, I would like to address a comment on the following document: draft-frost-pwe3-timing-pw-reqs-00.txt In section 3 related to applications, the paragraph related to CE Synchronised Networks requires some clarification. It is explained that PE2 is loop timed to the AC input signal coming from CE2. As CE2 recovers its clock from the signal passing through PE2, this scenario seems to generate a timing loop situation between PE2 and CE2. I suggest that the text of this application scenario is modified to explain in more details how it works. Best regards Jean-Loup Ferrant NB: Sorry the previous mail had no title. --=_alternative 004A3EE680257049_= Content-Type: text/html; charset="US-ASCII"
Hi Jean Loup,

Thanks for the comment. Looking at it again, I think I can see how it might imply a timing loop, although this is not intended. I'll try and re-word it next time. I hope the revised figure 2 gives the idea better.

Regards,
Tim
|<-------- Pseudo-wires -------->|
| |
| |<-- PSN Tunnel -->| |
V V V V
+-----+ AC +------+ +------+ AC +-----+
| CE1 | | | PE1 |==================| PE2 | | | CE2 |
| |<---------|< ............PW1............. -|<---------|<- |
| | | | | | | | | | | | |
| ->|--------->|- ............PW2............. >|--------->| | |
| | | | | | | | | | | |
+-----+ | | | | +-----|
^ | | | | ^
|A | | | | G|
+------------>| .............PW3.............. |--------------
| | |==================| |
+-+ +------+ +------+
|L|
+-+

Figure 2: Relationship to the CE Synchronized Scenario

Jean-Loup.Ferrant@alcatel.fr
25/07/2005 10:26

To
pwe3@ietf.org

cc
Silvana.Rodrigues@Zarlink.Com, Tim.Frost@Zarlink.Com

Subject
comment on "draft-frost-pwe3-timing-pw-reqs-00.txt"

Dear sirs, I would like to address a comment on the following document: draft-frost-pwe3-timing-pw-reqs-00.txt In section 3 related to applications, the paragraph related to CE Synchronised Networks requires some clarification. It is explained that PE2 is loop timed to the AC input signal coming from CE2. As CE2 recovers its clock from the signal passing through PE2, this scenario seems to generate a timing loop situation between PE2 and CE2. I suggest that the text of this application scenario is modified to explain in more details how it works. Best regards Jean-Loup Ferrant NB: Sorry the previous mail had no title.
--=_alternative 004A3EE680257049_=-- --===============0537768358== 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 --===============0537768358==-- From pwe3-bounces@ietf.org Mon Jul 25 10:06:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3ba-0002Zx-O9; Mon, 25 Jul 2005 10:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3bZ-0002Sf-C1 for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 10:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22083 for ; Mon, 25 Jul 2005 10:06:51 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx46P-0003dW-VM for pwe3@ietf.org; Mon, 25 Jul 2005 10:38:47 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2005 10:06:04 -0400 X-IronPort-AV: i="3.95,140,1120449600"; d="scan'208"; a="63786813:sNHT1615822066" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j6PE61Vu025186; Mon, 25 Jul 2005 10:06:02 -0400 (EDT) Message-ID: <42E4F1C9.6050601@cisco.com> Date: Mon, 25 Jul 2005 08:06:01 -0600 From: Luca Martini User-Agent: Mail/News Client 1.0+ (X11/20050603) MIME-Version: 1.0 To: benjamin.niven-jenkins@bt.com Subject: Re: [PWE3] Segmented PWs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, sbrim@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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Ben, Yes, I think that including this text is a good idea. The performance of the PW ( client ) can only be as good as the performance offered by the transport ( Server ). I will format this text for terminology , and include a form of it in the next version. Luca benjamin.niven-jenkins@bt.com wrote: >Scott, > >See in-line. > >Ben > > > >>-----Original Message----- >>From: Scott W Brim [mailto:sbrim@cisco.com] >>On 07/08/2005 10:45 AM, benjamin.niven-jenkins@bt.com allegedly wrote: >> >> >>>"In a client/server relationship the performance of the >>> >>> >>client layer >> >> >>>is equal to the performance of the server layer plus any >>> >>> >>impairments >> >> >>>introduced by the client layer itself. Therefore it is not >>> >>> >>possible >> >> >>>for the client layer to provide better performance than the server >>>layer over which it is transported. >>> >>> >>Ben, as I think we discussed somewhere, "performance" is a >>service issue, and ultimately the only measurement that >>matters is at the application. That is, some of the >>performance characteristics which one might treasure in a low >>level transport technology might be irrelevant to the >>services you are actually trying to deliver over the higher >>layer. If you want to put text like this in, let's be clear >>on what it's important to measure. It depends on the >>particular performance metric(s) you care about in the client >>layer network. As Stewart points out, some of those >>performance metrics are better met in a PW environment. Does >>that fit with your premise? >> >> > >Two things. I tend to agree that ultimately performance only matters at >the 'service', however what if the 'service' is a transport (stratum) >service e.g. a network builder type service. For example if Operator X >sells an ATM link connection to Operator Y, but Operator X provides that >ATM link connection using a ATM PW? Then the performance >characteristics which one might treasure in a low level transport >technology may be relevant to the service? So I think we may agree >(basically that it depends on the particular performance metric(s) you >care about in the client layer network). The intention of my proposed >text is not to be prescriptive but just to offer guidance that this >issue of perfance inheritance should be carefully considered before >peering two server layers with each. > >Re: Stewart's point about some performance metrics may be better met in >a PW environment. I agree this may be the case and needs to be >considered as part of the 'careful consideration' I mention above. So I >think what your saying is X over Y over Z may not be suitable for >supporting application/service X but X over Y-PW over Z maybe suitable, >in which case I agree as I believe the performance inheritance needs to >be considered on an individual basis. > > > >>>Note: Due to this vertical performance inheritance and the >>> >>> >>different >> >> >>>performance provided by, and the characteristics of, each >>> >>> >>networking >> >> >>>mode it is generally advisable to stack modes that less efficiently >>>provide dedicated bandwidth/performance on top of modes that more >>>efficiently provide dedicated bandwidth/performance. >>> >>> >>Not directly deducible from previous text. Is the ability to >>provide dedicated bandwidth the only interesting metric? >> >> > >Most probably not, but I only provided the text as a 'starter for 10' to >generate some debate etc. I'm not a expert on performance. > > > >>>Therefore, it is necessary to carefully consider which server layer >>>modes (and/or technologies) it is appropriate to peer with >>> >>> >>one another >> >> >>>in order to provide the topmost client layer (the >>> >>> >>'service') with the >> >> >>>performance that it requires. This is a horizontal performance >>>relationship because the server layer partitions are peered >>> >>> >>with each >> >> >>>other horizontally." >>> >>> >>This I like :-) >> >> > >Good, this is my main point, i.e. this performance inheritance needs to >be considered & thought about at some point, preferably prior to >deploymment :-) > >Ben > >_______________________________________________ >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 Jul 25 10:52:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4KA-00016i-Du; Mon, 25 Jul 2005 10:52:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4K7-0000t2-6L for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 10:52:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27057 for ; Mon, 25 Jul 2005 10:52:53 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx4oy-0005QA-7P for pwe3@ietf.org; Mon, 25 Jul 2005 11:24:49 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 16:52:44 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PEqfDg019398; Mon, 25 Jul 2005 16:52:42 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA21945; Mon, 25 Jul 2005 15:52:40 +0100 (BST) Message-ID: <42E4FCB8.3010209@cisco.com> Date: Mon, 25 Jul 2005 15:52:40 +0100 From: Stewart Bryant 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: agenda@ietf.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: pwe3 , Danny McPherson Subject: [PWE3] PWE3 - TUESDAY, August 2, 2005 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org TUESDAY, August 2, 2005 1030-1230 Morning Session II INT pwe3 Pseudo Wire Emulation Edge to Edge WG 5 mins Agenda etc Status of WG drafts Setting the scene This session will be chaired by Danny McPherson. Slot times include questions. No overruns will be permitted. The purpose of the session is to determine which MS PW signalling protocol we wish to take forward as a WG draft. 10 mins Luca Martini Requirements for inter domain Pseudo-Wires http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-00.txt 15 mins Matthew Bocci An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge http://www.ietf.org/internet-drafts/draft-bocci-bryant-pwe3-ms-pw-arch-00.txt During each of the following sessions, the authors are asked to demonstrate: a) That the proposal satisfies the MS PW requirements b) How the proposal will be integrated with the existing MPLS and IP pseudowire encapsulations and signalling protocols (L2TPv3 and LDP) 10 mins Luca Martini Segmented Pseudo Wire http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-pw-00.txt 15 mins Rahul Aggarwal http://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-02.txt 15 mins Florin Balus Multi-Segment Pseudowire Setup and Maintenance using LDP http://www.ietf.org/internet-drafts/draft-balus-mh-pw-control-protocol-02.txt 15 mins Himanshu Shah Multi-Segment Pseudo Wire Signaling http://www.ietf.org/internet-drafts/draft-shah-bocci-pwe3-ms-pw-signaling-01.txt 10 mins Yakov Rekhter and Luca Martini Comparing and contrasting the LDP and RSVP approaches 25 mins Discussion: During this session the WG will determine which (one) of the three MS PW signalling protocols it wishes to take forward as a WG draft. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 11:03:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4UR-0008IE-GR; Mon, 25 Jul 2005 11:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4UQ-0008CS-50 for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 11:03:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27988 for ; Mon, 25 Jul 2005 11:03:32 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx4zH-0005lt-4J for pwe3@ietf.org; Mon, 25 Jul 2005 11:35:28 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 17:03:23 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PF3IDg022913; Mon, 25 Jul 2005 17:03:19 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA23129; Mon, 25 Jul 2005 16:03:17 +0100 (BST) Message-ID: <42E4FF35.5070800@cisco.com> Date: Mon, 25 Jul 2005 16:03:17 +0100 From: Stewart Bryant 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: agenda@ietf.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: pwe3 , Danny McPherson Subject: [PWE3] PWE3 WEDNESDAY, August 3, 2005 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org WEDNESDAY, August 3, 2005 0900-1000 Morning Session I INT pwe3 Pseudo Wire Emulation Edge to Edge WG 10 mins Chris Metz AII Types for Aggregation http://www.ietf.org/internet-drafts/draft-metz-aii-aggregate-00.txt 10 mins Moran Roth Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks http://www.ietf.org/internet-drafts/draft-roth-pwe3-fc-encap-00.txt 10 mins Vasile Radoaca PWE3 Applications & OAM Scenarios http://www.ietf.org/internet-drafts/draft-delord-pwe3-oam-applications-01.txt 10 mins Tim Frost Requirements for Pseudo Wires carrying Timing and Synchronization http://www.ietf.org/internet-drafts/draft-frost-pwe3-timing-pw-reqs-00.txt 10 mins Sasha Vainshtein Control Protocol Extensions for Setup of TDM Pseudowires http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-control-protocol-extensi-00.txt 5 mins Ron Cohen SONET/SDH Circuit Emulation over Packet (CEP) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-11.txt 5 mins Orly Nicklass Managed Objects for TDM over Packet Switched Network (PSN) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-03.txt _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 11:08:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4Z2-0005c1-Ux; Mon, 25 Jul 2005 11:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4Z0-0005O7-WE for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 11:08:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28351 for ; Mon, 25 Jul 2005 11:08:17 -0400 (EDT) Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx53r-0005ru-FZ for pwe3@ietf.org; Mon, 25 Jul 2005 11:40:13 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jul 2005 18:08:15 +0300 Message-ID: From: Sasha Vainshtein To: pwe3 Subject: RE: [PWE3] RE: comments on draft-ietf-pwe3-fcs-retention-03.txt Date: Mon, 25 Jul 2005 18:08:10 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: "'Malis, Andrew G.'" , Alik Shimelmits , 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="===============0278454436==" Sender: pwe3-bounces@ietf.org 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. --===============0278454436== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5912A.AB7D80B0" 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. ------_=_NextPart_001_01C5912A.AB7D80B0 Content-Type: text/plain; charset="iso-8859-1" Hi all, Wrt to to coverage/applicability issue raised by Stewart: IMO FCS retention draft applies only to the PW services that do not modify in any way the original frame. This definition excludes FR "Single DLCI" PW services (that strip the FR header at ingress and re-buiild it at egress, possibly with a new DLCI value) and Ethernet PW services which strip/insert service-delimiting VLAN tags. On the other hand, the FR Port Mode PW services are now undistinguishable from the HDLC services and hence do not modify any bits in the FR frame including FECN/BECN (because HDLC PWs do not recognize them). After some off-the-list discussion with Stewart and Andy it seems like the appropriate resolution of this issue would be to state explicitly to which modes of FR and Ethernet PW the FCS retention draft applies. With best regards, Sasha Vainshtein -----Original Message----- From: Malis, Andrew G. [mailto:Andy.Malis@Tellabs.com] Sent: Friday, July 22, 2005 5:31 PM To: Stewart Bryant Cc: pwe3 Subject: [PWE3] RE: comments on draft-ietf-pwe3-fcs-retention-03.txt Stewart, Thanks for the comments. We're past the submission window, so I'll get another revision ready in time for when it reopens. Do you want to see it first before I resubmit it? Cheers, Andy _____ From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Fri 7/22/2005 11:23 To: Malis, Andrew G. Cc: pwe3 Subject: comments on draft-ietf-pwe3-fcs-retention-03.txt Andy I was doing a final check on Document: draft-ietf-pwe3-fcs-retention-03.txt PWE3 Frame Check Sequence Retention - Stewart ============= The draft does not pass the nits checker ============= Since the draft covers frame relay and the FR draft says that the PW MAY change the FECN and/or BECN bits, it is probably worth noting that the FCS will have to change. It may also be worth noting that to preserve data integrity this means checking the FCS at the egress PE (perhaps with an overlapping check method). ============= As defined for MPLS, not only can a PW-aware device internally corrupt an encapsulated payload, but ANY MPLS LSR in the path can corrupt the encapsulated payload. SB> This applies to both IP and MPLS PSNs. ============= 4. Signaling FCS Retention With MPLS-based Pseudowires When using the signaling procedures in [4], there is a Pseudowire Interface Parameter Identifier value used to signal the desire to retain the FCS when advertising a VC label [5]: SB> It is now called a SB> Pseudowire Interface Parameter Sub-TLV type 8. IANA Considerations This document does not specify any new registries for IANA to maintain. This document requires IANA to allocate a PWE3 Virtual Circuit FEC element parameter ID [5]. It might be better to say that [5] - which is a blocking ref does this - so no additional IANA action needed. =============== This specification also requires one value within the L2TP "Control Message Attribute Value Pairs" section to be assigned by IANA as per [8]. The new AVP is encoded as L2TP-TBA-1 in this document, and should be referred to in the IANA L2TP parameters registry as "FCS Retention." ... but make it clear that IANA does have an action here. Does this allocation need review and signoff by the L2TPext WG? =============== ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ ------_=_NextPart_001_01C5912A.AB7D80B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable comments on draft-ietf-pwe3-fcs-retention-03.txt
Hi=20 all,

Wrt to=20 to coverage/applicability issue raised by Stewart:

IMO=20 FCS retention draft applies only to the PW services that do not modify = in any=20 way the original frame.

This=20 definition excludes FR "Single DLCI" PW services (that strip the FR = header at=20 ingress and re-buiild it at egress, possibly with a new DLCI value) and = Ethernet=20 PW services which strip/insert service-delimiting VLAN tags.=20

On the=20 other hand, the FR Port Mode PW services are now undistinguishable from = the HDLC=20 services and hence do not modify any bits in the FR frame including = FECN/BECN=20 (because HDLC PWs do not recognize them).

After=20 some off-the-list discussion with Stewart and Andy it seems = like the=20 appropriate resolution of this issue would be to state explicitly to = which modes=20 of FR and Ethernet PW the FCS retention draft = applies.

With best = regards,

&nb= sp; &nb= sp; Sasha=20 Vainshtein

-----Original = Message-----
From:=20 Malis, Andrew G. [mailto:Andy.Malis@Tellabs.com]
Sent: = Friday, July=20 22, 2005 5:31 PM
To: Stewart Bryant
Cc:=20 pwe3
Subject: [PWE3] RE: comments on=20 draft-ietf-pwe3-fcs-retention-03.txt

Stewart,

Thanks for the = comments. We're past=20 the submission window, so I'll get another revision ready in time for = when it=20 reopens. Do you want to see it first before I resubmit = it?

Cheers,

Andy

From: Stewart Bryant=20 [mailto:stbryant@cisco.com]
Sent: Fri 7/22/2005 = 11:23
To:=20 Malis, Andrew G.
Cc: pwe3
Subject: comments on=20 draft-ietf-pwe3-fcs-retention-03.txt
Andy

I was doing a final check = on

Document:=20 draft-ietf-pwe3-fcs-retention-03.txt
PWE3 Frame Check Sequence=20 Retention

- = Stewart

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The draft = does not pass=20 the nits = checker

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Since the = draft covers frame=20 relay and the FR draft
says that the PW MAY change the FECN and/or = BECN
bits, it is probably worth noting that the FCS
will have = to change.=20 It may also be worth noting
that to preserve data integrity this=20 means
checking the FCS at the egress PE (perhaps with
an = overlapping=20 check = method).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As = defined for MPLS, not only can a=20 PW-aware device
internally corrupt an encapsulated payload, but = ANY MPLS=20 LSR in the
path can corrupt the encapsulated = payload.

SB> This=20 applies to both IP and MPLS = PSNs.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

4.=20 Signaling FCS Retention With MPLS-based=20 Pseudowires

     When using the signaling=20 procedures in [4], there is a Pseudowire
     = Interface=20 Parameter Identifier value used to signal the desire=20 to
     retain the FCS when advertising a VC = label=20 [5]:

SB> It is now called a
SB> Pseudowire Interface = Parameter=20 Sub-TLV type

8. IANA=20 Considerations

     This document does not = specify=20 any new registries for IANA to
    =20 maintain.

     This document requires IANA = to=20 allocate a PWE3 Virtual Circuit FEC
     = element=20 parameter ID [5].

It might be better to say that [5] - which = is a=20 blocking
ref does this - so no additional IANA action=20 = needed.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&nbs= p;    This=20 specification also requires one value within the L2TP=20 "Control
     Message Attribute Value Pairs" = section to=20 be assigned by IANA as
     per [8]. The new = AVP is=20 encoded as L2TP-TBA-1 in this document, = and
     should=20 be referred to in the IANA L2TP parameters registry as=20 "FCS
     Retention."

... but make it = clear that=20 IANA does have an action here.
Does this allocation need review = and signoff=20 by the L2TPext = WG?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<= /DIV>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C5912A.AB7D80B0-- --===============0278454436== 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 --===============0278454436==-- From pwe3-bounces@ietf.org Mon Jul 25 11:48:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5C4-0000M5-8O; Mon, 25 Jul 2005 11:48:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5C2-0000Lz-T1 for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 11:48:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01521 for ; Mon, 25 Jul 2005 11:48:36 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx5gu-0007Lp-H2 for pwe3@ietf.org; Mon, 25 Jul 2005 12:20:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2005 08:48:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="3267011:sNHT20232440" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j6PFmKk6006927; Mon, 25 Jul 2005 11:48:23 -0400 (EDT) Message-ID: <42E509C4.6060004@cisco.com> Date: Mon, 25 Jul 2005 09:48:20 -0600 From: Luca Martini User-Agent: Mail/News Client 1.0+ (X11/20050603) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [PWE3] Draft Charter References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> In-Reply-To: <39170c8225f602142cb536a5691ac7aa@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Danny McPherson wrote: > > l 24, 2005, at 2:35 AM, Moran Roth wrote: > >> Danny, >> >> The first objective of the WG states: >> "Specify the following PW types and consider specification of additional >> PW types contingent on WG consensus and AD approval: >> Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET." >> >> We would like to add Fibre Channel to the list of PW types, as we have >> identified a requirement from network operators to carry Fibre Channel >> over PW. This will allow the transparent transport of Fibre Channel >> services over the PSN, along with the data and TDM services already >> specified in the list. This will facilitate the extension of storage >> area networks to support mission critical applications such as disaster >> recovery and business continuity. > > > Are other folks interested in this becoming a WG > item? We've heard this from Moran a bit in the > past, if there's additional support within the WG we > can add it to the charter now... > > -danny > I do not have any objections to having a Fibre Channel PW. If anything it's going to be an interesting topic , as I seem to remember lot's of timing requirements in the old fibre channel protocol. Anyway if we are going to create a Fibre Channel PW, then pwe3 is the right place to do it. Luca > > _______________________________________________ > 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 Jul 25 11:55:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5J7-0001wX-FX; Mon, 25 Jul 2005 11:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5J6-0001wQ-Cn for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 11:55:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02172 for ; Mon, 25 Jul 2005 11:55:54 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx5ny-0007d1-1F for pwe3@ietf.org; Mon, 25 Jul 2005 12:27:51 -0400 Received: from emachine (pcp08789264pcs.mtlrel01.nj.comcast.net[68.84.61.71]) by comcast.net (rwcrmhc11) with SMTP id <2005072515554401300hbjuie>; Mon, 25 Jul 2005 15:55:44 +0000 From: "Robert Hines" To: "'pwe3'" Date: Mon, 25 Jul 2005 11:55:39 -0400 Organization: Robert Hines all rigts reserved Message-ID: <000301c59131$4e533c70$6401a8c0@emachine> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <42E509C4.6060004@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Spam-Score: 1.2 (+) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit Subject: [PWE3] unsubscribe X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: b.hines@comcast.net List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 11:59:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5MA-0002sL-H1; Mon, 25 Jul 2005 11:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5M8-0002ry-Cr; Mon, 25 Jul 2005 11:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02484; Mon, 25 Jul 2005 11:59:02 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx5qq-0007jr-8x; Mon, 25 Jul 2005 12:30:59 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 17:58:40 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PFwbDg009042; Mon, 25 Jul 2005 17:58:37 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA29614; Mon, 25 Jul 2005 16:58:35 +0100 (BST) Message-ID: <42E50C2B.7000500@cisco.com> Date: Mon, 25 Jul 2005 16:58:35 +0100 From: Stewart Bryant 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: gash@att.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: pwe3 , avt@ietf.org Subject: [PWE3] draft-ash-avt-hc-over-mpls-protocol-01.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org In the example scenario, header compression therefore takes place between R1 and R4, and the MPLS path transports data/compressed-header/MPLS-labels instead of data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. SB> You claim a size reduction but at this stage you have not SB> said what the MPLS stack looks like. I assume that you have SB> two labels, and as I recall you have just the 000 nible not SB> the control word. The MPLS label stack and link-layer headers are not compressed. Therefore HC over MPLS can significantly reduce the header overhead through compression mechanisms. MPLS is used to route HC packets over an MPLS LSP without compression/decompression cycles at each intermediate router. MPLS pseudowires (PWs) SB> perhaps a reference? 8 octets V +------+----------------------------+ MPLS Labels |header| | +------+----------------------------+ \_________________ _________________/ V SB> The above is technically two layers - the PW ident and the CE SB> identifier. You may have other MPLS labels for example if you are SB> going over a VPN. The PW control octet is used to identify the packet types for certain HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as detailed in Section 4.2. SB> You should call up and SB> perhaps to explain why your bytes SB> start with zero. Note that ROHC [RFC3095] provides its own packet type within the protocol, and does not require use of the PW control octet. SB> see above 4. Protocol Specifications In Figure 1 we assume an example data flow set up from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header Compression is performed, and R4/HD is the egress router where header Decompression is done. Each router functions as an LSR and supports signaling of LSP/PWs. A summary of the procedures is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - PW Interface Parameters Sub-TLV SB> Do you need to copy this - wouldn't it be better to just reference SB> the definitive copy in the PW control RFC - just in case any typos SB> creep in? Figure 3 shows the HC over MPLS protocol stack. The PW control octet is used to identify the packet types for certain HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown in Figure 5: 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |0 0 0 0|Pkt Typ| +-+-+-+-+-+-+-+-+ Figure 5 - PW Control Octet where: "Packet Type" encoding: 0: Reserved 1: FULL_HEADER 2: COMPRESSED_TCP 3: COMPRESSED_TCP_NODELTA 4: COMPRESSED_NON_TCP 5: COMPRESSED_RTP_8 6: COMPRESSED_RTP_16 7: COMPRESSED_UDP_8 8: COMPRESSED_UDP_16 9: CONTEXT_STATE 10-15: MUST NOT BE ASSIGNED SB> re 10-15 - Why MNBA? Or do you mean reserved? As discussed in [ECMP-AVOID], since this MPLS payload type is not IP, the first nibble is set to 0000 to avoid being mistaken for IP. This is also consistent with the proposed encoding of the PWE3 control word [PW-CNTL-WORD]. SB> OK, you say this here. I think that you should say it earlier since SB> it is a design choice. 7. IANA Considerations As discussed in Section 4.1, new PW type values are assigned in [IANA] for HC over MPLS LSP/PWs. As discussed in Section 4.1, interface parameter sub-TLV type values are specified in [IANA] for both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. SB> You say that all IANA actions are described SB> in IANA and there are no additional IANA actions. Just to SB> make it clear for the IANA reviewer. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 12:02:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5PI-0003Ry-Ks; Mon, 25 Jul 2005 12:02:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5PH-0003Ro-7z for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 12:02:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02880 for ; Mon, 25 Jul 2005 12:02:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx5u9-0007se-0D for pwe3@ietf.org; Mon, 25 Jul 2005 12:34:14 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 18:02:09 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PG25Dg010341; Mon, 25 Jul 2005 18:02:05 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA00059; Mon, 25 Jul 2005 17:02:03 +0100 (BST) Message-ID: <42E50CFB.2000201@cisco.com> Date: Mon, 25 Jul 2005 17:02:03 +0100 From: Stewart Bryant 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: Yaakov Stein References: <27A0F290348F8E45AEF79889DDE65A5205027B1B@exrad2.ad.rad.co.il> In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205027B1B@exrad2.ad.rad.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org Subject: [PWE3] re draft-roth-pwe3-fc-encap-00.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org > Moran, > > Is there a good reason to have FC PWs but not SCSI ones, > or should we expect a SCSI PW encap as well ? > FC is a serial interface? Why do you ask? - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 12:37:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5xj-0004RE-EI; Mon, 25 Jul 2005 12:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5xi-0004R9-PJ for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 12:37:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05696 for ; Mon, 25 Jul 2005 12:37:52 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx6SZ-0000an-Nf for pwe3@ietf.org; Mon, 25 Jul 2005 13:09:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 18:37:43 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PGbdDg020065; Mon, 25 Jul 2005 18:37:40 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA03914; Mon, 25 Jul 2005 17:37:38 +0100 (BST) Message-ID: <42E51552.4040108@cisco.com> Date: Mon, 25 Jul 2005 17:37:38 +0100 From: Stewart Bryant 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: Moran Roth References: <13D5DF801DFEBE439353E0AAFE78541406CD87@tlvmail1.corrigent.com> In-Reply-To: <13D5DF801DFEBE439353E0AAFE78541406CD87@tlvmail1.corrigent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org Subject: [PWE3] draft-roth-pwe3-fc-encap-00.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Some comments on draft-roth-pwe3-fc-encap-00.txt - Stewart 4. Encapsulation This specification provides port to port transport of FC encapsulated traffic. The following FC connections are supported over the MPLS network: - N-Port to N-Port - N-Port to F-Port - E-Port to E-Port SB> Where are these types defined? 4.1. The Control Word The Generic PW control word, as defined in "PWE3 Control Word" [PW- CW] MAY be used for FC PW. The structure of the control word is as follows: SB> Do you mean MAY or MUST. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|0 0 0 0|FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - Control Word structure for the one-to-one mapping mode The Flags bits are not used for FC. These bits MUST be set to 0 by the ingress PE, and MUST be ignored by the egress PE. The FRG bits are used for PW PDU fragmentation as described in [PW- CW] and [FRAG]. The length field can be used to remove any padding added by the PSN. Its processing must follow the rules defined in [PW-CW]. The use of the sequence number is optional, and the processing must follow the rules as in [PW-CW]. SB> No, you have to describe the rules here. 4.2. MTU Requirements The network MUST be configured with an MTU that is sufficient to transport the largest encapsulation frames. SB> So you don't need frag you can say that the bits MUST be 00 When MPLS is used as the tunneling protocol, for example, this is likely to be 12 or more bytes greater than the largest frame size. The methodology described in [FRAG] MAY be used to fragment encapsulated frames that exceed the PSN MTU. However if [FRAG] is not used then if the ingress router determines that an encapsulated layer 2 PDU exceeds the MTU of the PSN tunnel through which it must be sent, the PDU MUST be dropped. SB> But now you say can use frag. Did you meant to say SHOULD above? 5. Security Considerations This document specifies only encapsulations, and not the protocols used to carry the encapsulated packets across the PSN. Each such protocol may have its own set of security issues [PW-MPLS] [RFC3985], but those issues are not affected by the encapsulations specified herein. Note that the security of the emulated service will only be as good as the security of the PSN. SB> Aren't FC apps a bit more sensitive to security than most apps? SB> SB> I think that you should consider writing an applicability section SB> I would imagine that FC has quite stringent requirements on SB> delay misordering latency etc. Would you consider it suitable SB> for ruuning over the pblic Internet? 6. IANA considerations A new PW type, named "FC Port Mode" is requested from IANA. The next available value of 0x0021 is requested. SB> The next available is 1F. But I don't think that you should quote a SB> value. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 12:47:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx66n-00068I-Tj; Mon, 25 Jul 2005 12:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx66m-00067t-Jf for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 12:47:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06425 for ; Mon, 25 Jul 2005 12:47:14 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx6be-0000rR-NH for pwe3@ietf.org; Mon, 25 Jul 2005 13:19:12 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 18:47:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PGkvDg022372; Mon, 25 Jul 2005 18:46:58 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA04954; Mon, 25 Jul 2005 17:46:56 +0100 (BST) Message-ID: <42E51780.9030508@cisco.com> Date: Mon, 25 Jul 2005 17:46:56 +0100 From: Stewart Bryant 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: Danny McPherson Subject: Re: [PWE3] Draft Charter References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> In-Reply-To: <39170c8225f602142cb536a5691ac7aa@tcb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org >> We would like to add Fibre Channel to the list of PW types, as we have >> identified a requirement from network operators to carry Fibre Channel >> over PW. This will allow the transparent transport of Fibre Channel >> services over the PSN, along with the data and TDM services already >> specified in the list. This will facilitate the extension of storage >> area networks to support mission critical applications such as disaster >> recovery and business continuity. > > > Are other folks interested in this becoming a WG > item? We've heard this from Moran a bit in the > past, if there's additional support within the WG we > can add it to the charter now... > It seems a useful wire type to me, and IETF is in the SAN business. From what I have heard it will need a careful applicability statement. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 13:02:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6L3-0000co-Vl; Mon, 25 Jul 2005 13:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6L1-0000ca-G8 for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 13:01:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07341 for ; Mon, 25 Jul 2005 13:01:57 -0400 (EDT) From: benjamin.niven-jenkins@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx6ps-0001I1-PJ for pwe3@ietf.org; Mon, 25 Jul 2005 13:33:55 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 18:01:41 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Jul 2005 18:01:40 +0100 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] draft-roth-pwe3-fc-encap-00.txt Date: Mon, 25 Jul 2005 18:02:32 +0100 Message-ID: Thread-Topic: [PWE3] draft-roth-pwe3-fc-encap-00.txt Thread-Index: AcWRN1ohK2Z3DzkcT5yO3Wi72617IAAAvcoA To: X-OriginalArrivalTime: 25 Jul 2005 17:01:40.0908 (UTC) FILETIME=[87017EC0:01C5913A] X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Stewart et al, > SB> I think that you should consider writing an applicability=20 > section I=20 > SB> would imagine that FC has quite stringent requirements on delay=20 > SB> misordering latency etc. Would you consider it suitable=20 > for ruuning=20 > SB> over the pblic Internet? I don't think it should be 'considered', according the old and the new charter it is mandatory: Old charter: "Applicability statements for each service will describe expected shortfalls of the emulation's faithfulness." New charter: "All emulated service definitions must include an applicability statement describing the faithfulness of the emulation." Ben _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 13:08:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6Rb-0002OK-ES; Mon, 25 Jul 2005 13:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6RY-0002O7-Tv for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 13:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07844 for ; Mon, 25 Jul 2005 13:08:41 -0400 (EDT) Received: from radmail1.rad.co.il ([62.0.23.193] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx6wM-0001WN-Cs for pwe3@ietf.org; Mon, 25 Jul 2005 13:40:39 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j6PH6B3Q019841 for ; Mon, 25 Jul 2005 20:06:13 +0300 (IDT) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j6PH6Bgd019838; Mon, 25 Jul 2005 20:06:11 +0300 (IDT) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2005 20:08:57 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A52050F948B@exrad2.ad.rad.co.il> Thread-Topic: re draft-roth-pwe3-fc-encap-00.txt Thread-Index: AcWROrSxqIDlwJ7QRIO/4fYKkeYZNAAB636w From: "Yaakov Stein" To: "Stewart Bryant" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: [PWE3] RE: re draft-roth-pwe3-fc-encap-00.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org =20 > FC is a serial interface?=20 I don't see your point here. We have bit-oriented PWs, and byte oriented ones, and cell-oriented ones. > Why do you ask? Well, it is simplest to understand how to convert FCIP into a PW, since it is based on a tunnel through the IP network. However, there aer quite a few SANs that iSCSI, in fact there are a few tremendously large iSCSI networks. iSCSI runs over TCP/IP, and thus gets bogged down in routers. It would seem that upgrading iSCSI to tunneling over MPLS would=20 be a natural speed-up, considering the datarates. Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 13:38:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6tv-0000Ux-8G; Mon, 25 Jul 2005 13:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6tt-0000Uo-5M; Mon, 25 Jul 2005 13:38:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09386; Mon, 25 Jul 2005 13:37:58 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dx7Ok-0002PE-PQ; Mon, 25 Jul 2005 14:09:56 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-11.tower-126.messagelabs.com!1122312994!4553309!21 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 7021 invoked from network); 25 Jul 2005 17:37:44 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-11.tower-126.messagelabs.com with SMTP; 25 Jul 2005 17:37:44 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B0001ED6B; Mon, 25 Jul 2005 13:37:44 -0400 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 Date: Mon, 25 Jul 2005 12:37:44 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE694@KCCLUST06EVS1.ugd.att.com> Thread-Topic: draft-ash-avt-hc-over-mpls-protocol-01.txt Thread-Index: AcWRMcSV9mx5chWkR/u+Vy5Vq6w29gABbnKw From: "Ash, Gerald R $Jerry$, ALABS" To: "Stewart Bryant" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R $Jerry$, ALABS" , pwe3 , avt@ietf.org Subject: [PWE3] RE: draft-ash-avt-hc-over-mpls-protocol-01.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Hi Stewart, Thanks a lot for your comments and suggestions. > In the example scenario, header compression therefore takes place > between R1 and R4, and the MPLS path transports > data/compressed-header/MPLS-labels instead of > data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. >=20 > SB> You claim a size reduction but at this stage you have not > SB> said what the MPLS stack looks like. I assume that you have > SB> two labels, and as I recall you have just the 000 nibble not > SB> the control word. Right, we should clarify that we have (typically) 2 MPLS labels and a PW Control Octet. =20 > The MPLS label stack and link-layer headers are not compressed. =20 > Therefore HC over MPLS can significantly reduce the header > overhead through compression mechanisms. >=20 > MPLS is used to route HC packets over an MPLS LSP without > compression/decompression cycles at each intermediate=20 > router. MPLS pseudowires (PWs) > > SB> perhaps a reference? OK, we can reference the PW architecture http://ietf.org/rfc/rfc3985.txt. > 8 octets V > +------+----------------------------+ > MPLS Labels |header| | > +------+----------------------------+ > \__________________________________/ > V >=20 > SB> The above is technically two layers - the PW ident and the CE > SB> identifier. You may have other MPLS labels for example if you are > SB> going over a VPN. OK, we'll clarify in next revision. =20 > The PW control octet is used to identify the packet types=20 > for certain HC schemes, including cTCP [RFC1144], IPHC > [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as > detailed in Section 4.2. >=20 > SB> You should call up and > SB> perhaps to explain why your bytes > SB> start with zero. OK, we can reference [ECMP-AVOID] and [PW-CNTL-WORD] here as well in in Section 4.2. =20 > Note that ROHC [RFC3095] provides its own packet type within > the protocol, and does not require use of the PW control > octet. >=20 > SB> see above >=20 > > 4. Protocol Specifications >=20 > In Figure 1 we assume an example data flow set up from R1/HC --> > R2 --> R3 --> R4/HD, where R1/HC is the ingress router where > header compression is performed, and R4/HD is the egress router=20 > where header decompression is done. Each router functions as an > LSR and supports signaling of LSP/PWs. A summary of the > procedures is as follows: >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-TLV Type | Length | Variable Length Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Length Value | > | " | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 4 - PW Interface Parameters Sub-TLV >=20 > SB> Do you need to copy this - wouldn't it be better to just reference > SB> the definitive copy in the PW control RFC - just in case any typos > SB> creep in? OK, we can remove Figure 4 and just reference [PW-SIG]. > Figure 3 shows the HC over MPLS protocol stack. The PW=20 > control octet is used to identify the packet types for > certain HC schemes, including cTCP [RFC1144], IPHC > [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown > in Figure 5: >=20 >=20 > 0 1 2 3 4 5 6 7 8 > +-+-+-+-+-+-+-+-+ > |0 0 0 0|Pkt Typ| > +-+-+-+-+-+-+-+-+ >=20 > Figure 5 - PW Control Octet >=20 > where: >=20 > "Packet Type" encoding: > 0: Reserved > 1: FULL_HEADER > 2: COMPRESSED_TCP > 3: COMPRESSED_TCP_NODELTA > 4: COMPRESSED_NON_TCP > 5: COMPRESSED_RTP_8 > 6: COMPRESSED_RTP_16 > 7: COMPRESSED_UDP_8 > 8: COMPRESSED_UDP_16 > 9: CONTEXT_STATE > 10-15: MUST NOT BE ASSIGNED >=20 > SB> re 10-15 - Why MNBA? Or do you mean reserved? The MNBA language suggested by Colin Perkins. If the these values are to be assigned in the future, then we need to specify a registry, which we're not doing at the moment. =20 > As discussed in [ECMP-AVOID], since this MPLS payload=20 > type is not IP, the first nibble is set to 0000 to > avoid being mistaken for IP. This is also consistent > with the proposed encoding of the PWE3 control word > [PW-CNTL-WORD]. >=20 > SB> OK, you say this here. I think that you should say it=20 > SB> earlier since it is a design choice. OK, as above. > 7. IANA Considerations >=20 > As discussed in Section 4.1, new PW type values are assigned in > [IANA] for HC over MPLS LSP/PWs. As discussed in Section 4.1, > interface parameter sub-TLV type values are specified in=20 > [IANA] for both the network control protocol for IPv4, IPCP > [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. >=20 > SB> You say that all IANA actions are described > SB> in IANA and there are no additional IANA actions. Just to > SB> make it clear for the IANA reviewer. We should actually clarify the second sentence to say that: "As discussed in Section 4.1, interface parameter sub-TLV type values *need to be* specified in [IANA] for both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]." [IANA] http://ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.txt does not now specify sub-TLV type values for the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. Thanks, Regards, Jerry=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 14:15:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7QX-0006yi-9N; Mon, 25 Jul 2005 14:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7QS-0006yY-5D for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 14:11:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11609 for ; Mon, 25 Jul 2005 14:11:39 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx7vL-0003Rn-3r for pwe3@ietf.org; Mon, 25 Jul 2005 14:43:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2005 11:11:19 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="3291046:sNHT20630620" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j6PIBFk6017605; Mon, 25 Jul 2005 14:11:16 -0400 (EDT) Message-ID: <42E52B42.7070609@cisco.com> Date: Mon, 25 Jul 2005 12:11:14 -0600 From: Luca Martini User-Agent: Mail/News Client 1.0+ (X11/20050603) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [PWE3] PWE3 IANA policy References: <200507191732.j6JHWGfX013213@rotala.raleigh.ibm.com> In-Reply-To: <200507191732.j6JHWGfX013213@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "W. Mark Townsley" , erosen@cisco.com, Danny McPherson , 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Thomas Narten wrote: > > >Big deal. If folk care, they allocate a second code point and require >that implementations of the standard support both for backwards >compatability. This is not a problem. > >Thomas > > > Maybe not for the IETF , but it will cost the Service providers, real money! Changing a protocol in a deployed network , just because the allocation body was too slow to allocate the value requires significant time and effort. More likely the market will accept the established value. Luca >_______________________________________________ >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 Jul 25 14:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7YU-0000Kp-0V; Mon, 25 Jul 2005 14:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7YR-0000Kk-Tr for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 14:19:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11977 for ; Mon, 25 Jul 2005 14:19:54 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx83I-0003eK-GK for pwe3@ietf.org; Mon, 25 Jul 2005 14:51:51 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 19:19:35 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Jul 2005 19:19:35 +0100 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] draft-roth-pwe3-fc-encap-00.txt Date: Mon, 25 Jul 2005 19:19:35 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1E44@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [PWE3] draft-roth-pwe3-fc-encap-00.txt Thread-Index: AcWRN1ohK2Z3DzkcT5yO3Wi72617IAAAvcoAAAF+biA= To: , X-OriginalArrivalTime: 25 Jul 2005 18:19:35.0847 (UTC) FILETIME=[697C9370:01C59145] X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Ben, > Stewart et al, >=20 > > SB> I think that you should consider writing an applicability > > section I > > SB> would imagine that FC has quite stringent requirements on delay > > SB> misordering latency etc. Would you consider it suitable=20 > > for ruuning > > SB> over the pblic Internet? >=20 > I don't think it should be 'considered', according the old and the new > charter it is mandatory: >=20 > Old charter: "Applicability statements for each service will describe > expected shortfalls of the emulation's faithfulness." >=20 > New charter: "All emulated service definitions must include an > applicability statement describing the faithfulness of the emulation." >=20 > Ben NH=3D> I agree. But you/I know there is a server->client performance inheritance issue here that has not been addressed to date, largely because this was not something we needed to worry about. That is, when the link connections in your layer network are provided by trails in a co-cs or co-ps_CBR server layer network then this issue is not significant. However, if this is not the case then one cannot assume it is no longer not significant. Further, not only are there no rules on what client/server relationships can exist between the (3) modes but there are no rules on how many such client/server transitions could be encountered. {Aside=3D> I've some ideas on how to model this (which I've fed in R&D work here in BT) but it looks complex to me (understatement)....and of course performance (inheritance) is now load sensitive (in all lower layer networks which are not co-cs or co-ps_CBR)}. So, in order to fulfil what appears to be (correctly) stated in the charter then some good network models will be required with both end-end objectives (for some set of NP metrics) and these need to be broken back to smaller partition impairment allowances, ie operators need to know what NP they are required to meet (because ultimately this comes down to some measurements), and customers will also want to know what they are getting in SLAs. After all, if we cannot quantify this stuff then how can we measure/control/apportion it in any meaningful and fair way?=20 Should be an interesting exercise...especially noting that to even get on NP page there are several things that must precede it, ie what I call 'an order of processing', viz: - the mode defines the defects that are relevant and required OAM - the defects need to be quantified wrt entry/exit criteria and consequent actions - defect persistency sets availability entry/exit criteria and consequent actions....one of which is.. - NP aggregation (for SLA purposes) in only valid in the up-state (ie available time) regards, Neil _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 15:08:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8JL-0001Qa-W8; Mon, 25 Jul 2005 15:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8JJ-0001QG-RK; Mon, 25 Jul 2005 15:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15258; Mon, 25 Jul 2005 15:08:20 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx8oC-0004zN-SR; Mon, 25 Jul 2005 15:40:18 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 21:08:11 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PJ83Dg021280; Mon, 25 Jul 2005 21:08:04 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA18122; Mon, 25 Jul 2005 20:08:02 +0100 (BST) Message-ID: <42E53892.2060708@cisco.com> Date: Mon, 25 Jul 2005 20:08:02 +0100 From: Stewart Bryant 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: "Ash, Gerald R $Jerry$, ALABS" References: <9473683187ADC049A855ED2DA739ABCA060CE694@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060CE694@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: pwe3 , avt@ietf.org Subject: [PWE3] Re: draft-ash-avt-hc-over-mpls-protocol-01.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org >> Figure 3 shows the HC over MPLS protocol stack. The PW >> control octet is used to identify the packet types for >> certain HC schemes, including cTCP [RFC1144], IPHC >> [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown >> in Figure 5: >> >> >> 0 1 2 3 4 5 6 7 8 >> +-+-+-+-+-+-+-+-+ >> |0 0 0 0|Pkt Typ| >> +-+-+-+-+-+-+-+-+ >> >> Figure 5 - PW Control Octet >> >> where: >> >> "Packet Type" encoding: >> 0: Reserved >> 1: FULL_HEADER >> 2: COMPRESSED_TCP >> 3: COMPRESSED_TCP_NODELTA >> 4: COMPRESSED_NON_TCP >> 5: COMPRESSED_RTP_8 >> 6: COMPRESSED_RTP_16 >> 7: COMPRESSED_UDP_8 >> 8: COMPRESSED_UDP_16 >> 9: CONTEXT_STATE >> 10-15: MUST NOT BE ASSIGNED >> >>SB> re 10-15 - Why MNBA? Or do you mean reserved? > > > The MNBA language suggested by Colin Perkins. If the these values are > to be assigned in the future, then we need to specify a registry, which > we're not doing at the moment. > > Yes, but you could imagine that some new requirement might come along say sctp or dccp, and the language here will cause some argument. Setting up the registry, is not difficult, and no one is going to argue against Expert Review as the allocation policy in this case :) > > >>7. IANA Considerations >> >> As discussed in Section 4.1, new PW type values are assigned in >> [IANA] for HC over MPLS LSP/PWs. As discussed in Section 4.1, >> interface parameter sub-TLV type values are specified in >> [IANA] for both the network control protocol for IPv4, IPCP >> [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. >> >>SB> You say that all IANA actions are described >>SB> in IANA and there are no additional IANA actions. Just to >>SB> make it clear for the IANA reviewer. > > > We should actually clarify the second sentence to say that: > "As discussed in Section 4.1, interface parameter sub-TLV type values > *need to be* specified in [IANA] for both the network control protocol > for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]." > > [IANA] > http://ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.txt > does not now specify sub-TLV type values for the network control > protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. > > Thanks, > Regards, > Jerry OK - I saw a bunch of your values in there, and did not notice that you needed more. It's likely that there will be another spin of IANA when we resolve the allocation policy, so you should give Luca the list to put in next time he does an update. - Stewart > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jul 25 16:34:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9eS-0002oN-7u; Mon, 25 Jul 2005 16:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9eQ-0002oI-SA for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 16:34:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21638 for ; Mon, 25 Jul 2005 16:34:13 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxA9K-0007jD-U0 for pwe3@ietf.org; Mon, 25 Jul 2005 17:06:12 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2005 13:34:04 -0700 X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208,217"; a="650633879:sNHT38138028" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PKY3Is023236; Mon, 25 Jul 2005 13:34:03 -0700 (PDT) Received: from xmb-sjc-22a.amer.cisco.com ([128.107.191.81]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 13:34:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Jul 2005 13:34:18 -0700 Message-ID: <999D9C7316770741A028EF2A88B8E46864693E@xmb-sjc-22a.amer.cisco.com> Thread-Topic: draft-ietf-pwe3-cesopsn-03.txt and draft-ietf-pwe3-satop-02.txt Thread-Index: AcWRWDrv+lc1UPUMSxOOQG5hwRXV3g== From: "Bill Storer $bstorer$" To: , X-OriginalArrivalTime: 25 Jul 2005 20:34:03.0467 (UTC) FILETIME=[3229B1B0:01C59158] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [PWE3] draft-ietf-pwe3-cesopsn-03.txt and draft-ietf-pwe3-satop-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: , Content-Type: multipart/mixed; boundary="===============0212611173==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0212611173== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59158.320FA36C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59158.320FA36C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, =20 I'm a bit confused about the placement of the RTP header and control word in these drafts. For IP, we have the RTP header before the control word. For MPLS, we have the RTP header after the control word. =20 =20 Could you elaborate on the reasons for this difference? =20 =20 Thanks, =20 =20 Bill =20 =20 ------_=_NextPart_001_01C59158.320FA36C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 Sasha,

I'm a = bit confused=20 about the placement of the RTP header and control word in these = drafts. =20 For IP, we have the RTP header before the control word. For MPLS, = we have=20 the RTP header after the control word.

Could = you elaborate=20 on the reasons for this difference?

Thanks,

Bill

------_=_NextPart_001_01C59158.320FA36C-- --===============0212611173== 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 --===============0212611173==-- From pwe3-bounces@ietf.org Mon Jul 25 22:25:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxF7u-00071K-3H; Mon, 25 Jul 2005 22:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxF7s-000705-HM for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 22:25:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14961 for ; Mon, 25 Jul 2005 22:24:58 -0400 (EDT) Received: from [202.179.105.26] (helo=pljy103a.siemens.com.my) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxFci-0001I1-G7 for pwe3@ietf.org; Mon, 25 Jul 2005 22:57:00 -0400 Received: from PLJY128A.my001.siemens.net (Not Verified[140.231.120.65]) by pljy103a.siemens.com.my with NetIQ MailMarshal (v5.5.6.6) id ; Tue, 26 Jul 2005 10:23:58 +0800 Received: from PLJY083A.my001.siemens.net ([140.231.124.30]) by PLJY128A.my001.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 10:24:28 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PWE3] unsubscribe Date: Tue, 26 Jul 2005 10:24:27 +0800 Message-ID: <9B60A5B0F17BBB4791CB35E6405D93685B47D7@PLJY083A.my001.siemens.net> Thread-Topic: [PWE3] unsubscribe thread-index: AcWRiSThA1tobNfuSP+KPvJWOPurIA== From: "Kueh Edmund" To: X-OriginalArrivalTime: 26 Jul 2005 02:24:28.0371 (UTC) FILETIME=[25FB7230:01C59189] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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="===============1579545776==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1579545776== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59189.25A28CC9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59189.25A28CC9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #########################################################################= ############ Note: This message is for the named person's use only. It may contain confiden= tial, proprietary or legally privileged information. No confidentiality or pri= vilege is waived or lost by any mistransmission. If you receive this message in= =20error, please immediately delete it and all copies of it from your system, destr= oy any hard copies of it and notify the sender. You must not, directly or indir= ectly, use, disclose, distribute, print, or copy any part of this message if you= =20are not the intended recipient. SIEMENS MULTIMEDIA SDN BHD and any of its subsidi= aries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, e= xcept where the message states otherwise and the sender is authorized to state them t= o be the views of any such entity. #########################################################################= ############ ------_=_NextPart_001_01C59189.25A28CC9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ; Tue, 26 Jul 2005 00:22:24 -0400 (EDT) Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxHSS-0004M9-Rc for pwe3@ietf.org; Tue, 26 Jul 2005 00:54:28 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jul 2005 07:22:20 +0300 Message-ID: From: Sasha Vainshtein To: "'Bill Storer (bstorer) '" , "'pwe3@ietf.org '" Date: Tue, 26 Jul 2005 07:22:18 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [PWE3] RE: draft-ietf-pwe3-cesopsn-03.txt and draft-ietf-pwe3-satop-02.t xt 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Hi Bill, Yes indeed, placement of RTP header and Control Word in these drafts differ between IP and MPLS encapsulations. This issue has been discussed on the PWE3 mailing list, and this arrangement is a result of the need tomeet to requirements: - compliance with the traditional usage of RTP over IPv4/IPv6 PSN - MPLS ECMP avoidance (which is critical for TDM pseudo-wires) as described in draft-ietf-mpls-ecmp-bcp-01.txt and compliance with the requirement for the preferred and generic PWE3 control word formats (as defind in draft-ietf-pwe3-cw-05). This is explicitly stated in the Note in Section 5.1 of draft-ietfp-we3-cesopsn-03. For historical purposes I'd like to add that one of the arguments against such a difference raised during the WG discussions was the fact that the 1st nibble of RTP header (should it directly follow the MPLS label stack) is 8 or more. However, this argument has been rejected by the WG because 8 is a registered (even if probably never used!) IP version with IANA. Hopefully this helps to clarify the situation. Regards, Sasha -----Original Message----- From: Bill Storer (bstorer) To: pwe3@ietf.org; Sasha Vainshtein Sent: 7/25/2005 10:34 PM Subject: draft-ietf-pwe3-cesopsn-03.txt and draft-ietf-pwe3-satop-02.txt Hi Sasha, I'm a bit confused about the placement of the RTP header and control word in these drafts. For IP, we have the RTP header before the control word. For MPLS, we have the RTP header after the control word. Could you elaborate on the reasons for this difference? Thanks, Bill _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 06:53:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxN3t-00014e-Vf; Tue, 26 Jul 2005 06:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxN3r-00014X-Qt for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 06:53:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05866 for ; Tue, 26 Jul 2005 06:53:21 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxNYt-00077y-Bp for pwe3@ietf.org; Tue, 26 Jul 2005 07:25:28 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j6QAiRU07556 for ; Tue, 26 Jul 2005 12:44:27 +0200 Received: from [127.0.0.1] ([172.16.2.192]) by mail1.imc.kth.se; Tue, 26 Jul 2005 12:50:23 +0200 Message-ID: <42E6156D.3020808@pi.se> Date: Tue, 26 Jul 2005 12:50:21 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Subject: Re: [PWE3] Draft Charter References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> In-Reply-To: <42E509C4.6060004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org All, I've one immediate reaction reading the charter - this is quite a bit of work too take on. is it the intention that we should do all this is one go? Wouldn't be better to focus? /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 07:42:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNp1-00033d-03; Tue, 26 Jul 2005 07:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNoz-00033Y-F0 for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 07:42:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08842 for ; Tue, 26 Jul 2005 07:42:04 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxOJz-0000FT-Fr for pwe3@ietf.org; Tue, 26 Jul 2005 08:14:10 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Jul 2005 13:41:53 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6QBfnDg025502; Tue, 26 Jul 2005 13:41:50 +0200 (MEST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-37.cisco.com [64.103.65.37]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA28769; Tue, 26 Jul 2005 12:41:48 +0100 (BST) Message-ID: <42E6217C.5070007@cisco.com> Date: Tue, 26 Jul 2005 12:41:48 +0100 From: Stewart Bryant 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: Loa Andersson Subject: Re: [PWE3] Draft Charter References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> In-Reply-To: <42E6156D.3020808@pi.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org There are four core elements to the charter: 1) Finishing the work on simple pt-pt PWs that we started. Here the technology is agreed, we just need to turn the handle to get the RFCs done. The burdon here falls on the individual authors and WG chairs. 2) New PW types - this is essentially sustaining engineering that will continue for some time. 3) Management (OAM and MIBs). This needs to get some attention. 4) Multi-segment PWs, which is new work. This seems a reasonable work programme. - Stewart Loa Andersson wrote: > All, > > I've one immediate reaction reading the charter - this is > quite a bit of work too take on. is it the intention that we > should do all this is one go? Wouldn't be better to focus? > > /Loa > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 08:30:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOZV-0006iS-6y; Tue, 26 Jul 2005 08:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOZR-0006iM-GQ for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 08:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12591 for ; Tue, 26 Jul 2005 08:30:04 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxP4T-0001tw-Ri for pwe3@ietf.org; Tue, 26 Jul 2005 09:02:11 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j6QCLJU09942 for ; Tue, 26 Jul 2005 14:21:19 +0200 Received: from [127.0.0.1] ([172.16.2.192]) by mail1.imc.kth.se; Tue, 26 Jul 2005 14:27:08 +0200 Message-ID: <42E62C1A.6040706@pi.se> Date: Tue, 26 Jul 2005 14:27:06 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Bryant Subject: Re: [PWE3] Draft Charter References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> <42E6217C.5070007@cisco.com> In-Reply-To: <42E6217C.5070007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Stewart, there are at least two things in the charter not covered in this list, the security diffrences between native wires and PWs, possibly quite a bit of work; and the congestions mechansisms, that also could quite a bit of work. Also I guess that "some attention" on MIBs and OAM is to put it mildly, the experiences from the mpls wg group was that it was a major effort (still to be completed). /Loa Stewart Bryant wrote: > There are four core elements to the charter: > > 1) Finishing the work on simple pt-pt PWs that we started. > Here the technology is agreed, we just need to turn the > handle to get the RFCs done. The burdon here falls > on the individual authors and WG chairs. > > 2) New PW types - this is essentially sustaining engineering > that will continue for some time. > > 3) Management (OAM and MIBs). This needs to get some attention. > > 4) Multi-segment PWs, which is new work. > > This seems a reasonable work programme. > > - Stewart > > > Loa Andersson wrote: > >> All, >> >> I've one immediate reaction reading the charter - this is >> quite a bit of work too take on. is it the intention that we >> should do all this is one go? Wouldn't be better to focus? >> >> /Loa >> > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 08:38:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOhb-0007wK-7y; Tue, 26 Jul 2005 08:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOhZ-0007wB-A9 for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 08:38:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13296 for ; Tue, 26 Jul 2005 08:38:28 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPCb-0002BP-Nr for pwe3@ietf.org; Tue, 26 Jul 2005 09:10:35 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j6QCThU10193 for ; Tue, 26 Jul 2005 14:29:43 +0200 Received: from [127.0.0.1] ([172.16.2.192]) by mail1.imc.kth.se; Tue, 26 Jul 2005 14:35:34 +0200 Message-ID: <42E62E15.708@pi.se> Date: Tue, 26 Jul 2005 14:35:33 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> In-Reply-To: <42E6156D.3020808@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org The current proposal for the pwe3 charter says: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS based packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. I would like to change this to: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. This is to clearly say that mpls is part of the IP protocol suite. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 08:49:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOrv-00039P-EB; Tue, 26 Jul 2005 08:49:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOro-00039K-KL for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 08:49:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14225 for ; Tue, 26 Jul 2005 08:49:01 -0400 (EDT) Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPMm-0002Z1-Jm for pwe3@ietf.org; Tue, 26 Jul 2005 09:21:08 -0400 Received: from dgismtp02.mcilink.com ([166.38.58.142]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0IK800L3LJL9ET@firewall.mci.com> for pwe3@ietf.org; Tue, 26 Jul 2005 12:48:45 +0000 (GMT) Received: from dgismtp02.mcilink.com by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0IK800201JL9BI@dgismtp02.mcilink.com> for pwe3@ietf.org; Tue, 26 Jul 2005 12:48:45 +0000 (GMT) Received: from XS344V8061891 ([153.39.146.243]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0IK80021KJL8BA@dgismtp02.mcilink.com> for pwe3@ietf.org; Tue, 26 Jul 2005 12:48:45 +0000 (GMT) Date: Tue, 26 Jul 2005 08:48:42 -0400 From: David McDysan Subject: Comments on [PWE3] I-D ACTION:draft-ietf-pwe3-ms-pw-requirements-00.txt To: Pwe3 Message-id: <0IK80021LJL9BA@dgismtp02.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcWR4FlG4yVj9EJuSDSbfkzrFSjnJw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org I propose the following changes to make certain points in the requirements draft clearer and more precise. Also, some discussion on the list was not reflected in this version and I make some specific suggestions on how to include these points in this WG document. I have grouped my comments below into major/technical and minor/editorial sections. I suggest that if you wish to start a thread on a particular topic that you change the subject line so that it will be easier for the editors to track and document WG consensus. Thanks, Dave Major/Technical comments ======================== 4. Terminology 5. Use Cases vi Pseudo-Wires in Access and Metro Networks On 2/9/05, I suggested adding a sentence stating that the topology that connects a U-PE access metro device to an S-PE metro aggregation may be simple (e.g., single homed from a packet routing perspective) and that restoration may be handled at lower layers (e.g., SONET/SDH protection). Nabil agreed, but pointed out that the case where a U-PE is dual homed to two S-PEs using a primary/backup MS-PW is also possible in this use case. I request that the editors add these two cases of U-PE to S-PE resiliency to this use case. 6.1 Architecture i S-PEs MAY only support switching PWs of the same PW type. In this case, the PW type is transparent to the S-PE in the forwarding plane, except for functions needed to provide for interworking between different PSN technologies. The above is inconsistent with the description below Figure 2 "This document requires support for MS-PWs with segments of the same type." In my opinion, protocol support for switching PW segements of the same type is mandatory and switching between different PW types is optional. Suggest changing "MAY" to "MUST" in the above to address this comment. Requirement v describes interworking of PW types. Are the following requirements different ways of stating the same thing? I think that the wording of iii is clearer and suggest deletion of ii, or at least further clarification of ii is needed. -ii. If MS-PWs are tunneled, using a PSN tunnel overlay, across a PSN that only supports SS-PWs, then only the requirements of [PWE3-REQ] apply to that PSN. The fact that the overlay is carrying MS-PWs MUST be transparent to the routers in the PSN. -iii. The PWs MUST remain transparent to the P-routers. A P-router is not an S-PE or an U-PE from the MS-PW architecture viewpoint. P-routers provide transparent PSN transport for PWs and MUST not have any knowledge of PW traversing them. I raised the following point on 3/9/05 on the list as well as in the Minneapolis meeting regarding the following requirement: -vii. MS-PWs are composed of SS-PW, and SS-PW are bi-directional, therefore both directions of a PW segment MUST terminate on the same S-PE/U-PE." This requirement can be read in at least the following two ways: 1) both directions of every PW segment must terminate on the same S-PE to S-PE AND on the same S-PE connected to a U-PE at each end of the pseudowire 2) both directions of a PW segment must terminate on the same S-PE connected to a U-PE at each end of the set of PW segements that comprise the MS-PW. I propose that the requirement be clarified to state that the first case is mandatory, since this is what several people have told me is the intent. Also, several people indicated that there are OAM advantages to this approach (e.g., having a return channel that traverses the same set of S-PEs), which I suggest should be mentioned in the document. I had described on 3/9/05, cases where the above scenarios would be suboptimal than an approach that did not impose such restrictions and would like to get feedback from the list as to whether an option for routing that does not force traversal of the same set of S-PEs in each direction such that higher utilization results is of interest. It does open the door to a more general architectural discussion that I recall at least Neil Harrison and Yakov Stein have mentioned where making protocols stackable with functions useable in an recursive manner is possible. There is an asymmetry in the current PW and MPLS protocol design in that MPLS LSPs are simplex, while PWs are duplex. A symmetric architecture would require duplex MPLS LSPs and simplex PWs. In my opinion, such a discussion is relevant to PWE3, but also relevant to at least MPLS. 6.2 Resiliency -i. The ability to configure an end-end backup PW path for a primary PW path MUST be supported. The backup and primary paths should have the ability to traverse separate S-PEs. The backup path MAY be signaled at configuration time or after failure detection. The last sentence is not optional, as use of the word MAY implies. I believe what is intended is "The backup path SHALL be signaled at configuration time or after failure detection." Also, an additional clarification is that at configuration time the backup path cannot be selected before the primary path has been selected. I think there is also a requiremnent for the case where if a S-PE diverse backup path cannot be found at configuration time, then the protocol shall provide a means to indicate this to the configuring entity. -iii. When a MS-PW segment is tunneled over PSN tunnels with fast reroute capability fast re-route events SHOULD be transparent to the MS-PW. I'm not clear as to what "transparent" means in this context. I expect there would be momentary loss as well as a potential change in latency in response to an (MPLS?) fast re-route event. Also, if the (MPLS or IP)PSN tunnel changed or re-optimized, momentary loss and a change in latency could result. Certainly these phenomena are not transparent to the PW. If some other behavior(s) is to be transparent, then this should be clarified. -iv. Automatic Mechanisms to perform a fast switchover from a primary PW to a backup PW upon failure detection SHOULD be provided to minimize packet loss. I think this works only if the backup path is pre-established, and suggest adding this condition to the requirement. Note that requirement i allows the backup path to be signaled after failure detection. 6.3 Quality of Service and Class of Service There was a fair amount of discussion on this topic on the list in January through April, but the only change was made to requirement ii, unrelated to that discussion. -ii. A method to select per PW/QoS class setup/holding priority should be provided. I suggest that the editors expand the above text and give an example, since I can interpret the above text in more than one way (e.g., is the setup/holding priority per PW, or per QoS class, or both?) Following is a summary of the points discussed and a proposed resolution based upon the proposal from Richard Spencer with my comments from 4/28/05: Replace 6.3 i with the following - The MS-PW signalling protocol must support the option to carry traffic parameters that allow an S-PE or U-PE perform admission control and/or dynamically configure per MS-PW traffic conditioning mechanisms (e.g., policers, shapers). The parameters controlling admission control decisions or dynamic configuration of traffic conditioning mechanisms MUST be configurable. Replace 6.3.1 i with the following: - The MS-PW signalling protocol MUST carry enough information for a S-PEs to be able to select the appropriate PSN tunnel, (e.g., EXP field for MPLS, DSCP for IP) corresponding to the requested QoS class. S-PEs SHOULD ensure that only packets with the signaled markings are forwarded. I think that 6.3.1 ii is redundant with the proposed rewording of 6.3.1 i and recommend that it be deleted. Section 6.3 iii. Suggest splitting this into two requirements as follows: iii. In case the PSN tunnel lacks the resources necessary to accommodate the new PW, a PW setup failure message MUST be returned and the PW MUST fail to setup. iiia In case the PSN tunnel lacks the resources necessary to accommodate the new PW, an S-PE or U-PE SHOULD attempt to signal an new PSN tunnel, or increase the capacity of the existing PSN tunnel. If the expanded PSN tunnels fails to setup the PW MUST fail to setup. The current wording is inconsistent in that the fail if no resource is available and the alternative of attempt to increase tunnel capacity are both "MUST." I think that a proposal that Eric Rosen made on 4/7/05 should be added to section 6.3, with my rewording to requirements style language proposed below: - The QoS processing at an S-PE SHOULD be done using standard PSN tunnel (e.g., MPLS) switching, queuing and traffic conditioning procedures, which have no knowledge that they are functioning in an S-PE context. Section 6.4 MS-PW Setup Mechanism There has been a lot of discussion on the list of four protocols. Suggest adding a statement that the addition of one or more other protocols for MS-PW setup is not precluded to address this comment, otherwise the requirements document is dictating the set of possible solutions. There was a fair amount of discussion on the list regarding the need for the protocol to support IP addresses as well as some other identifier. Suggest breaking v into two parts to state these requirements more clearly. v. The MS-PW signaling protocol MUST support addressing U-PEs and S-PEs using IP addresses. This applies to use cases where reachability to the IP address of the U-PEs and S-PEs are known across potential domains of the MS-PW. v'. In cases where the IP addresses of the U-PE and S-PE are no known across potential domains of the MS-PW (e.g., security and confidentiality policies prevent advertising IP reachability), procedures MUST be provided to allow dynamic setup of MS-PWs using some other identifier. I am not clear as to what is intended by the following requirement: -vi. Addressing of MS-PW end point at the U-PE MUST be independent of the IP address of the U-PEs themselves. If it means precluding the SS-PW use of IP address and PWid/GFEC for MS-PW signaling, then I disagree with this requirement. I think that reworded requirement v' handles this case for using non-IP identifiers to identify (U-PE) endpoints. Section 6.4.1 Routing There was some discussion on the list in Jan/Feb 2005 regarding automatic discovery of the S-PEs that are candidates for an MS-PW. Suggest that there should be a requirement that states that automatic discovery of S-PEs is desirable. Section 8. Security Considerations This appears to be completely new text, not yet reviewed by the working group. Below are some initial comments. I think that MS-PW also creates some additional security considerations for intra-provider use cases, with details listed below. If these detailed comments are accepted, then the summary statement that MS-PW intra-provider security is equivalent to SS-PW security needs to be changed. I note that these control protocol security requirements appear to apply only to IP addressing. 8.1. Data-plane Security Requirements First paragraph. Suggest stating that an S-PE is the point of an MS-PW "crossconnect" (this is the first use of this undefined term in the document) and that this is where injection (also suggest adding intercept) could occur. Note that this case of S-PE injection/intercept can occur in both intra- or inter-provider use case. Second paragraph. "Eavesdropping" (suggest use of "intercept" instead) or "hijacking" (suggest "redirecting" instead) could occur at an S-PE in both intra- or inter-provider use cases. Also, an OAM continuity check style mechanism may be able to detect redirection (hijacking) and suggest that this possibility be added to the text. Third paragraph. I think that policing is already covered in the QoS section. There is an issue of how to set the burst duration parameters of a policer or implementing per-PW shaping such that packet clumping that could occur does not result in some packets being declared non conformant at the receiving S-PE that needs to be addressed in the document (but not in the security section). Suggest that enabling policing (and shaping) be described as a function that occurs via bialateral agreement in the inter-provider use case. I believe that if the "security" concern is an interface overload DoS style attack, then ingress policing on the S-PE at the inter-provider boundary does not address this problem. Fourth paragraph. I think that QoS treatment in terms of only allowing the signaled QoS markings belongs in the QoS section, not the security section. I believe that my proposed rewording of 6.3.1 i in the QoS section covers this case. Fifth paragraph. Defining label space does not seem to be a security requirement. It would seem to fit better in section 6.4. 8.2. Control-plane Security Requirements First paragraph. The problem being described here is unclear. Suggest that the second sentence be reworded as follows: "It is important to make sure that PW connections are not accepted only from an authenticated U-PEs,or else a local attachment circuit might get connected to an incorrect remote attachment circuit." Second paragraph. Suggest stating that the entities "peering" are U-PE and S-PE. I can (mis?)interpret the text such that each U-PE and S-PE must be configured with the list of all possible remote U-PE addresses (or prefixes). I believe this is not a scalable solution. Another interpretation is that such "peer" adress filtering is only for the signaling entities. This would be more scalable. Suggest last sentence be reworded as follows: "The S-PE and U-PE SHOULD drop any signaling messages that do not have an IP address of a know MS-PW signaling peer to avoid a DoS attack on the control plane." If routing is used for autodiscovery, then similar requirements apply to routing protocol sessions. Third paragraph. Suggest that scope is not only "connection request" messages, but all control messages (signaling and routing). Suggest clarification that source address filtering will block packets with addresses of U-PE or S-PE from entering the target domain. Fourth paragraph. Please clarify the following "Furthermore authentication using a signature for each indifidual MS-PW setup messages MUST be available, in addition to an overall control protocol session authentication , and message validation." Does this apply to release and status messages as well? Note that doing this level of authentication creates a DoS vector on U-PE or S-PE processing resources such that an attacker can send a large number of messages with invalid session as well as MS-PW authentication values. Fifth paragraph. I don't believe misconfiguration is a security issue (it can also occur in an inter-provider context). If static manual configuration protocols are not secured, then this would be less secure than a dynamically signaled case where the signaling protocol exchanges are authenticated. Suggest that the specific mechanism of a central server is not a requirement. The means for end points being able to authenticate the endpoints is an important security requirement. A requirement should not state the form of a centralized solution, but should state the funciton needed. A distributed mechanism could send a digest as part of a SAII/TAII encoding. Sixth paragraph. Good requirements. Suggest giving an example for the last sentence (e.g., a TCP SYN attack if LDP is used). Minor, Editorial Points ======================= Suggest the title be "Multi-segment" instead of "Inter-Domain" Pseudo-wires to align better with terminology in document. Text below Figure 2: Suggest using "PSN domain" instead of PSN to align with earlier domain level terminology. Section 6.2 Resiliency, requirement ii seems to be unecessary since the same points are made in requirement i. Section 6.2 Resiliency, requirement vii would seem to be better placed in section 7, OAM. (It appears to be a duplicate of requirements vi and viii in that section). Section 6.3, delete "Class of Service" from section title - the term is never used in the document. Suggest use of only "Quality of Service" and add acronym "(QoS)" in section title. Section 6.4.1, vi Suggest replacing "1:1" with primary/backup to have consistent terminology. > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, June 16, 2005 3:50 PM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-ms-pw-requirements-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Pseudo Wire Emulation Edge to Edge > Working Group of the IETF. > > Title : Requirements for inter domain Pseudo-Wires > Author(s) : L. Martini, et al. > Filename : draft-ietf-pwe3-ms-pw-requirements-00.txt > Pages : 20 > Date : 2005-6-16 > > This document describes the necessary requirements to allow a > service > provider to extend the reach of pseudo-wires 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 > service providers, or administratively established pseudo-wire > domains. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-00.tx t > > 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-00.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-00.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 From pwe3-bounces@ietf.org Tue Jul 26 08:55:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOxb-0004gQ-0E; Tue, 26 Jul 2005 08:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOxT-0004gB-NY for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 08:54:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14539 for ; Tue, 26 Jul 2005 08:54:54 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPSX-0002ig-8c for pwe3@ietf.org; Tue, 26 Jul 2005 09:27:01 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j6QCkAU10475 for ; Tue, 26 Jul 2005 14:46:10 +0200 Received: from [127.0.0.1] ([172.16.2.192]) by mail1.imc.kth.se; Tue, 26 Jul 2005 14:51:51 +0200 Message-ID: <42E631E5.6070708@pi.se> Date: Tue, 26 Jul 2005 14:51:49 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson Subject: Re: [PWE3] Draft Charter transport etc. References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> In-Reply-To: <42E6156D.3020808@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Second paragraph of the proposed charter says: "Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF specified PSNs." While I have a farily good idea what goes into encapsulation and management, and understand the need for security. I've issues with transport, control and interworking. Do we use "trasnport" here as it used in e.g. "transport area" or do we intend to talk about the technology over which the the PW is "transported". If it is the latter what needs to be specified? Control normally comprises signalling and routing protocols, should these be specified by the pwe3 wg or by the wg that "owns the protocol"? Shouldn't we say that we need to develop requirements on signaling and routing prtocol extensions. Interworking - I assume that this interworking where boths attachment circuits carry IP packets? If so how much of this is addressed by the L2VPN wg and the IPLS? In the best of worlds the PWs need not to bother about interworking at all. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 08:59:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP2F-00058L-Ks; Tue, 26 Jul 2005 08:59:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP2D-00057z-N1 for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 08:59:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14912 for ; Tue, 26 Jul 2005 08:59:44 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPXC-0002uE-8g for pwe3@ietf.org; Tue, 26 Jul 2005 09:31:52 -0400 Received: from [205.168.100.50] (unknown [10.0.12.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 81D8D142B3 for ; Tue, 26 Jul 2005 08:59:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42E62E15.708@pi.se> References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> <42E62E15.708@pi.se> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <774aafbf2cca5cc6c4f15fb8e2b1f21e@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks Date: Tue, 26 Jul 2005 06:59:06 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 26, 2005, at 6:35 AM, Loa Andersson wrote: > The current proposal for the pwe3 charter says: > > Network transport service providers and their users are > seeking to rationalize their networks by migrating their > existing services and platforms onto IP or MPLS based > packet switched networks (PSN). This migration requires > communications services that can emulate the essential > properties of traditional communications links over a > PSN. > > I would like to change this to: > > Network transport service providers and their users are > seeking to rationalize their networks by migrating their > existing services and platforms onto IP or MPLS enabled > IP networks (PSN). This migration requires > communications services that can emulate the essential > properties of traditional communications links over a > PSN. > > This is to clearly say that mpls is part of the IP protocol > suite. I've already changed this paragraph twice and considering it's simply meant to be introductory/background text I'm not all that keen on changing it again. I believe it's implied that these mechanisms are enabled by an "IP protocol suite", of which MPLS is a component. With that said, do other folks have thoughts on Loa's recommendation? If so, I can fold it into the next revision. Thanks for the review Loa! -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 09:01:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP4A-0005WL-4D; Tue, 26 Jul 2005 09:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP46-0005W9-Bj for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 09:01:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15142 for ; Tue, 26 Jul 2005 09:01:44 -0400 (EDT) From: benjamin.niven-jenkins@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPZ9-0002zu-1A for pwe3@ietf.org; Tue, 26 Jul 2005 09:33:52 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 14:01:27 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Jul 2005 14:00:51 +0100 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Draft Charter - IP and MPLS enabled IP networks Date: Tue, 26 Jul 2005 14:01:44 +0100 Message-ID: Thread-Topic: [PWE3] Draft Charter - IP and MPLS enabled IP networks Thread-Index: AcWR3xv6CkEzUQqYTBWV0CmC9vVvwQAAc4dA To: X-OriginalArrivalTime: 26 Jul 2005 13:00:51.0140 (UTC) FILETIME=[0CAFA040:01C591E2] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Loa, Colleagues, > I would like to change this to: >=20 > Network transport service providers and their users are > seeking to rationalize their networks by migrating their=20 > existing services and platforms onto IP or MPLS enabled IP=20 > networks (PSN). This migration requires communications=20 > services that can emulate the essential properties of=20 > traditional communications links over a PSN. >=20 > This is to clearly say that mpls is part of the IP protocol suite. I am not sure I know what MPLS enabled IP networks means. My understanding is that MPLS is a data forwarding mechanism that is controlled by a suite of IP protocols. It is possible to have MPLS data forwarding without any IP data forwarding in the 'user plane'. MPLS enabled IP networks implies to me a network with IP forwarding in the 'user plane' that simultaneously supports MPLS forwarding in the 'user plane' as well, almost as though MPLS forwarding is a 'bolt on' to IP forwarding and is unable to exist on its own separately from IP forwarding - this is certainly one scenario but not IMO the only scenario. I can forsee a future in which a co-ps data forwarding network (which may or may not be MPLS) is controlled by a cl-ps control plane (which may or may not be IP), e.g. G.motnni & the work of WG7 in ITU-T FGNGN), but this is not IMO captured by the statement 'MPLS enabled IP network'. Now, playing Devil's Advocate - Why do we need to 'clearly say that MPLS is part of the IP protocol suite'? What do we gain from such a statement, what ambiguity does it alleviate? Ben _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 09:05:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP7x-0006co-I1; Tue, 26 Jul 2005 09:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP7s-0006cC-DN for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 09:05:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15772 for ; Tue, 26 Jul 2005 09:05:39 -0400 (EDT) Received: from corfw.corrigent.com ([213.31.203.2] helo=tlvmail1.corrigent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPcv-0003F6-2V for pwe3@ietf.org; Tue, 26 Jul 2005 09:37:46 -0400 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2005 16:05:27 +0200 Message-ID: <13D5DF801DFEBE439353E0AAFE78541406CF0D@tlvmail1.corrigent.com> Thread-Topic: draft-roth-pwe3-fc-encap-00.txt Thread-Index: AcWRP5LCSDI+P0gHTI+WLJBGL0swDgAoU4FA From: "Moran Roth" To: "Stewart Bryant" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: [PWE3] RE: draft-roth-pwe3-fc-encap-00.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Stewart, Thanks a lot for your comments. Please see inline. Moran > Some comments on draft-roth-pwe3-fc-encap-00.txt >=20 > - Stewart >=20 >=20 > 4. Encapsulation >=20 > This specification provides port to port transport of FC encapsulated > traffic. The following FC connections are supported over the MPLS > network: > - N-Port to N-Port > - N-Port to F-Port > - E-Port to E-Port >=20 > SB> Where are these types defined? =20 [MR] The FC port types are defined in FC-FS-2 standard by the T11 technical committee. * N-Port is a (end-)node port, server or disk. * F-Port is a fabric-element (switch) port facing a n-port. * E-Port is an extension port of a switch to interface between switches. =20 > 4.1. The Control Word >=20 > The Generic PW control word, as defined in "PWE3 Control Word" [PW- > CW] MAY be used for FC PW. The structure of the control word is as > follows: >=20 > SB> Do you mean MAY or MUST. =20 [MR] I think that MAY is more appropriate, since there is no CW field that is mandatory in this encapsulation. =20 > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0|0 0 0 0|FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 3 - Control Word structure for the one-to-one mapping mode >=20 > The Flags bits are not used for FC. These bits MUST be set to 0 by > the ingress PE, and MUST be ignored by the egress PE. >=20 > The FRG bits are used for PW PDU fragmentation as described in [PW- > CW] and [FRAG]. >=20 > The length field can be used to remove any padding added by the PSN. > Its processing must follow the rules defined in [PW-CW]. >=20 > The use of the sequence number is optional, and the processing must > follow the rules as in [PW-CW]. >=20 > SB> No, you have to describe the rules here. =20 [MR] I'll add it in the next revision of the draft. =20 =20 > 4.2. MTU Requirements >=20 > The network MUST be configured with an MTU that is sufficient to > transport the largest encapsulation frames. >=20 > SB> So you don't need frag you can say that the bits MUST be 00 >=20 > When MPLS is used as the > tunneling protocol, for example, this is likely to be 12 or more > bytes greater than the largest frame size. The methodology described > in [FRAG] MAY be used to fragment encapsulated frames that exceed the > PSN MTU. However if [FRAG] is not used then if the ingress router > determines that an encapsulated layer 2 PDU exceeds the MTU of the > PSN tunnel through which it must be sent, the PDU MUST be dropped. >=20 > SB> But now you say can use frag. Did you meant to say SHOULD above? =20 [MR] SHOULD is more appropriate. In the next revision I'll clarify the text to=20 state that if FRAG is used the MTU may be set to the fragment size. If FRAG is not used the MTU MUST be configured with an MTU that is=20 sufficient to transport the largest encapsulation frames. =20 > 5. Security Considerations >=20 > This document specifies only encapsulations, and not the protocols > used to carry the encapsulated packets across the PSN. Each such > protocol may have its own set of security issues [PW-MPLS] [RFC3985], > but those issues are not affected by the encapsulations specified > herein. Note that the security of the emulated service will only be > as good as the security of the PSN. >=20 >=20 > SB> Aren't FC apps a bit more sensitive to security than most apps? > SB> > SB> I think that you should consider writing an applicability section I=20 > SB> would imagine that FC has quite stringent requirements on delay=20 > SB> misordering latency etc. Would you consider it suitable for ruuning=20 > SB> over the pblic Internet? [MR] In general the requirement that we saw is for adding a new type of=20 service over a network owned by a network operator, hence it does not refer to the public internet. This will be detailed in an=20 applicability section I'll add to the next revision. =20 > 6. IANA considerations >=20 > A new PW type, named "FC Port Mode" is requested from IANA. The next > available value of 0x0021 is requested. [MR] Accepted. =20 > SB> The next available is 1F. But I don't think that you should quote a=20 > SB> value. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 09:08:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPAG-0008CM-2H; Tue, 26 Jul 2005 09:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPAD-0008Au-Pf for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 09:08:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16146 for ; Tue, 26 Jul 2005 09:08:04 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPfH-0003Ok-Cp for pwe3@ietf.org; Tue, 26 Jul 2005 09:40:11 -0400 Received: from [205.168.100.50] (unknown [10.0.12.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 3CD3E1428A for ; Tue, 26 Jul 2005 09:08:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42E631E5.6070708@pi.se> References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> <42E631E5.6070708@pi.se> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <98348c48ea0b077b09f250703b436b95@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter transport etc. Date: Tue, 26 Jul 2005 07:07:59 -0600 To: pwe3 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 26, 2005, at 6:51 AM, Loa Andersson wrote: > Second paragraph of the proposed charter says: > > "Pseudowire Emulation Edge to Edge (PWE3) will specify the > encapsulation, transport, control, management, interworking and > security of services emulated over IETF specified PSNs." > > While I have a farily good idea what goes into encapsulation > and management, and understand the need for security. I've > issues with transport, control and interworking. > > Do we use "trasnport" here as it used in e.g. "transport area" Nah, else I'd have use a capital 't' as in Transport :-) > or do we intend to talk about the technology over which the the > PW is "transported". If it is the latter what needs to be specified? I thought "transport" seemed sufficient. Would you prefer "carriage" or something akin? > Control normally comprises signalling and routing protocols, should > these be specified by the pwe3 wg or by the wg that "owns the > protocol"? Shouldn't we say that we need to develop requirements > on signaling and routing prtocol extensions. All the control functions we provide to date were "extended" in PWE3, and as much as the PWE3 architecture permits, this is likely to remain the path going forward - as you well know. However, working with other working groups where necessarily is of course required. > Interworking - I assume that this interworking where boths attachment > circuits carry IP packets? If so how much of this is addressed by > the L2VPN wg and the IPLS? In the best of worlds the PWs need not to > bother about interworking at all. That demarcation is just what needs to be defined, and PWE3 and L2VPN need to work together to get there.. -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 09:49:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPo2-00025a-Kq; Tue, 26 Jul 2005 09:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPo0-00025P-QW for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 09:49:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18772 for ; Tue, 26 Jul 2005 09:49:11 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQJ2-0004kK-Cy for pwe3@ietf.org; Tue, 26 Jul 2005 10:21:19 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j6QDePU11761 for ; Tue, 26 Jul 2005 15:40:25 +0200 Received: from [127.0.0.1] ([172.16.2.192]) by mail1.imc.kth.se; Tue, 26 Jul 2005 15:46:31 +0200 Message-ID: <42E63EB5.1020202@pi.se> Date: Tue, 26 Jul 2005 15:46:29 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny McPherson Subject: Re: [PWE3] Draft Charter transport etc. References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> <42E631E5.6070708@pi.se> <98348c48ea0b077b09f250703b436b95@tcb.net> In-Reply-To: <98348c48ea0b077b09f250703b436b95@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org >> or do we intend to talk about the technology over which the the >> PW is "transported". If it is the latter what needs to be specified? > > > I thought "transport" seemed sufficient. Would you prefer > "carriage" or something akin? nope - understood that way "transport" is fine, more curious on what needs to be specified? /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 13:01:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSoS-0005mA-MF; Tue, 26 Jul 2005 13:01:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSoR-0005m5-D3 for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 13:01:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05853 for ; Tue, 26 Jul 2005 13:01:48 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTJV-00039j-SH for pwe3@ietf.org; Tue, 26 Jul 2005 13:33:59 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2005 13:01:39 -0400 X-IronPort-AV: i="3.95,144,1120449600"; d="scan'208"; a="63996754:sNHT27420764" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j6QH1ak6004945; Tue, 26 Jul 2005 13:01:38 -0400 (EDT) Message-ID: <42E66C70.2010308@cisco.com> Date: Tue, 26 Jul 2005 11:01:36 -0600 From: Luca Martini User-Agent: Mail/News Client 1.0+ (X11/20050603) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> <42E62E15.708@pi.se> <774aafbf2cca5cc6c4f15fb8e2b1f21e@tcb.net> In-Reply-To: <774aafbf2cca5cc6c4f15fb8e2b1f21e@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Danny McPherson wrote: > On Jul 26, 2005, at 6:35 AM, Loa Andersson wrote: > >> The current proposal for the pwe3 charter says: >> >> Network transport service providers and their users are >> seeking to rationalize their networks by migrating their >> existing services and platforms onto IP or MPLS based >> packet switched networks (PSN). This migration requires >> communications services that can emulate the essential >> properties of traditional communications links over a >> PSN. >> >> I would like to change this to: >> >> Network transport service providers and their users are >> seeking to rationalize their networks by migrating their >> existing services and platforms onto IP or MPLS enabled >> IP networks (PSN). This migration requires >> communications services that can emulate the essential >> properties of traditional communications links over a >> PSN. >> >> This is to clearly say that mpls is part of the IP protocol >> suite. > > > I've already changed this paragraph twice and considering > it's simply meant to be introductory/background text I'm > not all that keen on changing it again. I believe it's > implied that these mechanisms are enabled by an "IP > protocol suite", of which MPLS is a component. > > With that said, do other folks have thoughts on Loa's > recommendation? If so, I can fold it into the next > revision. > I think that the "MPLS enabled IP networks" text fits in with the stile we put in the pwe3 control protocol draft. It might make things more consistent.. Luca > Thanks for the review Loa! > > -danny > > > _______________________________________________ > 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 Jul 26 13:09:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSvy-0000uP-TX; Tue, 26 Jul 2005 13:09:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSvx-0000uK-UC for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 13:09:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06683 for ; Tue, 26 Jul 2005 13:09:34 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTR2-0003SY-Og for pwe3@ietf.org; Tue, 26 Jul 2005 13:41:46 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2005 13:09:28 -0400 X-IronPort-AV: i="3.95,144,1120449600"; d="scan'208"; a="63998216:sNHT28396804" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j6QH9Ok6006973; Tue, 26 Jul 2005 13:09:25 -0400 (EDT) Message-ID: <42E66E43.1020901@cisco.com> Date: Tue, 26 Jul 2005 11:09:23 -0600 From: Luca Martini User-Agent: Mail/News Client 1.0+ (X11/20050603) MIME-Version: 1.0 To: Loa Andersson Subject: Re: [PWE3] Draft Charter References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> <42E6217C.5070007@cisco.com> <42E62C1A.6040706@pi.se> In-Reply-To: <42E62C1A.6040706@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Danny McPherson , 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Loa Andersson wrote: > Stewart, > > there are at least two things in the charter not covered in > this list, the security diffrences between native wires and > PWs, possibly quite a bit of work; and the congestions mechansisms, > that also could quite a bit of work. > Actually there seems to be little or no interest to work on congestion mechanisms in this WG. Since this WG does not deal with applications , it is quite difficult to build a congestion mechanism that will work properly. Luca > Also I guess that "some attention" on MIBs and OAM is to put > it mildly, the experiences from the mpls wg group was that it > was a major effort (still to be completed). > > /Loa > > Stewart Bryant wrote: > >> There are four core elements to the charter: >> >> 1) Finishing the work on simple pt-pt PWs that we started. >> Here the technology is agreed, we just need to turn the >> handle to get the RFCs done. The burdon here falls >> on the individual authors and WG chairs. >> >> 2) New PW types - this is essentially sustaining engineering >> that will continue for some time. >> >> 3) Management (OAM and MIBs). This needs to get some attention. >> >> 4) Multi-segment PWs, which is new work. >> >> This seems a reasonable work programme. >> >> - Stewart >> >> >> Loa Andersson wrote: >> >>> All, >>> >>> I've one immediate reaction reading the charter - this is >>> quite a bit of work too take on. is it the intention that we >>> should do all this is one go? Wouldn't be better to focus? >>> >>> /Loa >>> >> > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 13:12:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSys-0001x0-Sk; Tue, 26 Jul 2005 13:12:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3BB-0006U1-Mz for pwe3@megatron.ietf.org; Mon, 25 Jul 2005 09:39:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20150 for ; Mon, 25 Jul 2005 09:39:36 -0400 (EDT) From: Jean-Loup.Ferrant@alcatel.fr Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx3g0-0002kE-RX for pwe3@ietf.org; Mon, 25 Jul 2005 10:11:31 -0400 Received: from frmail19.netfr.alcatel.fr (frmail19.netfr.alcatel.fr [155.132.251.19]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j6PDd2re006953; Mon, 25 Jul 2005 15:39:27 +0200 In-Reply-To: To: Tim.Frost@Zarlink.Com X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Mon, 25 Jul 2005 15:39:08 +0200 X-MIMETrack: Serialize by Router on FRMAIL19/FR/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 07/25/2005 15:39:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 1.4 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-Mailman-Approved-At: Tue, 26 Jul 2005 13:12:37 -0400 Cc: Silvana.Rodrigues@Zarlink.Com, pwe3@ietf.org Subject: [PWE3] Re: comment on "draft-frost-pwe3-timing-pw-reqs-00.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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Hi Tim, May be you should simply write that the PW3 that transports the timing does not make use of the clock delivered by CE2 to PE2 in the PE2 equipment. Regards Jean-Loup Tim.Frost@Zarlin k.Com To: Jean-Loup FERRANT/FR/ALCATEL@ALCATEL cc: pwe3@ietf.org, Silvana.Rodrigues@Zarlink.Com 25/07/2005 15:30 Subject: Re: comment on "draft-frost-pwe3-timing-pw-reqs-00.txt" Hi Jean Loup, Thanks for the comment. Looking at it again, I think I can see how it might imply a timing loop, although this is not intended. I'll try and re-word it next time. I hope the revised figure 2 gives the idea better. Regards, Tim |<-------- Pseudo-wires -------->| | | | |<-- PSN Tunnel -->| | V V V V +-----+ AC +------+ +------+ AC +-----+ | CE1 | | | PE1 |==================| PE2 | | | CE2 | | |<---------|< ............PW1............. -|<---------|<- | | | | | | | | | | | | | | | ->|--------->|- ............PW2............. >|--------->| | | | | | | | | | | | | | | +-----+ | | | | +-----| ^ | | | | ^ |A | | | | G| +------------>| .............PW3.............. |-------------- | | |==================| | +-+ +------+ +------+ |L| +-+ Figure 2: Relationship to the CE Synchronized Scenario Jean-Loup.Ferrant@alcatel .fr To 25/07/2005 10:26 pwe3@ietf.org cc Silvana.Rodrigues@Zarlink.Com, Tim.Frost@Zarlink.Com Subject comment on "draft-frost-pwe3-timing-pw-reqs-00. txt" Dear sirs, I would like to address a comment on the following document: draft-frost-pwe3-timing-pw-reqs-00.txt In section 3 related to applications, the paragraph related to CE Synchronised Networks requires some clarification. It is explained that PE2 is loop timed to the AC input signal coming from CE2. As CE2 recovers its clock from the signal passing through PE2, this scenario seems to generate a timing loop situation between PE2 and CE2. I suggest that the text of this application scenario is modified to explain in more details how it works. Best regards Jean-Loup Ferrant NB: Sorry the previous mail had no title. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 13:19:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxT5N-0003mX-3n; Tue, 26 Jul 2005 13:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxT5L-0003mN-3A for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 13:19:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07461 for ; Tue, 26 Jul 2005 13:19:16 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTaQ-0003lU-7O for pwe3@ietf.org; Tue, 26 Jul 2005 13:51:27 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2005 10:19:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,144,1120460400"; d="scan'208"; a="3461683:sNHT20546740" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j6QHJ6Vu007359; Tue, 26 Jul 2005 13:19:07 -0400 (EDT) Message-ID: <42E6708A.4070606@cisco.com> Date: Tue, 26 Jul 2005 11:19:06 -0600 From: Luca Martini User-Agent: Mail/News Client 1.0+ (X11/20050603) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [PWE3] Draft Charter References: <84262ffba39c931d51d883c6b26df744@tcb.net> <0eaf01c58c72$7e666f90$d6849ed9@Puppy> <6.2.1.2.2.20050719111743.07512280@mail.comcast.net> <6cc94e0d1ac2453891604ca1cbab6d99@tcb.net> In-Reply-To: <6cc94e0d1ac2453891604ca1cbab6d99@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Danny McPherson wrote: > > On Jul 19, 2005, at 9:20 AM, Andrew G. Malis wrote: > >> And also add text to coordinate with other working groups that are >> extending the protocols owned by PWE3. A current example of this is >> the AVT working group, which is discussing >> draft-ash-avt-hc-over-mpls-protocol-01.txt. > > > While I fell as though we're reaching a bit, I've went ahead > and added the following [arguably gratuitous] text: > > "PWE3 will work closely with the L2VPN WG to ensure a clear > demarcation is defined for where PWE3 stops and L2VPN starts. > PWE3 will coordinate very closely with any WG that is > responsible for protocols which PWE3 intends to extend (e.g., > the MPLS WG for LDP), as well as foster interaction with WGs > that intend to extend PWE3 protocols." > Danny, I do not think that this is appropriate in a charter. Delineation of the scope of work should be done by the charter and should be clear ! Just stating that it the WG will work on it , does not define a delineation. We should state explicitly what areas are included , and ( if not clear ) what areas are excluded in this charter. More to follow ... Luca > -danny > > > _______________________________________________ > 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 Jul 26 13:24:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxT9s-0004gS-UF; Tue, 26 Jul 2005 13:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxT9r-0004gG-Lq for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 13:23:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07901 for ; Tue, 26 Jul 2005 13:23:56 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTew-0003wl-JV for pwe3@ietf.org; Tue, 26 Jul 2005 13:56:08 -0400 Received: from [205.168.100.50] (unknown [10.0.12.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 8F7381429E; Tue, 26 Jul 2005 13:23:34 -0400 (EDT) In-Reply-To: <42E6708A.4070606@cisco.com> References: <84262ffba39c931d51d883c6b26df744@tcb.net> <0eaf01c58c72$7e666f90$d6849ed9@Puppy> <6.2.1.2.2.20050719111743.07512280@mail.comcast.net> <6cc94e0d1ac2453891604ca1cbab6d99@tcb.net> <42E6708A.4070606@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9929eda7cb23851194ecca2e56804d02@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter Date: Tue, 26 Jul 2005 11:23:30 -0600 To: Luca Martini X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 26, 2005, at 11:19 AM, Luca Martini wrote: >> > Danny, > I do not think that this is appropriate in a charter. Delineation of > the scope of work should be done by the charter and should be clear ! > Just stating that it the WG will work on it , does not define a > delineation. > We should state explicitly what areas are included , and ( if not > clear ) what areas are excluded in this charter. Some of this is done in other places in the charter.. If you've got text about what you'd like to see in addition, please do send it along.. -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 13:28:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTDt-0005Ko-F1; Tue, 26 Jul 2005 13:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTDr-0005KS-4b for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 13:28:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08215 for ; Tue, 26 Jul 2005 13:28:04 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTiw-000462-Bw for pwe3@ietf.org; Tue, 26 Jul 2005 14:00:15 -0400 Received: from [205.168.100.50] (unknown [10.0.12.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id CFC11142AD; Tue, 26 Jul 2005 13:28:04 -0400 (EDT) In-Reply-To: <42E63EB5.1020202@pi.se> References: <13D5DF801DFEBE439353E0AAFE78541406CE8F@tlvmail1.corrigent.com> <39170c8225f602142cb536a5691ac7aa@tcb.net> <42E509C4.6060004@cisco.com> <42E6156D.3020808@pi.se> <42E631E5.6070708@pi.se> <98348c48ea0b077b09f250703b436b95@tcb.net> <42E63EB5.1020202@pi.se> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter transport etc. Date: Tue, 26 Jul 2005 11:28:00 -0600 To: Loa Andersson X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 26, 2005, at 7:46 AM, Loa Andersson wrote: >>> or do we intend to talk about the technology over which the the >>> PW is "transported". If it is the latter what needs to be specified? >> I thought "transport" seemed sufficient. Would you prefer >> "carriage" or something akin? > > nope - understood that way "transport" is fine, more curious > on what needs to be specified? It's mainly concerned with the "PW Service Functionality", as defined in the architecture document. Otherwise exerting control on the underlying PSN (be it IP or IP/MPLS) is explicitly out of scope, which I hope would satisfy any concerns you have here.. -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 13:34:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTKS-0000H6-LY; Tue, 26 Jul 2005 13:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTKR-0000Gy-HC for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 13:34:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08911 for ; Tue, 26 Jul 2005 13:34:52 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTpX-0004Mh-Dz for pwe3@ietf.org; Tue, 26 Jul 2005 14:07:03 -0400 Received: from [205.168.100.50] (unknown [10.0.12.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id A7AD11429E; Tue, 26 Jul 2005 13:34:53 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks Date: Tue, 26 Jul 2005 11:34:49 -0600 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org On Jul 26, 2005, at 7:06 AM, Dimitri.Papadimitriou@alcatel.be wrote: > danny - i agree on Loa's recommendation - OK folks, I've made the recommended changes.. The current draft revision of the charter is available here: http://pwe3.tcb.net/pwe3-charter-2005072601.txt and inline below.. -danny -------------------------- Pseudo Wire Emulation Edge to Edge (PWE3) WG Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF specified PSNs. A pseudowire emulates a point-to-point link, and provides a service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the two endpoints of the PW. PWE3 will investigate mechanisms necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and RTP will be used where appropriate. PWE3 will work closely with the L2VPN and L2TPEXT WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. WG Objectives (in order of priority): Specify the following PW types and consider specifying additional PW types contingent on WG consensus: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET. PWE3 may also specify a PW type which can be used for carrying a user's MPLS packets from one end of the PW to the other. In general, PWE3 will not specify mechanisms by which a PW may connect two different access services. However, PWE3 may specify such mechanisms for the special case where the access service payloads at both ends are known to consist entirely of IP packets. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. Specify OAM mechanisms for all PW types, suitable for operation over both IP and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Enhance packet-based PW specifications as necessary to allow the emulated service to be carried transparently over the PSN, for example by the retention of the FCS across the PW. Define mechanisms to permit the operation of a PW over a PSN that employs equal cost multiple path (ECMP) packet switching mechanism. A PW operating over a shared PSN does not have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define the requirements for and mechanisms needed to allow the operation of switched virtual circuits over a PSN. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jul 26 14:00:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTjb-0006FW-ES; Tue, 26 Jul 2005 14:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTjZ-0006FR-DM for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 14:00:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10617 for ; Tue, 26 Jul 2005 14:00:52 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUEd-00054y-KT for pwe3@ietf.org; Tue, 26 Jul 2005 14:33:02 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2005 11:00:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,144,1120460400"; d="scan'208"; a="3468513:sNHT23502628" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j6QI0aVu018440; Tue, 26 Jul 2005 14:00:40 -0400 (EDT) Message-ID: <42E67A41.5010707@cisco.com> Date: Tue, 26 Jul 2005 12:00:33 -0600 From: Luca Martini User-Agent: Mail/News Client 1.0+ (X11/20050603) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Cc: Dimitri.Papadimitriou@alcatel.be, 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Danny, Comments inline. Danny McPherson wrote: > > On Jul 26, 2005, at 7:06 AM, Dimitri.Papadimitriou@alcatel.be wrote: > >> danny - i agree on Loa's recommendation - > > > OK folks, I've made the recommended changes.. > > The current draft revision of the charter is available here: > > http://pwe3.tcb.net/pwe3-charter-2005072601.txt > > and inline below.. > > -danny > > -------------------------- > Pseudo Wire Emulation Edge to Edge (PWE3) WG > > Description of Working Group: > > Network transport service providers and their users are > seeking to rationalize their networks by migrating their > existing services and platforms onto IP or MPLS enabled > IP networks (PSN). This migration requires communications > services that can emulate the essential properties of > traditional communications links over a PSN. > > Pseudowire Emulation Edge to Edge (PWE3) will specify the > encapsulation, transport, control, management, interworking and > security of services emulated over IETF specified PSNs. > > A pseudowire emulates a point-to-point link, and provides a > service which is perceived by its user as an unshared link > or circuit of the chosen service. It is not intended that > an emulated service will be indistinguishable from the service > that is being emulated. The emulation need only be sufficient > for the satisfactory operation of the service. Emulation > necessarily involves a degree cost-performance trade-off. In > some cases it may be necessary to design more than one > emulation mechanism in order to resolve these design > conflicts. All emulated service definitions must include an > applicability statement describing the faithfulness of the > emulation. Switching, multiplexing, modification or other > operation on the traditional service, unless required as > part of the emulation, is out of the scope of the PWE3 WG. > > PWE3 will make use of existing IETF specified mechanisms > unless there are technical reasons why the existing mechanisms > are insufficient or unnecessary. > > PWE3 will not exert control on the underlying PSN, other than > to use any existing QoS or path control mechanism to provide > the required connectivity between the two endpoints of the PW. > > PWE3 will investigate mechanisms necessary to perform clock > recovery and other real-time signaling functions. This work will > be coordinated with the AVT WG and RTP will be used where > appropriate. > > PWE3 will work closely with the L2VPN and L2TPEXT WG to > ensure a clear demarcation is defined for where PWE3 stops > and L2VPN starts. PWE3 will coordinate very closely with > any WG that is responsible for protocols which PWE3 intends > to extend (e.g., the MPLS WG for LDP), as well as foster > interaction with WGs that intend to extend PWE3 protocols. > This statement need to be changed to either say : PWE3 will work closely with the L2VPN and L2TPEXT WG. PWE3 WG is not concerned with how PW are placed , or provisioned in a network, but only with the encapsulation and maintenance of the PWs. Or something along these lines ... The point is to draw the line , no just leave it open ended to the WG to fight over it . > WG Objectives (in order of priority): > > Specify the following PW types and consider specifying > additional PW types contingent on WG consensus: > No this is open ended. The WG could go on forever defining an infinite amount of PWs ... If the AD think that we need more then we should get a charter revision. By now you should know where this WG work needs to end. It should change to: Specify the following PW types: > Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET. > > PWE3 may also specify a PW type which can be used for > carrying a user's MPLS packets from one end of the PW to > the other. > > In general, PWE3 will not specify mechanisms by which a PW may > connect two different access services. However, PWE3 may specify > such mechanisms for the special case where the access service > payloads at both ends are known to consist entirely of IP packets. > excellent , this is much better then the previous version... > Specify the control and management functions of chartered PW > types, to include PW setup, configuration, maintenance and > tear-down. > This is fine with me , but in the initial charter "Setup" was taken to mean placement. So that would be the L2VPN WG job.. > Specify OAM mechanisms for all PW types, suitable for > operation over both IP and MPLS PSNs, and capable of > providing the necessary interworking with the OAM mechanisms > of the emulated service. > > Enhance packet-based PW specifications as necessary to allow > the emulated service to be carried transparently over the PSN, > for example by the retention of the FCS across the PW. > This seems to be a contradiction to the above statement: " It is not intended that an emulated service will be indistinguishable from the service that is being emulated. " I'm not sure that the FCS retention draft needs anything in the charter specific to it . What other work is this paragraph intended for ? I think that this should be made clear or removed. > Define mechanisms to permit the operation of a PW over > a PSN that employs equal cost multiple path (ECMP) packet > switching mechanism. > I take this to mean that we will define methods to operate PW in a network containing ECMP ... This means finding a way to load share a PW across multiple links .... Are you sure this is the intention ? ( disabling load sharing for PW would actually break the ECMP network ... ) I think you should take this section out unless the intention is as above. Luca > A PW operating over a shared PSN does not have the same > intrinsic security as a dedicated, purpose built, network. > In some cases this is satisfactory, while in other cases it > will be necessary to enhance the security of the PW > to emulate the intrinsic security of the emulated service. > PW specifications MUST include a description of how they > are to be operated over a shared PSN with adequate security. > > Whilst a service provider may traffic engineer their network > in such a way that PW traffic will not cause significant > congestion, a PW deployed by an end-user may cause > congestion of the underlying PSN. Suitable congestion > avoidance mechanisms are therefore needed to protect the > Internet from the unconstrained deployment of PWs. > > Define requirements for and mechanisms to provide > interconnection of PWs (to include inter-domain PWs). > > Define the requirements for and mechanisms needed to allow > the operation of switched virtual circuits over a PSN. > > > > _______________________________________________ > 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 Jul 26 14:13:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTty-0000aD-Sz; Tue, 26 Jul 2005 14:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTtw-0000ZI-Fv for pwe3@megatron.ietf.org; Tue, 26 Jul 2005 14:11:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11470 for ; Tue, 26 Jul 2005 14:11:35 -0400 (EDT) Received: from division.aa.arbor.net ([204.181.64.2] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUP1-0005Qv-Og for pwe3@ietf.org; Tue, 26 Jul 2005 14:43:45 -0400 Received: from [205.168.100.50] (unknown [10.0.12.200]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id D74D3142A3; Tue, 26 Jul 2005 14:11:33 -0400 (EDT) In-Reply-To: <42E67A41.5010707@cisco.com> References: <42E67A41.5010707@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <954b437e4e2017cff043e5990a39211f@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks Date: Tue, 26 Jul 2005 12:11:31 -0600 To: Luca Martini X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit 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: ,