From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Rick Osteen" Subject: Re: Re: Comments/ questions to draft-riegel-pwe3-tdm-requirements-01.txt Date: Sat, 1 Feb 2003 07:44:55 -0500 Lines: 77 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03C3C@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Return-path: To: "Shahram Davari" , "'Max Riegel'" , "Alik Shimelmits" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I believe that some requirement regarding delay is important for it to be attractive and useful to use. The first thought in the service provider's mind is considering if the actual "gazinta gazada"(a.k.a goes into, goes out of) works. The second is "Is it useful" or is it just not going to be a good customer experience. The bar for any data packet and it's delay has been raised. There are more and more people aware of delay and are wanting SLA's to hold the service provider's accountable. Customers, residential and business, are expecting money back if performance isn't up to par. -Rick Osteen ----- Original Message ----- From: "Shahram Davari" To: "'Max Riegel'" ; "Alik Shimelmits" Cc: Sent: Friday, January 31, 2003 10:18 AM Subject: RE: [PWE3] Re: Comments/ questions to draft-riegel-pwe3-tdm-requirements-01.txt > > > > > GENERAL -The document specifies (section 2) the need to put special > > emphasis on minimization of one-way delay. End-2-end delay (that > > actually is the sum of packetiztion delay, network delay and delay > > introduced by the jitter buffer] is important paramater for network > > designer. I would propose to include the requirement for n x DS0 and n > > x VC-x services - end-2-end delay should be not depend upon the value > > of n. > > I don't think such a requirement is needed. Not only such requirement > makes the design of the PW box more complicated, but also due to variable > overhead it makes the capacity planning next to impossible. Also a few msec > differences won't be noticeable by the end user. Remember we are not trying to > perfectly emulate TDM networks. IP networks have characteristics that needs to be > considered. > > -Shahram > > -I am afraid that there might be an overlap between n x DS0 with > > CAS and AVT WG activities: RFC 2833 defines how to carry telephony > > signals over the network, and, at least, in the past(!) a lot of work > > about multiplexing/bundling of voice streams was done in AVT WG (e.g. > > draft-ietf-avt-aggregation-00.txt - expired in 1998). What do you > > think? > > > > Keeping end2end delay constant in case of transmission of > > voice signals > > looks reasonable for me. But taking into account that we are > > only dealing > > with a part of the end2end transmission path (the pseudo wire > > emulation > > edge2edge) I wouldn't put any requirements for the end2end > > behaviour into > > our document. > > > > > > > Bye > > Max > > > > _______________________________________________ > > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: Re: Comments/ questions to draft-riegel-pwe3-tdm-requi rements-01.txt Date: Sat, 1 Feb 2003 17:39:21 -0000 Lines: 43 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org Return-path: To: rick.osteen@cox.net, Shahram_Davari@pmc-sierra.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Rick, please see remark below. regards, Neil Rick Osteen wrote > Sent: 01 February 2003 12:45 > > I believe that some requirement regarding delay is important > for it to be > attractive and useful to use. The first thought in the > service provider's > mind is considering if the actual "gazinta gazada"(a.k.a goes > into, goes out > of) works. The second is "Is it useful" or is it just not > going to be a good > customer experience. > The bar for any data packet and it's delay has been raised. > There are more > and more people aware of delay and are wanting SLA's to hold > the service > provider's accountable. Customers, residential and business, > are expecting > money back if performance isn't up to par. NH=> Quite so. And as an operator this is very important to me. However, I must be able to properly *fault-manage* the network properly first (ie auto defect detection/handling based on consistent defect entry/exit criteria and consequent actions). Delay/loss, or indeed any QoS metrics/objectives, are of far less importance. Further, any QoS metric measurements are only meaningful when the network (or at least the PW in question here) is in the available state....so one needs to define what this is in terms of entry/exit criteria and consequent actions too (one of which, based on what I have just observed, is stopping/starting QoS metric measurements on entering/leaving the unavailable state). There is an obvious logical ordering here: - define defects and their auto detection/handling 1st - then, based on above (ie persistency of defects), define availability/unavailabilty.....note these need their own SLAs which are disjoint from QoS SLAs; - than, and only then, can you sensibly define QoS SLAs since these are only relevant to the available state. Please read Y.1710/Y.1711, this is what is required for the fault-management of MPLS p2p LSPs, esp when carrying arbitrary clients (availability is also defined in here). These Recs are based on the above logic. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Max Riegel Subject: RE: Re: Comments/ questions to draft-riegel-pwe3-tdm-requi rements-01.txt Date: Mon, 03 Feb 2003 17:34:47 +0100 Lines: 33 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03C3C@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org, Alik Shimelmits Return-path: X-Sender: rm049557@139.21.212.200 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03C3C@nt-exch-yow.pmc-sie rra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 31.01.2003 16:18 +0100, Shahram Davari wrote: > > GENERAL -The document specifies (section 2) the need to put special > > emphasis on minimization of one-way delay. End-2-end delay (that > > actually is the sum of packetiztion delay, network delay and delay > > introduced by the jitter buffer] is important paramater for network > > designer. I would propose to include the requirement for n x DS0 and n > > x VC-x services - end-2-end delay should be not depend upon the value > > of n. > >I don't think such a requirement is needed. Not only such requirement >makes the design of the PW box more complicated, but also due to >variable overhead it makes the capacity planning next to impossible. >Also a few msec differences won't be noticeable by the end user. >Remember we are not trying to perfectly emulate TDM networks. >IP networks have characteristics that needs to be considered. Shahram, I agree with you that we should not include requirements for end-to-end delay minimization. PWE3 deals with emulation edge-to-edge and it it our intention to design a protocol for use edge-to-edge. Edge-to-edge implies that there might be several emulated circuits in line thus delay minimization for edge-to-edge is even becoming a more important issue. If a few ms might be tolerable end-to-end, n-times a few ms might become critical for the service transported over emulated TDM circuits. I didn't found a way yet how to restrict the repeated use of emulated TDM circuits in a real network. I do not understand: "also due to variable overhead it makes the capacity planning next to impossible." Can you explain your meaning a little bit more. Bye Max From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: Re: Comments/ questions to draft-riegel-pwe3-tdm-requi rements-01.txt Date: Mon, 3 Feb 2003 08:50:47 -0800 Lines: 29 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, Alik Shimelmits Return-path: To: "'Max Riegel'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Max, > > Edge-to-edge implies that there might be several emulated > circuits in line > thus delay minimization for edge-to-edge is even becoming a > more important > issue. If a few ms might be tolerable end-to-end, n-times a > few ms might > become critical for the service transported over emulated TDM > circuits. Are you suggesting that the delay is proportional to the number of emulated circuits (n)? > > I do not understand: "also due to variable overhead it makes > the capacity > planning next to impossible." Can you explain your meaning a > little bit more. > I think you agree that using fixed delay edge-to-edge means each PWs will have different packet sizes. Since the header size is the same in all of them, therefore the % of overhead would be different between PWs. For example if a PW is carrying a single DS0, and assuming a packetization delay budget of 5 msec you could encapsulate max 40 bytes of data in the packet. Assuming a IP/UDP/RTP/IW header (44 bytes) we would have a BW efficiency of 50%. Now if another PW is carrying a single T1, then a max of 960 bytes could be carried in the packet which gives us BW efficiency of 95%. So the service provider is unable to determine how much BW a certain amount of TDM traffic it can generate. Off course, it can reserve 2x BW and under-subscribe the network ! Yours, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: Re: Comments/ questions to draft-riegel-pwe3-tdm-requi rements-01.txt Date: Mon, 3 Feb 2003 09:12:27 -0800 Lines: 60 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org Return-path: To: "'Max Riegel'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > >Are you suggesting that the delay is proportional to the number of > >emulated circuits (n)? > > If you are puting them not parallel but in sequence, you > might end up with > n-times the delay. What do you mean by putting them in sequence and not parallel? All WAN/MAN communication links are sequential (there is no parallel bus here). I still can't understand your point. Could you please give an example. > > > > I do not understand: "also due to variable overhead it makes > > > the capacity > > > planning next to impossible." Can you explain your meaning a > > > little bit more. > > > >I think you agree that using fixed delay edge-to-edge means > each PWs will > >have different packet sizes. Since the header size is the > same in all of > >them, therefore the % of overhead would be different between > PWs. For > >example if a PW is carrying a single DS0, and assuming a > packetization > >delay budget of 5 msec you could encapsulate max 40 bytes of > data in the > >packet. Assuming a IP/UDP/RTP/IW header (44 bytes) we would > have a BW > >efficiency of 50%. Now if another PW is carrying a single > T1, then a max > >of 960 bytes could be carried in the packet which gives us > BW efficiency > >of 95%. > > > >So the service provider is unable to determine how much BW a certain > >amount of TDM traffic it can generate. Off course, it can > reserve 2x BW > >and under-subscribe the network ! > > A service provider should know which circuits he is selling > to customers, > e.g. 7x DS0, 3x T1. It takes only simple mathematics to get > exact figures > of total bandwidth allocation, even if the overhead of the particular > circuits is different. > But the problem is that a service provider who has, let say allocated 10% of its core BW to CES, can't compute before hand how many DS0 it can carry in that 10%. Computing real time is not a problem, planning is difficult. Yours, -Shahram > Bye > Max > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Max Riegel Subject: RE: Re: Comments/ questions to draft-riegel-pwe3-tdm-requi rements-01.txt Date: Mon, 03 Feb 2003 18:03:02 +0100 Lines: 43 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03C4C@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org Return-path: X-Sender: rm049557@139.21.212.200 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03C4C@nt-exch-yow.pmc-sie rra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 03.02.2003 08:50 -0800, Shahram Davari wrote: > > Edge-to-edge implies that there might be several emulated > > circuits in line > > thus delay minimization for edge-to-edge is even becoming a > > more important > > issue. If a few ms might be tolerable end-to-end, n-times a > > few ms might > > become critical for the service transported over emulated TDM > > circuits. > >Are you suggesting that the delay is proportional to the number of >emulated circuits (n)? If you are puting them not parallel but in sequence, you might end up with n-times the delay. > > I do not understand: "also due to variable overhead it makes > > the capacity > > planning next to impossible." Can you explain your meaning a > > little bit more. > >I think you agree that using fixed delay edge-to-edge means each PWs will >have different packet sizes. Since the header size is the same in all of >them, therefore the % of overhead would be different between PWs. For >example if a PW is carrying a single DS0, and assuming a packetization >delay budget of 5 msec you could encapsulate max 40 bytes of data in the >packet. Assuming a IP/UDP/RTP/IW header (44 bytes) we would have a BW >efficiency of 50%. Now if another PW is carrying a single T1, then a max >of 960 bytes could be carried in the packet which gives us BW efficiency >of 95%. > >So the service provider is unable to determine how much BW a certain >amount of TDM traffic it can generate. Off course, it can reserve 2x BW >and under-subscribe the network ! A service provider should know which circuits he is selling to customers, e.g. 7x DS0, 3x T1. It takes only simple mathematics to get exact figures of total bandwidth allocation, even if the overhead of the particular circuits is different. Bye Max From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-sonet-01.txt Date: Tue, 04 Feb 2003 06:45:21 -0500 Lines: 84 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart 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 : SONET/SDH Circuit Emulation over Packet (CEP) Author(s) : D. Zelig, P. Pate Filename : draft-ietf-pwe3-sonet-01.txt Pages : 37 Date : 2003-2-3 The generic requirements and architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3- ARCH]. Additional requirements for emulation of SONET/SDH and lower-rate TDM circuits has been defined in [PWE3-TDM-REQ]. This draft provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over a packet-switched network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sonet-01.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-sonet-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-arch-02.txt Date: Wed, 05 Feb 2003 06:44:51 -0500 Lines: 83 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart 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 : PWE3 Architecture Author(s) : S. Bryant, P. Pate Filename : draft-ietf-pwe3-arch-02.txt Pages : 45 Date : 2003-2-4 This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, specifies the various protocol elements and their functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-arch-02.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-arch-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: Comments on Martini PDU mode Date: Fri, 7 Feb 2003 07:59:41 -0800 Lines: 122 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CEC1.EC784470" Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2CEC1.EC784470 Content-Type: text/plain; charset="iso-8859-1" Dear colleagues, As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode. ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last encapsulated ATM cell's header. The reasons for this change are as following: 1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such. 2) Considering the above point, it seems that out of the currently defined values for FRAG: "Frg (Fragmentation) Bits This field is used to support the fragmentation functionality described later in this section. - 11 Single Segment Message (Beginning and End of Message) - 10 Beginning of Message - 00 Continuation of Message - 01 End of Message " The Beginning of Message (10) and the continuation of message (00) are not needed for the egress processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message). This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header. I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE. Yours, Shahram Davari Senior Product Research Engineer R&D Research Ottawa PMC-Sierra, Inc. Phone: (613) 271-4018 Fax: (613) 271-6468 ------_=_NextPart_001_01C2CEC1.EC784470 Content-Type: text/html; charset="iso-8859-1"
Dear colleagues,
 
As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode.
ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last
encapsulated ATM cell's header. The reasons for this change are as following:
 
1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such.
 
2) Considering the above point, it seems that out of the currently defined values for FRAG:
 
"Frg (Fragmentation) Bits

       This field is used to support the fragmentation functionality
       described later in this section.
     - 11 Single Segment Message (Beginning and End of Message)
     - 10 Beginning of Message
     - 00 Continuation of Message
     - 01 End of Message "
 
The Beginning of Message (10) and the continuation of message (00) are not needed for the egress
processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message).
This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header.
 
I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE.
 
Yours,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc.
Phone: (613) 271-4018
Fax:   (613) 271-6468
 
------_=_NextPart_001_01C2CEC1.EC784470-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: Comments on Martini PDU mode Date: Fri, 7 Feb 2003 08:21:28 -0800 Lines: 174 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CEC4.F7E99EF0" Return-path: To: Shahram Davari , "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2CEC4.F7E99EF0 Content-Type: text/plain; charset="iso-8859-1" Dear colleagues, I forgot to mention another important reason for such a proposed change: 3) As stated in the draft, Fragmentation is mainly used for preserving the ATM OAM cell position in respect to AAL5 composite cells. Reassembling the AAL5 PDU at the egress PE would cause repositioning of the OAM cells with respect to the AAL5 composite cells. Therefore to preserve OAM cells position, the egress should not reassemble the AAL5 PDU. And since no reassembling is required, there there is no need to identify beginning and middle of message. Yours, Shahram -----Original Message----- From: Shahram Davari Sent: Friday, February 07, 2003 11:00 AM To: 'pwe3@ietf.org' Subject: [PWE3] Comments on Martini PDU mode Dear colleagues, As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode. ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last encapsulated ATM cell's header. The reasons for this change are as following: 1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such. 2) Considering the above point, it seems that out of the currently defined values for FRAG: "Frg (Fragmentation) Bits This field is used to support the fragmentation functionality described later in this section. - 11 Single Segment Message (Beginning and End of Message) - 10 Beginning of Message - 00 Continuation of Message - 01 End of Message " The Beginning of Message (10) and the continuation of message (00) are not needed for the egress processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message). This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header. I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE. Yours, Shahram Davari Senior Product Research Engineer R&D Research Ottawa PMC-Sierra, Inc. Phone: (613) 271-4018 Fax: (613) 271-6468 ------_=_NextPart_001_01C2CEC4.F7E99EF0 Content-Type: text/html; charset="iso-8859-1"
Dear colleagues,
 
I forgot to mention another important reason for such a proposed change:
 
3) As stated in the draft, Fragmentation is mainly used for preserving the ATM OAM cell position in respect to AAL5 composite cells. Reassembling the AAL5 PDU at the egress PE would cause repositioning of the OAM cells with respect to the AAL5 composite cells. Therefore to preserve OAM cells position, the egress should not reassemble the AAL5 PDU. And since no reassembling is required, there there is no need to identify beginning and middle of message.
 
Yours,
Shahram
-----Original Message-----
From: Shahram Davari
Sent: Friday, February 07, 2003 11:00 AM
To: 'pwe3@ietf.org'
Subject: [PWE3] Comments on Martini PDU mode

Dear colleagues,
 
As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode.
ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last
encapsulated ATM cell's header. The reasons for this change are as following:
 
1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such.
 
2) Considering the above point, it seems that out of the currently defined values for FRAG:
 
"Frg (Fragmentation) Bits

       This field is used to support the fragmentation functionality
       described later in this section.
     - 11 Single Segment Message (Beginning and End of Message)
     - 10 Beginning of Message
     - 00 Continuation of Message
     - 01 End of Message "
 
The Beginning of Message (10) and the continuation of message (00) are not needed for the egress
processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message).
This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header.
 
I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE.
 
Yours,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc.
Phone: (613) 271-4018
Fax:   (613) 271-6468
 
------_=_NextPart_001_01C2CEC4.F7E99EF0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Maarten Vissers Subject: leaving Lucent Date: Mon, 10 Feb 2003 10:32:05 +0100 Organization: Lucent Technologies Lines: 46 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------84B24B7F77E76AEEAB570F41" Return-path: To: q9/15 , q11/15 , q12/15 , q14/15 , "t1x1.5" , pwe3 , mef-architecture , mef-services X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en To: q9/15 , q11/15 , q12/15 , q14/15 , "t1x1.5" , pwe3 , mef-architecture , mef-services Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. --------------84B24B7F77E76AEEAB570F41 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Today is my last day with access to my Lucent email account and in a few weeks (March 1) I will be leaving Lucent. But my game won't be over... I am looking back with great pleasure at a period of 20 years in which I worked not only for Philips, AT&T and Lucent, but in some aspects also for ETSI, ITU-T, T1, MEF and IETF. New opportunities are in front of me, and I am looking forward to explore those... My new contact information is: Tel: +31 35 523 4028 Mobile: +31 64 484 4112 Email: maarten@maartenvissers.nl Web: www.maartenvissers.nl Regards, Maarten --------------84B24B7F77E76AEEAB570F41 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies;NA&CPSE adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff fn:Maarten Vissers end:vcard --------------84B24B7F77E76AEEAB570F41-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Re: Comments on Martini PDU mode Date: Mon, 10 Feb 2003 09:53:35 +0000 Lines: 76 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "'pwe3@ietf.org'" , pwe3-admin@ietf.org Return-path: To: Shahram Davari X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/10/2003 09:53:37, Serialize complete at 02/10/2003 09:53:37 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Shahram, I agree with you. The individual fragments should never be reassembled at the egress side. The process is actually quite simple, as you describe. Best regards, Matthew ----------------------------------------- Matthew Bocci Office of the CTO Alcatel Fixed Networks Division ----------------------------------------- Shahram Davari Sent by: pwe3-admin@ietf.org 07/02/2003 15:59 To: "'pwe3@ietf.org'" cc: Subject: [PWE3] Comments on Martini PDU mode Dear colleagues, As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode. ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last encapsulated ATM cell's header. The reasons for this change are as following: 1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such. 2) Considering the above point, it seems that out of the currently defined values for FRAG: "Frg (Fragmentation) Bits This field is used to support the fragmentation functionality described later in this section. - 11 Single Segment Message (Beginning and End of Message) - 10 Beginning of Message - 00 Continuation of Message - 01 End of Message " The Beginning of Message (10) and the continuation of message (00) are not needed for the egress processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message). This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header. I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE. Yours, Shahram Davari Senior Product Research Engineer R&D Research Ottawa PMC-Sierra, Inc. Phone: (613) 271-4018 Fax: (613) 271-6468 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Re: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Mon, 10 Feb 2003 10:18:42 +0000 Lines: 53 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "'pwe3@ietf.org'" Return-path: To: David Clear X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/10/2003 10:18:44, Serialize complete at 02/10/2003 10:18:44 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O David, Regarding point 3 below, the way the draft is written, it could be either one-to-one or n-to-one (although n-to-one is mandatory to support). Also, the draft only mentions SDU mode for encapsulation of AAL5 frames, but in fact this could also be done using PDU encapsulation, for the reasons discussed in the applicability sections of draft-ietf-pwe3-atm-encap-00.txt. I believe that draft-ietf-pwe3-control-protocol-01.txt should provide support for all of the ATM encap modes, whether mandatory or optional. Best regards, Matthew ----------------------------------------- Matthew Bocci Office of the CTO Alcatel Fixed Networks Division ----------------------------------------- David Clear Sent by: pwe3-admin@ietf.org 22/01/2003 23:28 To: "'pwe3@ietf.org'" cc: Subject: [PWE3] Questions from draft-ietf-pwe3-control-protocol-01.txt Hi. A few questions I hope you can help with. [Frame Relay PW over MPLS] 1. Section 4.1 references draft-ietf-pwe3-frame-encap-01.txt, but I can't seem to find that draft (nor an -00 version). Has it been superceded by draft-ietf-pwe3-frame-relay-00.txt? 2. If LDP is used to signal a PW type of 0x0001 (Frame Relay DLCI), does that correspond to the "one-to-one" mode or "port mode" encapsulation (from draft-ietf-pwe3-frame-relay-00.txt (if that's the current one))? [ATM PW over MPLS] 3. Do LDP PW types 0x9 (ATM VCC cell transport) and 0xa (ATM VPC cell transport) refer to "one-to-one" mode or "n-to-one" mode encaps (from draft-ietf-pwe3-atm-encap-00.txt)? Section 4.2.3 reads: "Every cell that is received... is encapsulated according to [10], ATM cell mode...", but "ATM cell mode" does not zero in on a specific section from atm-encap draft. I figure it's n-to-one, but I would like confirmation. Regards, David. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: Comments on Martini PDU mode Date: Mon, 10 Feb 2003 10:38:30 -0000 Lines: 120 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, pwe3-admin@ietf.org Return-path: To: Matthew.Bocci@alcatel.co.uk, Shahram_Davari@pmc-sierra.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Like Matthew I also agree with you.....and your subsequent posting (7 Feb) where you said the following makes this change forced anyway: "3) As stated in the draft, Fragmentation is mainly used for preserving the ATM OAM cell position in respect to AAL5 composite cells. Reassembling the AAL5 PDU at the egress PE would cause repositioning of the OAM cells with respect to the AAL5 composite cells. Therefore to preserve OAM cells position, the egress should not reassemble the AAL5 PDU. And since no reassembling is required, there there is no need to identify beginning and middle of message." regards, Neil > -----Original Message----- > From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk] > Sent: 10 February 2003 09:54 > To: Shahram Davari > Cc: 'pwe3@ietf.org'; pwe3-admin@ietf.org > Subject: Re: [PWE3] Comments on Martini PDU mode > > > Hi Shahram, > > I agree with you. The individual fragments should never be > reassembled at > the egress side. The process is actually quite simple, as you > describe. > > Best regards, > > Matthew > > ----------------------------------------- > Matthew Bocci > Office of the CTO > Alcatel Fixed Networks Division > ----------------------------------------- > > > > > Shahram Davari > Sent by: pwe3-admin@ietf.org > 07/02/2003 15:59 > > > To: "'pwe3@ietf.org'" > cc: > Subject: [PWE3] Comments on Martini PDU mode > > > Dear colleagues, > > As some of you may know, ATM Forum has recently approved a > minor change to > the PDU frame transport mode. > ATM Forum has changed the 2-bit FRAG field to a single field called > UU-bit, that would be copied from the last > encapsulated ATM cell's header. The reasons for this change are as > following: > > 1) Although PDU mode does not state explicitly what are the > procedures for > fragmentation at the ingress and de-fragmentation at the > egress side, but > it implicitly assumes that the AAL5 PDU is reassembled at the > egress PE. > It seems that for reducing the latency and for simplicity in > processing, > there is no need to reassemble the fragments at the egress > PE. Rather each > received fragment could be segmented to constituents ATM > cells without > waiting to reassemble the whole AAL5 frame. All known > implementation of > PDU mode behave as such. > > 2) Considering the above point, it seems that out of the > currently defined > values for FRAG: > > "Frg (Fragmentation) Bits > > This field is used to support the fragmentation functionality > described later in this section. > - 11 Single Segment Message (Beginning and End of Message) > - 10 Beginning of Message > - 00 Continuation of Message > - 01 End of Message " > > The Beginning of Message (10) and the continuation of message > (00) are not > needed for the egress > processing. And therefore a single bit could be used to keep the > transparency of the AAL5 EOM (End of Message). > This field could be called UU-bit and be copied from the > header of the > last cell of the fragment to the PW header. > > I would like to propose changing the PDU mode in Martini > draft to simplify > the processing, reduce latency and buffering requirements at > the egress > PE. > > Yours, > Shahram Davari > Senior Product Research Engineer > R&D Research Ottawa > PMC-Sierra, Inc. > Phone: (613) 271-4018 > Fax: (613) 271-6468 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdm-requirements-00.txt Date: Tue, 11 Feb 2003 06:45:53 -0500 Lines: 86 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart 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 Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN) Author(s) : M. Riegel Filename : draft-ietf-pwe3-tdm-requirements-00.txt Pages : 26 Date : 2003-2-10 This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital signals of the PDH as well as the SONET/SDH hierarchy over packet-switched networks. It is based on the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH]. It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tdm-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-tdm-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "John Fischer" Subject: Re: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: 11 Feb 2003 08:56:34 -0500 Organization: Alcatel Canada Lines: 75 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: To: "'pwe3@ietf.org'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi all, I would like to request the editors of this draft to make updates in several areas: 4.2 ATM 4.2.1 Describes the N:1 AAL5 mode. Another section with a description of the 1:1 AAL5 PDU mode is needed. 4.2.3 Does this section intend to describe the 1:1 VCC, 1:1 VPC encapsulation modes? If so, it should clearly indicate so. If not, it should specify N:1 and another section for 1:1 cell mode as well as new PW types should be added to the document. In order to be clear, the list of PW types in section 5 should also be updated: 0x0002 ATM AAL5 VCC transport <<< ADD N:1 IN NAME 0x0003 ATM transparent cell transport <<< ADD N:1 IN NAME 0x0009 ATM VCC cell transport <<< ADD 1:1 IN NAME 0x000A ATM VPC cell transport <<< ADD 1:1 IN NAME Thanks, John Matthew.Bocci@alcatel.co.uk wrote: > David, > > Regarding point 3 below, the way the draft is written, it could be either > one-to-one or n-to-one (although n-to-one is mandatory to support). Also, > the draft only mentions SDU mode for encapsulation of AAL5 frames, but in > fact this could also be done using PDU encapsulation, for the reasons > discussed in the applicability sections of draft-ietf-pwe3-atm-encap-00.txt. > > I believe that draft-ietf-pwe3-control-protocol-01.txt should provide > support for all of the ATM encap modes, whether mandatory or optional. > > Best regards, > > Matthew > > ----------------------------------------- > Matthew Bocci > Office of the CTO > Alcatel Fixed Networks Division > ----------------------------------------- > > David Clear > Sent by: pwe3-admin@ietf.org > 22/01/2003 23:28 > > > To: "'pwe3@ietf.org'" > cc: > Subject: [PWE3] Questions from draft-ietf-pwe3-control-protocol-01.txt > > Hi. A few questions I hope you can help with. > [Frame Relay PW over MPLS] > 1. Section 4.1 references draft-ietf-pwe3-frame-encap-01.txt, but I can't > seem to find that draft (nor an -00 version). Has it been superceded by > draft-ietf-pwe3-frame-relay-00.txt? > 2. If LDP is used to signal a PW type of 0x0001 (Frame Relay DLCI), does > that correspond to the "one-to-one" mode or "port mode" encapsulation > (from draft-ietf-pwe3-frame-relay-00.txt (if that's the current one))? > [ATM PW over MPLS] > 3. Do LDP PW types 0x9 (ATM VCC cell transport) and 0xa (ATM VPC cell > transport) refer to "one-to-one" mode or "n-to-one" mode encaps (from > draft-ietf-pwe3-atm-encap-00.txt)? Section 4.2.3 reads: "Every cell that > is received... is encapsulated according to [10], ATM cell mode...", but > "ATM cell mode" does not zero in on a specific section from atm-encap > draft. I figure it's n-to-one, but I would like confirmation. > > Regards, > David. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Tue, 11 Feb 2003 17:52:36 +0200 Lines: 26 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'pwe3@ietf.org'" Return-path: To: "Luca (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca and all, A brief comment on draft-ietf-pwe3-control-protocol-01.txt. Section 5.1. specificies that, when applicabple, the "Interface Parameters" field must be used to validate that ... the ingress and egress ports at the edges of the circuit, have the necessary capabilities to interoperate with each other. For CEP PWs (which, probably unintentionally, are still called CEM in the draft), and, more generically, for all the TDM PWs, interoperability of ingress and egress ports definitely requires that they are of the same bit rate. (This does not apply to frame- or cell-oriented PWs.) However, the draft does not provide for encoding of the ports' bit rate as part of the "Interface Parameters" field. I also seem to remember that the WG discussed the possibility to maintain the list of registered PW types in a separate document. Everybody seemed to be in favor then; but I have not seen any development in this direction. Did I miss something? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Luca Martini Subject: Re: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Tue, 11 Feb 2003 18:24:13 -0700 Organization: Level3 Communications LLC. Lines: 43 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: Sasha Vainshtein Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha Vainshtein wrote: > Luca and all, > A brief comment on draft-ietf-pwe3-control-protocol-01.txt. > > Section 5.1. specificies that, when applicabple, the "Interface Parameters" > field must be used to validate that ... the ingress and egress > ports at the edges of the circuit, have the necessary capabilities to > interoperate with each other. > > For CEP PWs (which, probably unintentionally, are still called CEM in the > draft), and, more generically, for all the TDM PWs, interoperability of > ingress and egress ports definitely requires that they are of the same > bit rate. (This does not apply to frame- or cell-oriented PWs.) However, > the draft does not provide for encoding of the ports' bit rate as part of > the "Interface Parameters" field. > I have no objection to including an interface bit rate for CEM. please write a section for it and send it to me this week. > I also seem to remember that the WG discussed the possibility to maintain > the list of registered PW types in a separate document. Everybody seemed > to be in favor then; but I have not seen any development in this direction. > Did I miss something? > no, mark and I run out of time. I can split this out now, it's not too much work. ( getting to split the control word out is however much more time consuming :-( ) Luca > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Luca Martini Subject: Re: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Tue, 11 Feb 2003 18:29:26 -0700 Organization: Level3 Communications LLC. Lines: 92 Sender: pwe3-admin@ietf.org References: <3E490112.222ABE81@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: John Fischer Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O yes , this is my plan as well. I'm waiting for Matthew to return the ATM document , then i'll straiten out all the modes in the control document. Do you really care what vd type numbers get allocated to the 1:1 modes ? Thanks. luca John Fischer wrote: > Hi all, > I would like to request the editors of this draft to make > updates in several areas: > 4.2 ATM > 4.2.1 Describes the N:1 AAL5 mode. Another section with a description > of the 1:1 AAL5 PDU mode is needed. > 4.2.3 Does this section intend to describe the 1:1 VCC, 1:1 VPC > encapsulation modes? If so, it should clearly indicate so. > If not, it should specify N:1 and another section for 1:1 cell mode > as well as new PW types should be added to the document. > > In order to be clear, the list of PW types in section 5 should also be > updated: > 0x0002 ATM AAL5 VCC transport <<< ADD N:1 IN NAME > 0x0003 ATM transparent cell transport <<< ADD N:1 IN NAME > 0x0009 ATM VCC cell transport <<< ADD 1:1 IN NAME > 0x000A ATM VPC cell transport <<< ADD 1:1 IN NAME > Thanks, > John > > Matthew.Bocci@alcatel.co.uk wrote: > > >>David, >> >>Regarding point 3 below, the way the draft is written, it could be either >>one-to-one or n-to-one (although n-to-one is mandatory to support). Also, >>the draft only mentions SDU mode for encapsulation of AAL5 frames, but in >>fact this could also be done using PDU encapsulation, for the reasons >>discussed in the applicability sections of draft-ietf-pwe3-atm-encap-00.txt. >> >>I believe that draft-ietf-pwe3-control-protocol-01.txt should provide >>support for all of the ATM encap modes, whether mandatory or optional. >> >>Best regards, >> >>Matthew >> >>----------------------------------------- >>Matthew Bocci >>Office of the CTO >>Alcatel Fixed Networks Division >>----------------------------------------- >> >>David Clear >>Sent by: pwe3-admin@ietf.org >>22/01/2003 23:28 >> >> >> To: "'pwe3@ietf.org'" >> cc: >> Subject: [PWE3] Questions from draft-ietf-pwe3-control-protocol-01.txt >> >>Hi. A few questions I hope you can help with. >>[Frame Relay PW over MPLS] >>1. Section 4.1 references draft-ietf-pwe3-frame-encap-01.txt, but I can't >>seem to find that draft (nor an -00 version). Has it been superceded by >>draft-ietf-pwe3-frame-relay-00.txt? >>2. If LDP is used to signal a PW type of 0x0001 (Frame Relay DLCI), does >>that correspond to the "one-to-one" mode or "port mode" encapsulation >>(from draft-ietf-pwe3-frame-relay-00.txt (if that's the current one))? >>[ATM PW over MPLS] >>3. Do LDP PW types 0x9 (ATM VCC cell transport) and 0xa (ATM VPC cell >>transport) refer to "one-to-one" mode or "n-to-one" mode encaps (from >>draft-ietf-pwe3-atm-encap-00.txt)? Section 4.2.3 reads: "Every cell that >>is received... is encapsulated according to [10], ATM cell mode...", but >>"ATM cell mode" does not zero in on a specific section from atm-encap >>draft. I figure it's n-to-one, but I would like confirmation. >> >>Regards, >>David. >> >>_______________________________________________ >>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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Luca Martini Subject: Re: PWE3 congestion Date: Tue, 11 Feb 2003 18:42:01 -0700 Organization: Level3 Communications LLC. Lines: 46 Sender: pwe3-admin@ietf.org References: <3E26FFD4.6060101@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: stbryant@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O it sounds like a reasonable approach. It would be nice to point out somewhere that the several PW layer2 payloads assume 100% delivery , and therefore PW should probably be run over a PSN that can guarantee 100% frame delivery for the pw class of service. Luca Stewart Bryant wrote: > I am looking at the congestion section of the arch > revision (we need one). It seems to me that we can divide the > problem up into two traffic classes: > > o Traffic known (perhaps by SLA, perhaps by audit) to be TCP > friendly > > o Traffic of unknown provenance > > In the former case we need do nothing. Natural packet discard > will feed back to the transport layer, and the right things > will happen. I include in this case IP over packet PW, and IP > over ATM PW. I propose that the term "TCP friendly" be left > sufficiently general that it covers any IETF transport (they > are all supposed to be TCP friendly), and other similar > transports such as TP4 (if it still exists). > > For the "traffic of unknown provenance", it seems to me that > > could be used to calculate the maximum offered load, and > the PE would then be required to maintain it's load below > this rate (if necessary by shutting down PWs). The > statistics needed to operate this algorithm look a bit > daunting for a forwarding system, but presumably > some stastical view of the counters, a priori knowledge > of the bit rate etc would simplify things. > > Has anyone elso looked at this, and does it seem like the > right way to go? > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Chris Metz Subject: Re: PWE3 congestion Date: Wed, 12 Feb 2003 06:58:25 -0500 Lines: 60 Sender: pwe3-admin@ietf.org References: <3E26FFD4.6060101@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stbryant@cisco.com, "pwe3@ietf.org" Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Luca Martini In-Reply-To: <3E49A669.1010008@level3.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 06:42 PM 2/11/2003 -0700, Luca Martini wrote: >it sounds like a reasonable approach. >It would be nice to point out somewhere that the several PW layer2 >payloads assume 100% delivery , and therefore PW should probably be run >over a PSN that can guarantee 100% frame delivery for the pw class of service. Does such a PSN operating a today's speeds exist :-) Getting back to the notion of PWE3 congestion control I too am intrigued. The approach with TCP-style traffic operating over the PW is the correct one. Regarding traffic of unknown provenance the question would be how to implement the feedback loop so that the ingress PE is make aware of congestion and can take appropriate action. I am presuming we are not talking about encapsulating PWs in TCP/SCTP sessions between the PW end-points :-) so it seems we need what some sort of ABR-style closed loop? Cheers ... >Luca > > >Stewart Bryant wrote: >>I am looking at the congestion section of the arch >>revision (we need one). It seems to me that we can divide the >>problem up into two traffic classes: >>o Traffic known (perhaps by SLA, perhaps by audit) to be TCP >>friendly >>o Traffic of unknown provenance >>In the former case we need do nothing. Natural packet discard >>will feed back to the transport layer, and the right things >>will happen. I include in this case IP over packet PW, and IP >>over ATM PW. I propose that the term "TCP friendly" be left >>sufficiently general that it covers any IETF transport (they >>are all supposed to be TCP friendly), and other similar >>transports such as TP4 (if it still exists). >>For the "traffic of unknown provenance", it seems to me that >> >>could be used to calculate the maximum offered load, and >>the PE would then be required to maintain it's load below >>this rate (if necessary by shutting down PWs). The >>statistics needed to operate this algorithm look a bit >>daunting for a forwarding system, but presumably >>some stastical view of the counters, a priori knowledge >>of the bit rate etc would simplify things. >>Has anyone elso looked at this, and does it seem like the >>right way to go? >>Stewart >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Re: PWE3 congestion Date: Wed, 12 Feb 2003 12:53:01 +0000 Lines: 100 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Luca Martini , "pwe3@ietf.org" , pwe3-admin@ietf.org, stbryant@cisco.com Return-path: To: Chris Metz X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/12/2003 12:53:03, Serialize complete at 02/12/2003 12:53:03 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O All, Is the implicit assumption here that you cannot characterise the PW traffic sufficiently to provision the PSN so that it behaves in a way that the end-to-end layer 2 service can be sustained? For example, many protocols e.g. ATM, were originally designed with the assumption that packet loss in the underlying network (usually SONET/SDH) is very low. Even if you built in some form of closed loop congestion control for the PW, you still need to provision the PSN to allow the QoS objectives of the end-to-end service to be met. Cheers, Matthew ----------------------------------------- Matthew Bocci Office of the CTO Alcatel Fixed Networks Division ----------------------------------------- Chris Metz Sent by: pwe3-admin@ietf.org 12/02/2003 11:58 To: Luca Martini cc: stbryant@cisco.com, "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 congestion At 06:42 PM 2/11/2003 -0700, Luca Martini wrote: >it sounds like a reasonable approach. >It would be nice to point out somewhere that the several PW layer2 >payloads assume 100% delivery , and therefore PW should probably be run >over a PSN that can guarantee 100% frame delivery for the pw class of service. Does such a PSN operating a today's speeds exist :-) Getting back to the notion of PWE3 congestion control I too am intrigued. The approach with TCP-style traffic operating over the PW is the correct one. Regarding traffic of unknown provenance the question would be how to implement the feedback loop so that the ingress PE is make aware of congestion and can take appropriate action. I am presuming we are not talking about encapsulating PWs in TCP/SCTP sessions between the PW end-points :-) so it seems we need what some sort of ABR-style closed loop? Cheers ... >Luca > > >Stewart Bryant wrote: >>I am looking at the congestion section of the arch >>revision (we need one). It seems to me that we can divide the >>problem up into two traffic classes: >>o Traffic known (perhaps by SLA, perhaps by audit) to be TCP >>friendly >>o Traffic of unknown provenance >>In the former case we need do nothing. Natural packet discard >>will feed back to the transport layer, and the right things >>will happen. I include in this case IP over packet PW, and IP >>over ATM PW. I propose that the term "TCP friendly" be left >>sufficiently general that it covers any IETF transport (they >>are all supposed to be TCP friendly), and other similar >>transports such as TP4 (if it still exists). >>For the "traffic of unknown provenance", it seems to me that >> >>could be used to calculate the maximum offered load, and >>the PE would then be required to maintain it's load below >>this rate (if necessary by shutting down PWs). The >>statistics needed to operate this algorithm look a bit >>daunting for a forwarding system, but presumably >>some stastical view of the counters, a priori knowledge >>of the bit rate etc would simplify things. >>Has anyone elso looked at this, and does it seem like the >>right way to go? >>Stewart >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: John Fischer Subject: Re: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Wed, 12 Feb 2003 09:23:11 -0500 Organization: Alcatel Canada Lines: 98 Sender: pwe3-admin@ietf.org References: <3E490112.222ABE81@alcatel.com> <3E49A376.5000006@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Luca Martini Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I'm not particular about which numbers are allocated, just that there are some allocated. Thanks, John Luca Martini wrote: > yes , this is my plan as well. I'm waiting for Matthew to return the ATM > document , then i'll straiten out all the modes in the control document. > Do you really care what vd type numbers get allocated to the 1:1 modes ? > > Thanks. > luca > > John Fischer wrote: > > Hi all, > > I would like to request the editors of this draft to make > > updates in several areas: > > 4.2 ATM > > 4.2.1 Describes the N:1 AAL5 mode. Another section with a description > > of the 1:1 AAL5 PDU mode is needed. > > 4.2.3 Does this section intend to describe the 1:1 VCC, 1:1 VPC > > encapsulation modes? If so, it should clearly indicate so. > > If not, it should specify N:1 and another section for 1:1 cell mode > > as well as new PW types should be added to the document. > > > > In order to be clear, the list of PW types in section 5 should also be > > updated: > > 0x0002 ATM AAL5 VCC transport <<< ADD N:1 IN NAME > > 0x0003 ATM transparent cell transport <<< ADD N:1 IN NAME > > 0x0009 ATM VCC cell transport <<< ADD 1:1 IN NAME > > 0x000A ATM VPC cell transport <<< ADD 1:1 IN NAME > > Thanks, > > John > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > >>David, > >> > >>Regarding point 3 below, the way the draft is written, it could be either > >>one-to-one or n-to-one (although n-to-one is mandatory to support). Also, > >>the draft only mentions SDU mode for encapsulation of AAL5 frames, but in > >>fact this could also be done using PDU encapsulation, for the reasons > >>discussed in the applicability sections of draft-ietf-pwe3-atm-encap-00.txt. > >> > >>I believe that draft-ietf-pwe3-control-protocol-01.txt should provide > >>support for all of the ATM encap modes, whether mandatory or optional. > >> > >>Best regards, > >> > >>Matthew > >> > >>----------------------------------------- > >>Matthew Bocci > >>Office of the CTO > >>Alcatel Fixed Networks Division > >>----------------------------------------- > >> > >>David Clear > >>Sent by: pwe3-admin@ietf.org > >>22/01/2003 23:28 > >> > >> > >> To: "'pwe3@ietf.org'" > >> cc: > >> Subject: [PWE3] Questions from draft-ietf-pwe3-control-protocol-01.txt > >> > >>Hi. A few questions I hope you can help with. > >>[Frame Relay PW over MPLS] > >>1. Section 4.1 references draft-ietf-pwe3-frame-encap-01.txt, but I can't > >>seem to find that draft (nor an -00 version). Has it been superceded by > >>draft-ietf-pwe3-frame-relay-00.txt? > >>2. If LDP is used to signal a PW type of 0x0001 (Frame Relay DLCI), does > >>that correspond to the "one-to-one" mode or "port mode" encapsulation > >>(from draft-ietf-pwe3-frame-relay-00.txt (if that's the current one))? > >>[ATM PW over MPLS] > >>3. Do LDP PW types 0x9 (ATM VCC cell transport) and 0xa (ATM VPC cell > >>transport) refer to "one-to-one" mode or "n-to-one" mode encaps (from > >>draft-ietf-pwe3-atm-encap-00.txt)? Section 4.2.3 reads: "Every cell that > >>is received... is encapsulated according to [10], ATM cell mode...", but > >>"ATM cell mode" does not zero in on a specific section from atm-encap > >>draft. I figure it's n-to-one, but I would like confirmation. > >> > >>Regards, > >>David. > >> > >>_______________________________________________ > >>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 bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:43 2006 From: John Fischer Subject: Encapsulation types Date: Wed, 12 Feb 2003 09:58:58 -0500 Organization: Alcatel Canada Lines: 21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: pwe3 IETF , PPVPN Working Group X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: john.fischer@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] Status: O I noticed that draft-ietf-pwe3-control-protocol-01.txt uses the same encap type numbers as draft-kompella-ppvpn-l2vpn-02.txt Have these numbers been allocated from the same space? I couldn't find where these were defined (IANA or IETF). The PPVPN draft describes BGP signaling, while the PWE3 draft describes using LDP. Why are different signaling methods proposed in these drafts? Are these signaling methods interchangeable? eg. Is there a good reason why you would not set up an L2 VPN with different edge-facing L2 technologies using PWE3 defined LDP signaling and the PPVPN defined encap type of 64 IP-interworking? I've always been curious, but never asked. Thanks, John From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Wed, 12 Feb 2003 19:00:29 +0000 Organization: Cisco Systems, Inc. Lines: 199 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Metz , Luca Martini , "pwe3@ietf.org" , pwe3-admin@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Matthew.Bocci@alcatel.co.uk Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O There are two halves to the congestion problem: 1) Does the existence of the PW cause congestion on the PSN, and hence break the PSN. 2) Does the existence of congestion on the PSN cause the PW to break. The comments and questions (from me) that Luca quoted were as a result of the ADs specifying that we MUST have a solution to (1). The text (below from ...arch-02) is a re-write of the text that was added to RTP to cover case (1). There is no requirement use TCP or SCTP. The requirement is that if the payload will not automatically react like TCP to congestion loss in the PSN, then a method must me provided whereby an equivalent reduction in the offered traffic reduces in response to PSN congestion "just like TCP". In the case of a bit or cell stream, then I would assume that this must be done by closing one or more PWs when the packet loss reaches some threshold, but any other method that better suits the PW is fine. (2) can only be achieved in practice by a mixture of provisioning and QoS management. If the underlying PSN cannot deliver the necessary QoS performance, then it is not suitable to carry the PW. To some extent the deficiencies of the underlying PSN can be disguised by an NSP function, but this is not always possible. We could run the PW over a reliable transport to improve the QoS of the underlying PSN, but I think that most people agree that the resultant cost in processing resources is unacceptable, and a QoS based approach is the best practical approach. Regards Stewart ------------------------------------------------------------------------- 6.5 Congestion Considerations The PSN carrying the PW may be subject to congestion. The congestion characteristics will vary with the PSN type, the network architecture and configuration, and the loading of the PSN. Where the traffic carried over the PW is known to be TCP friendly (by, for example, packet inspection), packet discard in the PSN will trigger the necessary reduction in offered load, and no additional congestion avoidance action is necessary. If the PW is operating over a PSN that provides enhanced delivery, the PEs SHOULD monitor packet loss to ensure that the service that was requested is actually being delivered. If it is not, then the PE SHOULD assume that the PSN is providing a best-effort service, and SHOULD use the best-effort service congestion avoidance measures described below. If best-effort service is being used and the trafic is not known to be TCP friendly, the PEs SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the PW flow is achieving. This condition can be satisfied by implementing a rate-limiting measure in the NSP, or by shutting down one or more PWs. The choice of which approach to use depends upon the type of traffic being carried. Where congestion is avoided by shutting down a PW, a suitable mechanism MUST be provided to prevent it immediately returning to service, causing a series of congestion pulses. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using PWE3 or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. One method of determining an acceptable PW bandwidth is described in [TFRC]. Matthew.Bocci@alcatel.co.uk wrote: > All, > > Is the implicit assumption here that you cannot characterise the PW > traffic sufficiently to provision the PSN so that it behaves in a way that > the end-to-end layer 2 service can be sustained? For example, many > protocols e.g. ATM, were originally designed with the assumption that > packet loss in the underlying network (usually SONET/SDH) is very low. > Even if you built in some form of closed loop congestion control for the > PW, you still need to provision the PSN to allow the QoS objectives of the > end-to-end service to be met. > > Cheers, > > Matthew > ----------------------------------------- > Matthew Bocci > Office of the CTO > Alcatel Fixed Networks Division > ----------------------------------------- > > > > > Chris Metz > Sent by: pwe3-admin@ietf.org > 12/02/2003 11:58 > > > To: Luca Martini > cc: stbryant@cisco.com, "pwe3@ietf.org" > Subject: Re: [PWE3] PWE3 congestion > > > At 06:42 PM 2/11/2003 -0700, Luca Martini wrote: > >>it sounds like a reasonable approach. >>It would be nice to point out somewhere that the several PW layer2 >>payloads assume 100% delivery , and therefore PW should probably be run >>over a PSN that can guarantee 100% frame delivery for the pw class of > > service. > > Does such a PSN operating a today's speeds exist :-) > > Getting back to the notion of PWE3 congestion control I too am intrigued. > The approach with TCP-style traffic operating over the PW is the correct > one. Regarding traffic of unknown provenance the question would be how to > implement the feedback loop so that the ingress PE is make aware of > congestion and can take appropriate action. I am presuming we are not > talking about encapsulating PWs in TCP/SCTP sessions between the PW > end-points :-) so it seems we need what some sort of ABR-style closed > loop? > > Cheers ... > > > > > >>Luca >> >> >>Stewart Bryant wrote: >> >>>I am looking at the congestion section of the arch >>>revision (we need one). It seems to me that we can divide the >>>problem up into two traffic classes: >>>o Traffic known (perhaps by SLA, perhaps by audit) to be TCP >>>friendly >>>o Traffic of unknown provenance >>>In the former case we need do nothing. Natural packet discard >>>will feed back to the transport layer, and the right things >>>will happen. I include in this case IP over packet PW, and IP >>>over ATM PW. I propose that the term "TCP friendly" be left >>>sufficiently general that it covers any IETF transport (they >>>are all supposed to be TCP friendly), and other similar >>>transports such as TP4 (if it still exists). >>>For the "traffic of unknown provenance", it seems to me that >>> >>>could be used to calculate the maximum offered load, and >>>the PE would then be required to maintain it's load below >>>this rate (if necessary by shutting down PWs). The >>>statistics needed to operate this algorithm look a bit >>>daunting for a forwarding system, but presumably >>>some stastical view of the counters, a priori knowledge >>>of the bit rate etc would simplify things. >>>Has anyone elso looked at this, and does it seem like the >>>right way to go? >>>Stewart >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Thu, 13 Feb 2003 12:26:15 +0200 Lines: 263 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Chris Metz , Luca Martini , pwe3@ietf.org, pwe3-admin@ietf.org, Matthew.Bocci@alcatel.co.uk Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, February 12, 2003 9:00 PM > To: Matthew.Bocci@alcatel.co.uk > Cc: Chris Metz; Luca Martini; pwe3@ietf.org; pwe3-admin@ietf.org > Subject: Re: [PWE3] PWE3 congestion > > > > There are two halves to the congestion problem: > > 1) Does the existence of the PW cause congestion on the PSN, and > hence break the PSN. > > 2) Does the existence of congestion on the PSN cause the PW > to break. > > The comments and questions (from me) that Luca quoted were as > a result of the ADs specifying that we MUST have a solution > to (1). The text (below from ...arch-02) is a re-write of the > text that was added to RTP to cover case (1). There is no > requirement use TCP or SCTP. The requirement is that if the > payload will not automatically react like TCP to congestion > loss in the PSN, then a method must me provided whereby an > equivalent reduction in the offered traffic reduces in response > to PSN congestion "just like TCP". In the case of a bit or > cell stream, then I would assume that this must be done by > closing one or more PWs when the packet loss reaches some > threshold, but any other method that better suits the PW > is fine. > I do not think that proposed behavior is "just like TCP". TCP connections do not usually disconnect themselves under congestion (even if a frustrated user may do so if the connection looks stuck). On the other hand, I do not see any other way to treat congestion in PWs that are associated with CBR-like traffic. > > (2) can only be achieved in practice by a mixture of provisioning > and QoS management. If the underlying PSN cannot deliver the necessary > QoS performance, then it is not suitable to carry the PW. To some > extent the deficiencies of the underlying PSN can be disguised > by an NSP function, but this is not always possible. > We could run the PW over a reliable transport to improve the > QoS of the underlying PSN, but I think that most people agree that > the resultant cost in processing resources is unacceptable, and > a QoS based approach is the best practical approach. > > Regards > > Stewart > > > -------------------------------------------------------------- > ----------- > 6.5 Congestion Considerations > > The PSN carrying the PW may be subject to congestion. The > congestion > characteristics will vary with the PSN type, the network > architecture > and configuration, and the loading of the PSN. > > Where the traffic carried over the PW is known to be TCP friendly > (by, for example, packet inspection), packet discard in > the PSN will > trigger the necessary reduction in offered load, and no additional > congestion avoidance action is necessary. > > If the PW is operating over a PSN that provides enhanced delivery, > the PEs SHOULD monitor packet loss to ensure that the service that > was requested is actually being delivered. If it is not, > then the PE > SHOULD assume that the PSN is providing a best-effort service, and > SHOULD use the best-effort service congestion avoidance measures > described below. > > If best-effort service is being used and the trafic is > not known to > be TCP friendly, the PEs SHOULD monitor packet loss to ensure that > the packet loss rate is within acceptable parameters. > Packet loss is > considered acceptable if a TCP flow across the same > network path and > experiencing the same network conditions would achieve an average > throughput, measured on a reasonable timescale, that is > not less than > the PW flow is achieving. This condition can be satisfied by > implementing a rate-limiting measure in the NSP, or by > shutting down > one or more PWs. The choice of which approach to use depends upon > the type of traffic being carried. Where congestion is avoided by > shutting down a PW, a suitable mechanism MUST be provided > to prevent > it immediately returning to service, causing a series of > congestion > pulses. > > The comparison to TCP cannot be specified exactly, but is > intended as > an "order-of-magnitude" comparison in timescale and > throughput. The > timescale on which TCP throughput is measured is the > round-trip time > of the connection. In essence, this requirement states > that it is not > acceptable to deploy an application (using PWE3 or any other > transport protocol) on the best-effort Internet which consumes > bandwidth arbitrarily and does not compete fairly with > TCP within an > order of magnitude. One method of determining an acceptable PW > bandwidth is described in [TFRC]. > > > > > > > > > Matthew.Bocci@alcatel.co.uk wrote: > > All, > > > > Is the implicit assumption here that you cannot characterise the PW > > traffic sufficiently to provision the PSN so that it > behaves in a way that > > the end-to-end layer 2 service can be sustained? For example, many > > protocols e.g. ATM, were originally designed with the > assumption that > > packet loss in the underlying network (usually SONET/SDH) > is very low. > > Even if you built in some form of closed loop congestion > control for the > > PW, you still need to provision the PSN to allow the QoS > objectives of the > > end-to-end service to be met. > > > > Cheers, > > > > Matthew > > ----------------------------------------- > > Matthew Bocci > > Office of the CTO > > Alcatel Fixed Networks Division > > ----------------------------------------- > > > > > > > > > > Chris Metz > > Sent by: pwe3-admin@ietf.org > > 12/02/2003 11:58 > > > > > > To: Luca Martini > > cc: stbryant@cisco.com, "pwe3@ietf.org" > > Subject: Re: [PWE3] PWE3 congestion > > > > > > At 06:42 PM 2/11/2003 -0700, Luca Martini wrote: > > > >>it sounds like a reasonable approach. > >>It would be nice to point out somewhere that the several PW layer2 > >>payloads assume 100% delivery , and therefore PW should > probably be run > >>over a PSN that can guarantee 100% frame delivery for the > pw class of > > > > service. > > > > Does such a PSN operating a today's speeds exist :-) > > > > Getting back to the notion of PWE3 congestion control I too > am intrigued. > > The approach with TCP-style traffic operating over the PW > is the correct > > one. Regarding traffic of unknown provenance the question > would be how to > > implement the feedback loop so that the ingress PE is make aware of > > congestion and can take appropriate action. I am presuming > we are not > > talking about encapsulating PWs in TCP/SCTP sessions between the PW > > end-points :-) so it seems we need what some sort of > ABR-style closed > > loop? > > > > Cheers ... > > > > > > > > > > > >>Luca > >> > >> > >>Stewart Bryant wrote: > >> > >>>I am looking at the congestion section of the arch > >>>revision (we need one). It seems to me that we can divide the > >>>problem up into two traffic classes: > >>>o Traffic known (perhaps by SLA, perhaps by audit) to be TCP > >>>friendly > >>>o Traffic of unknown provenance > >>>In the former case we need do nothing. Natural packet discard > >>>will feed back to the transport layer, and the right things > >>>will happen. I include in this case IP over packet PW, and IP > >>>over ATM PW. I propose that the term "TCP friendly" be left > >>>sufficiently general that it covers any IETF transport (they > >>>are all supposed to be TCP friendly), and other similar > >>>transports such as TP4 (if it still exists). > >>>For the "traffic of unknown provenance", it seems to me that > >>> > >>>could be used to calculate the maximum offered load, and > >>>the PE would then be required to maintain it's load below > >>>this rate (if necessary by shutting down PWs). The > >>>statistics needed to operate this algorithm look a bit > >>>daunting for a forwarding system, but presumably > >>>some stastical view of the counters, a priori knowledge > >>>of the bit rate etc would simplify things. > >>>Has anyone elso looked at this, and does it seem like the > >>>right way to go? > >>>Stewart > >>>_______________________________________________ > >>>pwe3 mailing list > >>>pwe3@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Thu, 13 Feb 2003 11:22:50 +0000 Organization: Cisco Systems, Inc. Lines: 46 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Sasha Vainshtein Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, Please see a brief response inline: >> >>There are two halves to the congestion problem: >> >>1) Does the existence of the PW cause congestion on the PSN, and >>hence break the PSN. >> >>2) Does the existence of congestion on the PSN cause the PW >>to break. >> >>The comments and questions (from me) that Luca quoted were as >>a result of the ADs specifying that we MUST have a solution >>to (1). The text (below from ...arch-02) is a re-write of the >>text that was added to RTP to cover case (1). There is no >>requirement use TCP or SCTP. The requirement is that if the >>payload will not automatically react like TCP to congestion >>loss in the PSN, then a method must me provided whereby an >>equivalent reduction in the offered traffic reduces in response >>to PSN congestion "just like TCP". In the case of a bit or >>cell stream, then I would assume that this must be done by >>closing one or more PWs when the packet loss reaches some >>threshold, but any other method that better suits the PW >>is fine. >> > > I do not think that proposed behavior is "just like TCP". > TCP connections do not usually disconnect themselves > under congestion (even if a frustrated user may do so > if the connection looks stuck). On the other hand, I > do not see any other way to treat congestion in PWs > that are associated with CBR-like traffic. > It is "TCP like" in that the transport (PW) significantly reduces the offered load in the presence of network congestion (as detected by packet loss), and that it refrains from trying to increase the offered load until a suitable cooling off period has elapsed. In the case of TCP the offered load is regulated by the window size and the acknowledgment delay. In the PW case it is regulated by the PW bandwidth. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Philip Chimento Subject: Re: PWE3 congestion Date: Thu, 13 Feb 2003 09:14:17 -0500 Lines: 33 Sender: pwe3-admin@ietf.org References: <3E4B800A.4020003@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sasha Vainshtein , "pwe3@ietf.org" Return-path: X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: stbryant@cisco.com In-reply-to: stbryant's message of Thu, 13 Feb 2003 11:22:50 +0000. <3E4B800A.4020003@cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O One thing you have to remember is that TCP is in some sense 'greedy' in that it will keep probing to find the max load that it can offer (i.e. the max rate at which it can transmit). It seems to me that with PWs, especially if you want to do circuit emulation, that the following points hold: 1) Your options for squeezing the rate down are very limited, otherwise you lose the value of the service; i.e. you start to underrun your playout buffer severely. 2) You don't have a continuum of rates to work with, again I am referring mostly to circuit emulation, in the sense that you cannot reduce the bandwidth by arbitrary amounts. You cannot reduce the bandwidth in this case by 1/2 for example (which, of course, TCP can). This argues that you congestion control, at least for circuit emulation PWs, should be removal of some wires. 3) You cannot re-introduce load in small increments. If you want to re-introduce a PW after congestion has cleared, you will have to know either that flows that you share the bottleneck link with will adjust to the bandwidth that the PW re-introduces or that there is sufficient slack (i.e. underutilization) that will accomodate the new PW. Non-trivial problems.... Regards, Phil Chimento -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 congestion Date: Thu, 13 Feb 2003 16:32:35 -0000 Lines: 95 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Sasha@axerra.com, pwe3@ietf.org Return-path: To: chimento@torrentnet.com, stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Philip...I totally agree with you, these are indeed 'non-trivial problems'. However, speaking as an operator, and considering *if* it will be possible to migrate technologies like ATM and FR to a common MPLS core, I see it as far worse than this. Consider these factors: We should be defining proper client/server layer network relationships such that they are functionally independent (and we sure need this for arbitrary XoverMPLS), ie both the client layer network and the server layer network must be functionally self-sufficient and decoupled. This is an obvious requirement IMO to allow flexible/arbitrary client/server relationships to exist, and to allow layer network technologies to be developed/sunsetted independently. I consider even the adding of sequence numbers to the 'control word' to be a error of judgement.....it strikes me that this is standardising a broken implementation of the server layer (esp in case of MPLS). If these are retained then I would expect to see some defect detection/handling procedures specified for SN aberrations.....which seems, in one respect (but not all), to be a concern of the ADs here (though I note they are actually more worried about protecting the public Internet, which is fair enough from their perspective.....but its not sufficient from mine as an operator). Similarly, if anyone adds anything else to the control-word (or anything that can be considered as lying somewhere between the client and the server layer) which is *not* simply client/server adaptation (see that dirty-word G.805), then this too will need 'managing'. I even hear a rumour that a large router vendor wants to add an OAM function here....if true, this would really be stupid. PWE3 are in danger of setting off on the road (in fact they are already on it) of defining new layer networks. I would not advise going there....we have enough layer networks as it is (and some of these are not well specified functionally) without adding more. If the server layer is IP then we should make sure IP can be managed properly. If the server layer is MPLS make sure this can be managed properly. This is the right answer. I don't think its a good idea to keep adding 'fixes' to this 'in-between' layer......this should really only be a simple adaptation function IMO. regards, Neil > -----Original Message----- > From: Philip Chimento [mailto:chimento@torrentnet.com] > Sent: 13 February 2003 14:14 > To: stbryant@cisco.com > Cc: Sasha Vainshtein; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 congestion > > > One thing you have to remember is that TCP is in some sense > 'greedy' in > that > it will keep probing to find the max load that it can offer (i.e. the > max > rate at which it can transmit). It seems to me that with PWs, > especially if > you want to do circuit emulation, that the following points hold: > > 1) Your options for squeezing the rate down are very limited, > otherwise > you lose > the value of the service; i.e. you start to underrun your playout > buffer severely. > 2) You don't have a continuum of rates to work with, again I am > referring mostly to circuit emulation, in the sense that you cannot > reduce the bandwidth by arbitrary amounts. You cannot reduce the > bandwidth in this case by 1/2 for example (which, of course, > TCP can). > This argues that you congestion control, at least for circuit > emulation > PWs, should be removal of some wires. > 3) You cannot re-introduce load in small increments. If you want to > re-introduce a PW after congestion has cleared, you will have to know > either that flows that you share the bottleneck link with will adjust > to the bandwidth that the PW re-introduces or that there is > sufficient > slack (i.e. underutilization) that will accomodate the new PW. > > Non-trivial problems.... > > Regards, Phil Chimento > > -- > Phil Chimento Ericsson IPI > Phone: 240-314-3597 7301 Calhoun Place > chimento@torrentnet.com Rockville, Md. 20855 > ----------------------------------------------------- > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Thu, 13 Feb 2003 16:49:40 +0000 Organization: Cisco Systems, Inc. Lines: 113 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389014CFF97@i2km07-ukbr.domain1.systemhost.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O neil.2.harrison@bt.com wrote: > Philip...I totally agree with you, these are indeed 'non-trivial problems'. > However, speaking as an operator, and considering *if* it will be possible > to migrate technologies like ATM and FR to a common MPLS core, I see it as > far worse than this. Consider these factors: > > We should be defining proper client/server layer network relationships such > that they are functionally independent (and we sure need this for arbitrary > XoverMPLS), ie both the client layer network and the server layer network > must be functionally self-sufficient and decoupled. This is an obvious > requirement IMO to allow flexible/arbitrary client/server relationships to > exist, and to allow layer network technologies to be developed/sunsetted > independently. > > I consider even the adding of sequence numbers to the 'control word' to be a > error of judgement.....it strikes me that this is standardising a broken > implementation of the server layer (esp in case of MPLS). If these are > retained then I would expect to see some defect detection/handling > procedures specified for SN aberrations.....which seems, in one respect (but > not all), to be a concern of the ADs here (though I note they are actually > more worried about protecting the public Internet, which is fair enough from > their perspective.....but its not sufficient from mine as an operator). > > Similarly, if anyone adds anything else to the control-word (or anything > that can be considered as lying somewhere between the client and the server > layer) which is *not* simply client/server adaptation (see that dirty-word > G.805), then this too will need 'managing'. I even hear a rumour that a > large router vendor wants to add an OAM function here....if true, this would > really be stupid. > > PWE3 are in danger of setting off on the road (in fact they are already on > it) of defining new layer networks. I would not advise going there....we > have enough layer networks as it is (and some of these are not well > specified functionally) without adding more. > > If the server layer is IP then we should make sure IP can be managed > properly. If the server layer is MPLS make sure this can be managed > properly. This is the right answer. I don't think its a good idea to keep > adding 'fixes' to this 'in-between' layer......this should really only be a > simple adaptation function IMO. What exactly do you mean by "managed properly"? The requirement that MUST be addressed is to have a mechnanism that in real time protects the network core from congestion collapse in a fair way. In the case of non-TCP friendly traffic what is your technical proposal for the design of an alternative congestion back-off mechnism? Stewart > regards, Neil > > > >>-----Original Message----- >>From: Philip Chimento [mailto:chimento@torrentnet.com] >>Sent: 13 February 2003 14:14 >>To: stbryant@cisco.com >>Cc: Sasha Vainshtein; pwe3@ietf.org >>Subject: Re: [PWE3] PWE3 congestion >> >> >>One thing you have to remember is that TCP is in some sense >>'greedy' in >>that >>it will keep probing to find the max load that it can offer (i.e. the >>max >>rate at which it can transmit). It seems to me that with PWs, >>especially if >>you want to do circuit emulation, that the following points hold: >> >>1) Your options for squeezing the rate down are very limited, >>otherwise >>you lose >>the value of the service; i.e. you start to underrun your playout >>buffer severely. >>2) You don't have a continuum of rates to work with, again I am >>referring mostly to circuit emulation, in the sense that you cannot >>reduce the bandwidth by arbitrary amounts. You cannot reduce the >>bandwidth in this case by 1/2 for example (which, of course, >>TCP can). >>This argues that you congestion control, at least for circuit >>emulation >>PWs, should be removal of some wires. >>3) You cannot re-introduce load in small increments. If you want to >>re-introduce a PW after congestion has cleared, you will have to know >>either that flows that you share the bottleneck link with will adjust >>to the bandwidth that the PW re-introduces or that there is >>sufficient >>slack (i.e. underutilization) that will accomodate the new PW. >> >>Non-trivial problems.... >> >>Regards, Phil Chimento >> >>-- >>Phil Chimento Ericsson IPI >>Phone: 240-314-3597 7301 Calhoun Place >>chimento@torrentnet.com Rockville, Md. 20855 >>----------------------------------------------------- >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 congestion Date: Thu, 13 Feb 2003 17:23:18 -0000 Lines: 33 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: To: stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, please see below, regards, Neil Stewart Bryant wrote 13 February 2003 16:50 > > What exactly do you mean by "managed properly"? NH=> Simply this: If there is a client/server relationship between 2 layer network technologies X/Y say, then its important that both X and Y can be operated/managed as layer networks in their own right. So this embraces all the functional components one requires to do this, eg addressing, routing, signalling (not cnls obviously), fault-management, traffic management, performance management, etc. In particular one should not be asking a given layer network (be it client or server to some other layer network) to proxy for functional deficiences in the other layer network....and in the specific case here there is an 'in-between' layer network that seems to be being created that looks like its taking on some of these proxying functions. > > The requirement that MUST be addressed is to have a mechnanism that in > real time protects the network core from congestion collapse in a > fair way. > > In the case of non-TCP friendly traffic what is your > technical proposal > for the design of an alternative congestion back-off mechnism? NH=>The solution for protecting the network (get the source to slow down) is not trivial as Philip pointed out. How do you tell an ATM connection to slow down? How do you tell a circuit emulation T1/E1 to slow down? One way of addressing this is via signalling and CAC for known client demands on the server.....but of course it assumes these functions are available/specified in the server.....if they are not then perhaps one should not be doing this? From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Thu, 13 Feb 2003 11:18:27 -0800 Lines: 44 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: To: "'stbryant@cisco.com'" , neil.2.harrison@bt.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > In the case of non-TCP friendly traffic what is your > technical proposal > for the design of an alternative congestion back-off mechnism? > > Hi, A PW may be carrying a fixed BW traffic (CBR, like TDM) or it may be carrying variable BW traffic that requires committed rate and excess rate such as FR. In the former case Neil is correct to suggest that CAC, policing and resource reservation should be used and that if these are done properly these types of PW won't effectively cause any congestion in the PSN. This is what Luca and Sasha were referring to. The second type of traffic, requires resource reservation, CAC and policing for the committed rate, but not necessarily for the excess rate. This type of PW may in fact cause congestion in the PSN. The most logical approach is to inform the ingress PE (and not the customer) about the congestion and let the ingress PE either cut the excess traffic or may be even reroute it. Mechanisms such as those in RFC 3168 (IP ECN), may be used, but it only identifies the congestion to the egress (i.e., forward congestion notification). Two other method are at least possible: 1) Define congestion notification packets and generate them at the interior nodes toward the egress. For example if the PSN is MPLS, then interior nodes may generate a packet that has the same PSN header as the user packet (ie, same labels) but has a PW or IP header that identifies it as a congestion notification packet. In fact this packet may look very similar to MPLS-ping (with different UDP port #). The egress, upon receiving the EFCN packet may generate a BECN packet toward the ingress. 2) Use the NMS and the MIBs counters and have a threshold that triggers a message to all ingress nodes and informs them of congestion in that node. The ingress nodes could then use that info to either cut the excess traffic or reroute them. This method requires TE be used but is more scalable than (1). My 2c, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Philip Chimento Subject: Re: PWE3 congestion Date: Thu, 13 Feb 2003 14:16:29 -0500 Lines: 21 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389014CFF99@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stbryant@cisco.com, Sasha@axerra.com, pwe3@ietf.org Return-path: X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: neil.2.harrison@bt.com In-reply-to: neil.2.harrison's message of Thu, 13 Feb 2003 17:23:18 +0000. <0536FC9B908BEC4597EE721BE6A35389014CFF99@i2km07-ukbr.domain1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Actually, I wasn't pointing out that these problems are non-trivial to say that they can't be solved, just that they are hard, and that (I think) a different approach from that of TCP needs to be considered. You can't make circuit emulation "TCP-friendly" because of the characteristics that they have due to the service they provide. Neil's points about the management of different layers are well-taken, but rather different points. I was just trying to start a discussion on the order of "what would a good solution look like?" Regards, Phil Chimento -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Thu, 13 Feb 2003 11:42:13 -0800 Lines: 143 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Return-path: To: "'John Fischer'" , "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O John, > -----Original Message----- > From: John Fischer [mailto:john.fischer@alcatel.com] > Sent: Tuesday, February 11, 2003 8:57 AM > To: 'pwe3@ietf.org' > Subject: Re: [PWE3] Questions from > draft-ietf-pwe3-control-protocol-01.txt > > > Hi all, > I would like to request the editors of this draft to make > updates in several areas: > 4.2 ATM > 4.2.1 Describes the N:1 AAL5 mode. Another section with > a description > of the 1:1 AAL5 PDU mode is needed. My suggestion is to call them SDU mode and PDU mode rather than 1:1 or N:1 AAL5. Because to be honest you can't encapsulate Nx SDUs in a single packet. > 4.2.3 Does this section intend to describe the 1:1 VCC, 1:1 VPC > encapsulation modes? If so, it should clearly indicate so. > If not, it should specify N:1 and another section for > 1:1 cell mode > as well as new PW types should be added to the document. I think this section looks generic and applies to both 1:1 and N:1 cell modes. May be a sentence is needed to clarify. > > In order to be clear, the list of PW types in section 5 should also be > updated: > 0x0002 ATM AAL5 VCC transport <<< ADD N:1 IN NAME > 0x0003 ATM transparent cell transport <<< > ADD N:1 IN NAME > 0x0009 ATM VCC cell transport <<< ADD 1:1 IN NAME > 0x000A ATM VPC cell transport <<< ADD 1:1 IN NAME Again I suggest SDU rather than N:1 AAL5 VCC . And there is a need for 3 other code points: 0x000B PDU frame transport 0x000C N:1 ATM VCC cell transport 0x000D N:1 ATM VPC cell transport My suggestion is to add one more codepoint for TDM too: 0x000E N:1 ATM VPC cell transport Yours, -Shahram > Thanks, > John > > Matthew.Bocci@alcatel.co.uk wrote: > > > David, > > > > Regarding point 3 below, the way the draft is written, it > could be either > > one-to-one or n-to-one (although n-to-one is mandatory to > support). Also, > > the draft only mentions SDU mode for encapsulation of AAL5 > frames, but in > > fact this could also be done using PDU encapsulation, for > the reasons > > discussed in the applicability sections of > draft-ietf-pwe3-atm-encap-00.txt. > > > > I believe that draft-ietf-pwe3-control-protocol-01.txt > should provide > > support for all of the ATM encap modes, whether mandatory > or optional. > > > > Best regards, > > > > Matthew > > > > ----------------------------------------- > > Matthew Bocci > > Office of the CTO > > Alcatel Fixed Networks Division > > ----------------------------------------- > > > > David Clear > > Sent by: pwe3-admin@ietf.org > > 22/01/2003 23:28 > > > > > > To: "'pwe3@ietf.org'" > > cc: > > Subject: [PWE3] Questions from > draft-ietf-pwe3-control-protocol-01.txt > > > > Hi. A few questions I hope you can help with. > > [Frame Relay PW over MPLS] > > 1. Section 4.1 references > draft-ietf-pwe3-frame-encap-01.txt, but I can't > > seem to find that draft (nor an -00 version). Has it been > superceded by > > draft-ietf-pwe3-frame-relay-00.txt? > > 2. If LDP is used to signal a PW type of 0x0001 (Frame > Relay DLCI), does > > that correspond to the "one-to-one" mode or "port mode" > encapsulation > > (from draft-ietf-pwe3-frame-relay-00.txt (if that's the > current one))? > > [ATM PW over MPLS] > > 3. Do LDP PW types 0x9 (ATM VCC cell transport) and 0xa > (ATM VPC cell > > transport) refer to "one-to-one" mode or "n-to-one" mode > encaps (from > > draft-ietf-pwe3-atm-encap-00.txt)? Section 4.2.3 reads: > "Every cell that > > is received... is encapsulated according to [10], ATM cell > mode...", but > > "ATM cell mode" does not zero in on a specific section from > atm-encap > > draft. I figure it's n-to-one, but I would like confirmation. > > > > Regards, > > David. > > > > _______________________________________________ > > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: John Fischer Subject: Re: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Thu, 13 Feb 2003 14:49:37 -0500 Organization: Alcatel Canada Lines: 145 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03C9D@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Shahram, I agree. John Shahram Davari wrote: > John, > > > -----Original Message----- > > From: John Fischer [mailto:john.fischer@alcatel.com] > > Sent: Tuesday, February 11, 2003 8:57 AM > > To: 'pwe3@ietf.org' > > Subject: Re: [PWE3] Questions from > > draft-ietf-pwe3-control-protocol-01.txt > > > > > > Hi all, > > I would like to request the editors of this draft to make > > updates in several areas: > > 4.2 ATM > > 4.2.1 Describes the N:1 AAL5 mode. Another section with > > a description > > of the 1:1 AAL5 PDU mode is needed. > > My suggestion is to call them SDU mode and PDU mode rather than > 1:1 or N:1 AAL5. Because to be honest you can't encapsulate Nx SDUs in a > single packet. > > > 4.2.3 Does this section intend to describe the 1:1 VCC, 1:1 VPC > > encapsulation modes? If so, it should clearly indicate so. > > If not, it should specify N:1 and another section for > > 1:1 cell mode > > as well as new PW types should be added to the document. > > I think this section looks generic and applies to both 1:1 and N:1 > cell modes. May be a sentence is needed to clarify. > > > > > In order to be clear, the list of PW types in section 5 should also be > > updated: > > 0x0002 ATM AAL5 VCC transport <<< ADD N:1 IN NAME > > 0x0003 ATM transparent cell transport <<< > > ADD N:1 IN NAME > > 0x0009 ATM VCC cell transport <<< ADD 1:1 IN NAME > > 0x000A ATM VPC cell transport <<< ADD 1:1 IN NAME > > Again I suggest SDU rather than N:1 AAL5 VCC . And there is a need for 3 other code points: > > 0x000B PDU frame transport > 0x000C N:1 ATM VCC cell transport > 0x000D N:1 ATM VPC cell transport > > My suggestion is to add one more codepoint for TDM too: > > 0x000E N:1 ATM VPC cell transport > > Yours, > -Shahram > > > Thanks, > > John > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > David, > > > > > > Regarding point 3 below, the way the draft is written, it > > could be either > > > one-to-one or n-to-one (although n-to-one is mandatory to > > support). Also, > > > the draft only mentions SDU mode for encapsulation of AAL5 > > frames, but in > > > fact this could also be done using PDU encapsulation, for > > the reasons > > > discussed in the applicability sections of > > draft-ietf-pwe3-atm-encap-00.txt. > > > > > > I believe that draft-ietf-pwe3-control-protocol-01.txt > > should provide > > > support for all of the ATM encap modes, whether mandatory > > or optional. > > > > > > Best regards, > > > > > > Matthew > > > > > > ----------------------------------------- > > > Matthew Bocci > > > Office of the CTO > > > Alcatel Fixed Networks Division > > > ----------------------------------------- > > > > > > David Clear > > > Sent by: pwe3-admin@ietf.org > > > 22/01/2003 23:28 > > > > > > > > > To: "'pwe3@ietf.org'" > > > cc: > > > Subject: [PWE3] Questions from > > draft-ietf-pwe3-control-protocol-01.txt > > > > > > Hi. A few questions I hope you can help with. > > > [Frame Relay PW over MPLS] > > > 1. Section 4.1 references > > draft-ietf-pwe3-frame-encap-01.txt, but I can't > > > seem to find that draft (nor an -00 version). Has it been > > superceded by > > > draft-ietf-pwe3-frame-relay-00.txt? > > > 2. If LDP is used to signal a PW type of 0x0001 (Frame > > Relay DLCI), does > > > that correspond to the "one-to-one" mode or "port mode" > > encapsulation > > > (from draft-ietf-pwe3-frame-relay-00.txt (if that's the > > current one))? > > > [ATM PW over MPLS] > > > 3. Do LDP PW types 0x9 (ATM VCC cell transport) and 0xa > > (ATM VPC cell > > > transport) refer to "one-to-one" mode or "n-to-one" mode > > encaps (from > > > draft-ietf-pwe3-atm-encap-00.txt)? Section 4.2.3 reads: > > "Every cell that > > > is received... is encapsulated according to [10], ATM cell > > mode...", but > > > "ATM cell mode" does not zero in on a specific section from > > atm-encap > > > draft. I figure it's n-to-one, but I would like confirmation. > > > > > > Regards, > > > David. > > > > > > _______________________________________________ > > > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: OAM/RM cell handling in martini draft Date: Thu, 13 Feb 2003 12:04:00 -0800 Lines: 74 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D39B.0CE71E60" Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2D39B.0CE71E60 Content-Type: text/plain; charset="iso-8859-1" Hi, It seems that in case of PDU mode the draft says OAM/RM cells should be transported using the ATM VCC cell mode. First of all it is not clear whether this means N:1 or 1:1 cell modes. Secondly assuming that the intent is to use 1:1 cell mode, there is still a difference between 1:1 cell mode header and PDU frame mode header. This means that some packets in an LSP have different format, which makes the processing a bit complicated. My suggestion is: 1) Either make the header format the same for 1:1 and PDU mode (just replace FRAG with PTI), or 2) Send the OAM/RM cells in PDU mode and redefine the M-bit to mean OAM/RM cell. Yours, Shahram ------_=_NextPart_001_01C2D39B.0CE71E60 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
It seems that in case of PDU mode the draft says OAM/RM cells should be transported using
the ATM VCC cell mode. First of all it is not clear whether this means N:1 or 1:1 cell modes. Secondly
assuming that the intent is to use 1:1 cell mode, there is still a difference between 1:1 cell mode header
and PDU frame mode header. This means that some packets in an LSP have different format, which
makes the processing a bit complicated.
 
My suggestion is:
 
1) Either make the header format the same for 1:1 and PDU mode (just replace FRAG with PTI), or
2) Send the OAM/RM cells in PDU mode and redefine the M-bit to mean OAM/RM cell.
 
Yours,
Shahram
 
------_=_NextPart_001_01C2D39B.0CE71E60-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Thu, 13 Feb 2003 20:06:37 +0000 Organization: Cisco Systems, Inc. Lines: 53 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389014CFF99@i2km07-ukbr.domain1.systemhost.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O neil.2.harrison@bt.com wrote: > Stewart, please see below, regards, Neil > > Stewart Bryant wrote 13 February 2003 16:50 > > > >>What exactly do you mean by "managed properly"? > > NH=> Simply this: If there is a client/server relationship between 2 layer > network technologies X/Y say, then its important that both X and Y can be > operated/managed as layer networks in their own right. So this embraces all > the functional components one requires to do this, eg addressing, routing, > signalling (not cnls obviously), fault-management, traffic management, > performance management, etc. In particular one should not be asking a given > layer network (be it client or server to some other layer network) to proxy > for functional deficiences in the other layer network....and in the specific > case here there is an 'in-between' layer network that seems to be being > created that looks like its taking on some of these proxying functions. > ...and I think that the architecture uses this functional partitioning because the only sub-system that is allowed to modulate (by any method) the payload flow is the NSP, which is part of what you call the client network. >>The requirement that MUST be addressed is to have a mechnanism that in >>real time protects the network core from congestion collapse in a >>fair way. >> >>In the case of non-TCP friendly traffic what is your >>technical proposal >>for the design of an alternative congestion back-off mechnism? > > NH=>The solution for protecting the network (get the source to slow down) is > not trivial as Philip pointed out. How do you tell an ATM connection to slow > down? How do you tell a circuit emulation T1/E1 to slow down? > You don't. You set a congestion threshold and if that threshold is exceeded you tear down the PW. > One way of addressing this is via signalling and CAC for known client > demands on the server.....but of course it assumes these functions are > available/specified in the server.....if they are not then perhaps one > should not be doing this? Remember the IESG is not going to approve PW unless there is a method of protecting the Internet from congestion. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Thu, 13 Feb 2003 20:18:30 +0000 Organization: Cisco Systems, Inc. Lines: 20 Sender: pwe3-admin@ietf.org References: <200302131916.h1DJGTV28132@malibu.torrentnet.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: neil.2.harrison@bt.com, Sasha@axerra.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Philip Chimento Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Philip Chimento wrote: > Actually, I wasn't pointing out that these problems are non-trivial to > say that they can't > be solved, just that they are hard, and that (I think) a different > approach from that of > TCP needs to be considered. You can't make circuit emulation > "TCP-friendly" because of the characteristics that they have due to the > service they provide. > > Neil's points about the management of different layers are well-taken, > but rather different points. > I was just trying to start a discussion on the order of "what would a > good solution look like?" I put out the original posting to solicit just that feedback, and then when none was received put a baseline proposal in the arch draft. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: John Fischer Subject: Re: OAM/RM cell handling in martini draft Date: Fri, 14 Feb 2003 11:41:59 -0500 Organization: Alcatel Canada Lines: 41 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03C9E@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Shahram, The intention is to use 1:1 VCC cell mode to send the OAM/RM cell. The header is as you suggest in your point 1, "the same for 1:1 and PDU mode (just replace FRAG with PTI)" 1:1 VCC AAL5 PDU |M|V|Res|Frg|E|C| 1:1 VCC Cell |M|V|Res| PTI |C| where the Mode bit (M) is set to 0 if the packet contains an ATM cell. If set to 1, the packet contains an AAL5 payload. John > Shahram Davari wrote: > > Hi, > > It seems that in case of PDU mode the draft says OAM/RM cells should > be transported using > the ATM VCC cell mode. First of all it is not clear whether this means > N:1 or 1:1 cell modes. Secondly > assuming that the intent is to use 1:1 cell mode, there is still a > difference between 1:1 cell mode header > and PDU frame mode header. This means that some packets in an LSP have > different format, which > makes the processing a bit complicated. > > My suggestion is: > > 1) Either make the header format the same for 1:1 and PDU mode (just > replace FRAG with PTI), or > 2) Send the OAM/RM cells in PDU mode and redefine the M-bit to mean > OAM/RM cell. > > Yours, > Shahram > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: OAM/RM cell handling in martini draft Date: Fri, 14 Feb 2003 08:47:43 -0800 Lines: 65 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'pwe3@ietf.org'" Return-path: To: "'John Fischer'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi John, My suggestion (1) was basically to make the PDU mode header the same as cell mode header. Otherwise a single LSP would be carrying a mix of two different modes (formats). The egress processing is not trivial any more, meaning that the egress can't statically parse the packet, rather the parsing needs to be dynamic, meaning the meaning of the fields in the packet now depend on a flag (ie, M). Yours, -Shahram > -----Original Message----- > From: John Fischer [mailto:john.fischer@alcatel.com] > Sent: Friday, February 14, 2003 11:42 AM > To: Shahram Davari > Cc: 'pwe3@ietf.org' > Subject: Re: [PWE3] OAM/RM cell handling in martini draft > > > Hi Shahram, > The intention is to use 1:1 VCC cell mode to send > the OAM/RM cell. The header is as you suggest in > your point 1, "the same for 1:1 and PDU mode (just > replace FRAG with PTI)" > > 1:1 VCC AAL5 PDU > |M|V|Res|Frg|E|C| > > 1:1 VCC Cell > |M|V|Res| PTI |C| > > where the Mode bit (M) is set to 0 if the packet > contains an ATM cell. If set to 1, the packet > contains an AAL5 payload. > John > > > Shahram Davari wrote: > > > > Hi, > > > > It seems that in case of PDU mode the draft says OAM/RM cells should > > be transported using > > the ATM VCC cell mode. First of all it is not clear whether > this means > > N:1 or 1:1 cell modes. Secondly > > assuming that the intent is to use 1:1 cell mode, there is still a > > difference between 1:1 cell mode header > > and PDU frame mode header. This means that some packets in > an LSP have > > different format, which > > makes the processing a bit complicated. > > > > My suggestion is: > > > > 1) Either make the header format the same for 1:1 and PDU mode (just > > replace FRAG with PTI), or > > 2) Send the OAM/RM cells in PDU mode and redefine the M-bit to mean > > OAM/RM cell. > > > > Yours, > > Shahram > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: John Fischer Subject: Re: OAM/RM cell handling in martini draft Date: Fri, 14 Feb 2003 11:58:09 -0500 Organization: Alcatel Canada Lines: 73 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CAA@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Shahram, This is the side effect of carrying cells on a fram mode connection. Yes, the Mode bit needs to be parsed, that's why its there. John Shahram Davari wrote: > > Hi John, > > My suggestion (1) was basically to make the PDU mode header > the same as cell mode header. Otherwise a single LSP would be > carrying a mix of two different modes (formats). The egress > processing is not trivial any more, meaning that the egress > can't statically parse the packet, rather the parsing needs to > be dynamic, meaning the meaning of the fields in the packet > now depend on a flag (ie, M). > > Yours, > -Shahram > > > -----Original Message----- > > From: John Fischer [mailto:john.fischer@alcatel.com] > > Sent: Friday, February 14, 2003 11:42 AM > > To: Shahram Davari > > Cc: 'pwe3@ietf.org' > > Subject: Re: [PWE3] OAM/RM cell handling in martini draft > > > > > > Hi Shahram, > > The intention is to use 1:1 VCC cell mode to send > > the OAM/RM cell. The header is as you suggest in > > your point 1, "the same for 1:1 and PDU mode (just > > replace FRAG with PTI)" > > > > 1:1 VCC AAL5 PDU > > |M|V|Res|Frg|E|C| > > > > 1:1 VCC Cell > > |M|V|Res| PTI |C| > > > > where the Mode bit (M) is set to 0 if the packet > > contains an ATM cell. If set to 1, the packet > > contains an AAL5 payload. > > John > > > > > Shahram Davari wrote: > > > > > > Hi, > > > > > > It seems that in case of PDU mode the draft says OAM/RM cells should > > > be transported using > > > the ATM VCC cell mode. First of all it is not clear whether > > this means > > > N:1 or 1:1 cell modes. Secondly > > > assuming that the intent is to use 1:1 cell mode, there is still a > > > difference between 1:1 cell mode header > > > and PDU frame mode header. This means that some packets in > > an LSP have > > > different format, which > > > makes the processing a bit complicated. > > > > > > My suggestion is: > > > > > > 1) Either make the header format the same for 1:1 and PDU mode (just > > > replace FRAG with PTI), or > > > 2) Send the OAM/RM cells in PDU mode and redefine the M-bit to mean > > > OAM/RM cell. > > > > > > Yours, > > > Shahram > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Jim Harford Subject: Frame format for AAL5 PDU mode Date: Fri, 14 Feb 2003 13:53:16 -0500 Lines: 41 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-path: X-Sender: harford2@atmware.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: pwe3@ietf.org X-Declude-Sender: harford2@atmware.com [209.42.249.73] X-Note: Total weight is 0. Whitelisted Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Does everyone realize that the ATM Forum has changed the definition of its AAL5 PDU header? The FRAG field has been replaced by a reserved bit and a UU field. We believe the new header is backwards-compatible with the old header, but the change allowed us to simplify the explanation of the fields and procedures. This change was first communicated 3 months ago, when str-aic-mpls-niwf-02.01 went to straw ballot. I fully expect the ITU-T to also change their document, as well. Does PWE3 intend to update its working draft? Jim Harford > > > -----Original Message----- > > > From: John Fischer [mailto:john.fischer@alcatel.com] > > > Sent: Friday, February 14, 2003 11:42 AM > > > To: Shahram Davari > > > Cc: 'pwe3@ietf.org' > > > Subject: Re: [PWE3] OAM/RM cell handling in martini draft > > > > > > > > > Hi Shahram, > > > The intention is to use 1:1 VCC cell mode to send > > > the OAM/RM cell. The header is as you suggest in > > > your point 1, "the same for 1:1 and PDU mode (just > > > replace FRAG with PTI)" > > > > > > 1:1 VCC AAL5 PDU > > > |M|V|Res|Frg|E|C| > > > > > > 1:1 VCC Cell > > > |M|V|Res| PTI |C| > > > > > > John > > > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: Frame format for AAL5 PDU mode Date: Fri, 14 Feb 2003 11:04:47 -0800 Lines: 67 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Return-path: To: "'Jim Harford'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Jim, This was also my suggestion in an earlier email, and the responses received have been positive so far. Yours, -Shahram > -----Original Message----- > From: Jim Harford [mailto:harford2@atmware.com] > Sent: Friday, February 14, 2003 1:53 PM > To: pwe3@ietf.org > Subject: [PWE3] Frame format for AAL5 PDU mode > > > > Does everyone realize that the ATM Forum has changed the > definition of its > AAL5 PDU header? The FRAG field has been replaced by a > reserved bit and a > UU field. We believe the new header is backwards-compatible > with the old > header, but the change allowed us to simplify the explanation > of the fields > and procedures. This change was first communicated 3 months > ago, when > str-aic-mpls-niwf-02.01 went to straw ballot. > > I fully expect the ITU-T to also change their document, as > well. Does PWE3 > intend to update its working draft? > > Jim Harford > > > > > > -----Original Message----- > > > > From: John Fischer [mailto:john.fischer@alcatel.com] > > > > Sent: Friday, February 14, 2003 11:42 AM > > > > To: Shahram Davari > > > > Cc: 'pwe3@ietf.org' > > > > Subject: Re: [PWE3] OAM/RM cell handling in martini draft > > > > > > > > > > > > Hi Shahram, > > > > The intention is to use 1:1 VCC cell mode to send > > > > the OAM/RM cell. The header is as you suggest in > > > > your point 1, "the same for 1:1 and PDU mode (just > > > > replace FRAG with PTI)" > > > > > > > > 1:1 VCC AAL5 PDU > > > > |M|V|Res|Frg|E|C| > > > > > > > > 1:1 VCC Cell > > > > |M|V|Res| PTI |C| > > > > > > > > John > > > > > > > > > >_______________________________________________ > >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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "White, Craig (Level 3)" Subject: RE: PWE3 congestion Date: Fri, 14 Feb 2003 13:58:26 -0700 Lines: 114 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , , Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 congestion Thread-Index: AcLTnOsI+MaFqFkyR827r/2LFLY2eAAEKvsw To: , X-OriginalArrivalTime: 14 Feb 2003 20:58:26.0935 (UTC) FILETIME=[D1FC3070:01C2D46B] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EKxcp24211 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, looks like you got your discussion :) I know it wasn't exactly what you're looking for, but hey.... Seems my way of viewing this issue is backwards from conventional views so bear with me here. By this I mean that I view congest avoidance as something that occurs "only" on the senders side, or in our case could potentially only effect 1 direction of the PW. As you stated, we have to address the issue of Internet congestion if for no other reason than a procedural one. So.... My first question is "what exactly happens when "the Internet" congests"? When the "Internet congests", that means that some layer 1 has clocked out some transitions (that we may think of as containing our packet) and this packet will never again be clocked out by any other layer 1. This is not to say that all loss occurs on links, obviously there are issues that occur in a box (buffer overrun, (W)RED dropping) but in anycase, those packets never get clocked out again. Because that packet never gets clocked out again, then, obviously in certain cases, the higher layers (in that intermediate node) aren't necessarily alerted to this loss. Granted, some layer 2's framing methods may be able to detect and even ask for retransmission if the loss if it occurs on links of these certain types, but this is not true in all cases. Since the loss can occur in several places, which may even occur at several different layers, where does that leave us? The important part about the implications of the above, is not exactly what happens, the important part is where something happens, or rather where it doesn't happen. The router that clocked out the packet that never arrives doesn't do something like send "back pressure" towards the edge, rather it relies on the receiver to somehow "signal" the sender to adjust it's output rate. And while you could argue that (w)red is a "kind" of signaling, it effect is still on the edges rather than box/link that's experiencing the problem. Furthermore, the TCP based transmitter doesn't require a positive message (I lost packet X) to cause it to stop transmitting, but also non-receipt will cause the same effect. So for a tcp type connection, the sender "figures out" that further packet transmission is useless and then, several things occur, the most basic one being that the transmission stops, except for the periodic (re)sending of the packet that hasn't been ack'ed. Once ack'ed, TCP will "slow start" so as to not "reintroduce" the congestion, on the odd chance that this stream was causing the congestion. So, the basic behavior that current Internet congestion mechanisms exhibit is that the *edge* stops sending traffic towards the congestion until the cognition event is over. So, under "Internet congestion", it would seem that the behavior we're after is to stop transmitting towards the "Internet". After all, it makes no sense to even put the packets into flight if they are only going to get dropped before reaching the destination. If we can somehow manage to figure out when the packets aren't reaching the other end and stop the engress PE from sending, the we would have the same behavior as TCP in the beginning, but being slow to start back doesn't seem to be an option for us. Further more, having a round trip based (probe?) restart method also doesn't seem to be particularly good. Seems like we have to come up with a way to tell the sending PE to stop sending for some *small* amount of time, then blast away again. It would seems like a bad idea to just stop transmitting for 5-10 microseconds, but maybe not. What is the duration of "Internet congestion"? We know that PW will not work with chronic packet loss (congestion), so I'm thinking that a "fast start" mechanism is acceptable. I'm thinking right now that only the PE has to stop sending towards the Internet, rather than push the congestion towards the CE. Although, given certain PW types, it might be nice to try to use the "native" layer 2 methods to push the congestion back towards the CE, but I don't think this is a requirement. My questions today seem to revolve around the reaction of the customer application that's generating the PW packets on which the loss occurs. By this I mean if it's a TCP stream as PW payload would the TCP behavior be compromised/made worse if the PE quit sending towards the congestion. Although, It would also seem that in the case that if it's a TCP stream, it's backoff behavior may have acted soon enough so that the PE would only have to stops the flow under severe congestion. If it's not a tcp stream, for this I tend to think in terms of a UDP or even ethernet based "broken" video app that basically just spews packets, in this case, the PE sending or not sending doesn't effect the end application. I would like to come up with a PW congestion behavior that works the same regardless of payload type (TCP/UDP, raw ethernet, etc) thereby freeing us from the "payload" inspection idea. I also think that the "prior arrangement" method of classifying a stream "type" would be foolhardy at best, and most likely just simply futile, as least as a congestion avoidance . So, how do we determine if packets aren't making it to the other end? -craig > -----Original Message----- > From: Stewart Bryant [SMTP:stbryant@cisco.com] > Sent: Thursday, February 13, 2003 1:07 PM > To: neil.2.harrison@bt.com > Cc: chimento@torrentnet.com; Sasha@axerra.com; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 congestion > > > > neil.2.harrison@bt.com wrote: > > Stewart, please see below, regards, Neil > > > > Stewart Bryant wrote 13 February 2003 16:50 > > > > > > > >>What exactly do you mean by "managed properly"? > > > > NH=> Simply this: If there is a client/server relationship between 2 layer > > network technologies X/Y say, then its important that both X and Y can be > > operated/managed as layer networks in their own right. So this embraces all > > the functional components one requires to do this, eg addressing, routing, > > signalling (not cnls obviously), fault-management, traffic management, > > performance management, etc. In particular one should not be asking a given > > layer network (be it client or server to some other layer network) to proxy > > for functional deficiences in the other layer network....and in the specific > > case here there is an 'in-between' layer network that seems to be being > > created that looks like its taking on some of these proxying functions. > > > > ...and I think that the architecture uses this functional partitioning > because the only sub-system that is allowed to modulate (by any method) > the payload flow is the NSP, which is part of what you call the client > network. > > >>The requirement that MUST be addressed is to have a mechnanism that in > >>real time protects the network core from congestion collapse in a > >>fair way. > >> > >>In the case of non-TCP friendly traffic what is your > >>technical proposal > >>for the design of an alternative congestion back-off mechnism? > > > > NH=>The solution for protecting the network (get the source to slow down) is > > not trivial as Philip pointed out. How do you tell an ATM connection to slow > > down? How do you tell a circuit emulation T1/E1 to slow down? > > > > You don't. You set a congestion threshold and if that threshold is > exceeded you tear down the PW. > > > One way of addressing this is via signalling and CAC for known client > > demands on the server.....but of course it assumes these functions are > > available/specified in the server.....if they are not then perhaps one > > should not be doing this? > > Remember the IESG is not going to approve PW unless there is a method > of protecting the Internet from congestion. > > Stewart > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Andrew G. Malis" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 14 Feb 2003 16:05:57 -0500 Lines: 85 Sender: pwe3-admin@ietf.org References: <200302141143.GAA16759@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mpls@uu.net, ccamp@ops.ietf.org, pwe3@ietf.org Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Loa Andersson In-Reply-To: <200302141143.GAA16759@ietf.org> X-OriginalArrivalTime: 14 Feb 2003 21:19:48.0576 (UTC) FILETIME=[CDE71600:01C2D46E] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Loa, I assume that the mpls and ccamp lists are the appropriate places for discussion of this draft. I also included the pwe3 list, since this also affects the work in that WG. I apologize for the crossposts to those of you on more than one of these lists (including myself). Perhaps once the discussion has started, we can pick just one place to continue it. My initial reaction on reading your draft was that I didn't see any discussion of the pwe3 WG, which as you know is specifying extensions to RFC 3036. For the purposes of your draft, would pwe3 be classified as a "protocol specifying working group"? And is it your intention that the current work in the pwe3 WG be approved by the "requirement evaluating working group" prior to its documents being published as RFCs? Or would this be grandfathered in as already having been chartered by the IESG? Thanks, Andy ------- At 2/14/2003 06:43 AM -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : MPLS and GMPLS Change Process > Author(s) : L. Andersson > Filename : draft-andersson-mpls-g-chng-proc-00.txt > Pages : 11 > Date : 2003-2-13 > >This memo describes the process through which individuals, working >groups and external standards bodies can influence the development of >MPLS and GMPLS standards. With respect to standardization, this >process means that (G)MPLS extensions and changes can be done through >the IETF only, the body that created the (G)MPLS technology. The >IETF will not publish a (G)MPLS technology extension RFC outside of >the processes described here. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-andersson-mpls-g-chng-proc-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-andersson-mpls-g-chng-proc-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. >Content-Type: text/plain >Content-ID: <2003-2-13152703.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Fri, 14 Feb 2003 13:37:29 -0800 Lines: 9 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: To: "'White, Craig (Level 3)'" , stbryant@cisco.com, neil.2.harrison@bt.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > So, how do we determine if packets aren't making it to the other end? > The obvious way to do it is to use seq #. But IP/MPLS have no seq #. As I said in an earlier email, why not ask the node that is dropping a packet to generate a Congestion notification packet for that flow? Yours, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Fri, 14 Feb 2003 22:03:55 +0000 Organization: Cisco Systems, Inc. Lines: 19 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CB0@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Shahram Davari wrote: >>So, how do we determine if packets aren't making it to the other end? >> > > > The obvious way to do it is to use seq #. But IP/MPLS have no seq #. That is why the L2TPv3 and the MPLS CW have an optional sequence number, > As I said in an earlier email, why not ask the node that is dropping > a packet to generate a Congestion notification packet for that flow? > Because this feature is not generally available, particularly in the Internet core, and the PW has to run over the Internet. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Fri, 14 Feb 2003 14:10:45 -0800 Lines: 44 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, February 14, 2003 5:04 PM > To: Shahram Davari > Cc: 'White, Craig (Level 3)'; neil.2.harrison@bt.com; > chimento@torrentnet.com; Sasha@axerra.com; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 congestion > > > Shahram > > Shahram Davari wrote: > >>So, how do we determine if packets aren't making it to the > other end? > >> > > > > > > The obvious way to do it is to use seq #. But IP/MPLS have no seq #. > > That is why the L2TPv3 and the MPLS CW have an optional > sequence number, In that case the seq # must become mandatory ! > > > As I said in an earlier email, why not ask the node that is dropping > > a packet to generate a Congestion notification packet for that flow? > > > > Because this feature is not generally available, particularly > in the Internet core, and the PW has to run over the Internet. OK, I accept your argument that we don't want to retrofit all routers only the edge ones. Yours, -Shahram > > Stewart > From owner-mpls@UU.NET Wed Dec 27 16:41:43 2006 From: Loa Andersson Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 14 Feb 2003 23:13:07 +0100 Lines: 161 Sender: owner-mpls@UU.NET References: <5.2.0.9.0.20030214155201.043ebe30@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@UU.NET, ccamp@ops.ietf.org, pwe3@ietf.org Return-path: X-Original-Recipient: mpls@uu.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en To: "Andrew G. Malis" Precedence: bulk Status: O Andy, when writing the draft we briefly discussed whether to mention pwe3 or not, I gather that ther were different reasons for different people not to. The mpls and ccamp wg-chairs and the SubIP ADs had discussed the process for some time, on my part I did not want to delay publication by throwing this on the pwe3 chair just minutes before the prublication. I also think that there is an issue that pwe3 is not squarely within what we define as (G)MPLS technology, pwe3 is an end to end technology and that is why it is in transport. This could be splitting hairs by an axe, we took the decision to publish to get the type of reaction you given us here. The draft is out there to be discussed. If the pwe3 were to take up those extensions to ldp today, we would ask for problem description and requirments, on my part it is not my intention (and I don't think of any of the other authors) to retro-engineer existing work to fit the process. You might have noticed that I gave Jerry Ash the same answer when he suggested that the mpls should take up work on header compression over mpls. But since his work is not accepted or rejected yet, give us as much of the information as possible in the format we want to have in the change process. Though he has a certain freedom here. pwe3 in specifying extensions to ldp, would be a "protocol specifying working group", but note that this does not automatically transmorgraphies it into a (g)mpls technology working group. If you suggest that the pwe3 wg should be included as one of the (g)mpls technology working groups, then I suggest that you give us text to be discussed and if a consensus is reached included in the draft. Personally I would like to hear the transport ADs and pwe3 wg chairs opinion on this. Strictly I don't think we can require that people follow the process until the IESG has OKed it, but as a wg chair I can clearly have an opinion on how and where work on protocols specified by the mpls wg are done and how the mpls wg takes on new work. To avoid cross-posts I suggest that we taken the discussion on the draft-andersson-mpls-g-chng-proc-00.txt on the mpls list :). We will allocate time in both the mpls and ccamp working group meetings in SF to discuss this. /Loa Andrew G. Malis wrote: > Loa, > > I assume that the mpls and ccamp lists are the appropriate places for > discussion of this draft. I also included the pwe3 list, since this > also affects the work in that WG. I apologize for the crossposts to > those of you on more than one of these lists (including myself). > Perhaps once the discussion has started, we can pick just one place to > continue it. > > My initial reaction on reading your draft was that I didn't see any > discussion of the pwe3 WG, which as you know is specifying extensions > to RFC 3036. For the purposes of your draft, would pwe3 be classified > as a "protocol specifying working group"? And is it your intention > that the current work in the pwe3 WG be approved by the "requirement > evaluating working group" prior to its documents being published as > RFCs? Or would this be grandfathered in as already having been > chartered by the IESG? > > Thanks, > Andy > > ------- > > At 2/14/2003 06:43 AM -0500, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : MPLS and GMPLS Change Process >> Author(s) : L. Andersson >> Filename : draft-andersson-mpls-g-chng-proc-00.txt >> Pages : 11 >> Date : 2003-2-13 >> >> This memo describes the process through which individuals, working >> groups and external standards bodies can influence the development of >> MPLS and GMPLS standards. With respect to standardization, this >> process means that (G)MPLS extensions and changes can be done through >> the IETF only, the body that created the (G)MPLS technology. The >> IETF will not publish a (G)MPLS technology extension RFC outside of >> the processes described here. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt >> >> >> To remove yourself from the IETF Announcement list, send a message to >> ietf-announce-request with the word unsubscribe in the body of the >> message. >> >> 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-andersson-mpls-g-chng-proc-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-andersson-mpls-g-chng-proc-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. >> Content-Type: text/plain >> Content-ID: <2003-2-13152703.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt >> >> >> > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Fri, 14 Feb 2003 22:18:15 +0000 Organization: Cisco Systems, Inc. Lines: 57 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CB2@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, Sasha@axerra.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: > Stewart, > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Friday, February 14, 2003 5:04 PM >>To: Shahram Davari >>Cc: 'White, Craig (Level 3)'; neil.2.harrison@bt.com; >>chimento@torrentnet.com; Sasha@axerra.com; pwe3@ietf.org >>Subject: Re: [PWE3] PWE3 congestion >> >> >>Shahram >> >>Shahram Davari wrote: >> >>>>So, how do we determine if packets aren't making it to the >>> >>other end? >> >>> >>>The obvious way to do it is to use seq #. But IP/MPLS have no seq #. >> >>That is why the L2TPv3 and the MPLS CW have an optional >>sequence number, > > > In that case the seq # must become mandatory ! No, not if you have a well behaved payload. > > >>>As I said in an earlier email, why not ask the node that is dropping >>>a packet to generate a Congestion notification packet for that flow? >>> >> >>Because this feature is not generally available, particularly >>in the Internet core, and the PW has to run over the Internet. > > > OK, I accept your argument that we don't want to retrofit all routers only > the edge ones. > > Yours, > -Shahram > > >>Stewart >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Philip Chimento Subject: Re: PWE3 congestion Date: Fri, 14 Feb 2003 17:43:31 -0500 Lines: 62 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stbryant@cisco.com, neil.2.harrison@bt.com, Sasha@axerra.com, pwe3@ietf.org Return-path: X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "White, Craig (Level 3)" In-reply-to: Craig.White's message of Fri, 14 Feb 2003 13:58:26 -0700. Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Craig: A couple of comments: > > When the "Internet congests", that means that some layer 1 has clocked out some transitions (that we may think of as containing our packet) and this packet will never again be clocked out by any other layer 1. This is not to say that all loss occurs on links, obviously there are issues that occur in a box (buffer overrun, (W)RED dropping) but in anycase, those packets never get clocked out again. > It is important to note that the queue control mechanisms take advantage of TCP's "built-in" feedback mechanism which PWs don't necessarily have. RED is not particularly effective on uncontrolled UDP. > > So, under "Internet congestion", it would seem that the behavior we're after is to stop transmitting towards the "Internet". After all, it makes no sense to even put the packets into flight if they are only going to get dropped before reaching the destination. > If you have no way of reducing the rate, then you had better stop transmitting. > If we can somehow manage to figure out when the packets aren't reaching the other end and stop the engress PE from sending, the we would have the same behavior as TCP in the beginning, but being slow to start back doesn't seem to be an option for us. > Historically, there are lots of ways to do this. The issue to discuss is how, and what overhead/additional traffic are you willing to tolerate. > > Seems like we have to come up with a way to tell the sending PE to stop sending for some *small* amount of time, then blast away again. > No, actually, you don't want to do this. This is just the behavior that slow start is trying to avoid. You don't want to make it worse... > It would seems like a bad idea to just stop transmitting for 5-10 microseconds, but maybe not. What is the duration of "Internet congestion"? We know that PW will not work with chronic packet loss (congestion), so I'm thinking that a "fast start" mechanism is acceptable. > Basically, the duration is on the order of RTTs of the TCP sessions on the bottleneck link. (That is assuming that the traffic on any link is composed mostly of TCP, which is mostly true, I think.) That can be far far more than a few microseconds. > I'm thinking right now that only the PE has to stop sending towards the Internet, rather than push the congestion towards the CE. Although, given certain PW types, it might be nice to try to use the "native" layer 2 methods to push the congestion back towards the CE, but I don't think this is a requirement. > How much loss can your service tolerate and for how long ? Sometimes it is better just to terminate the connection.... > > I would like to come up with a PW congestion behavior that works the same regardless of payload type (TCP/UDP, raw ethernet, etc) thereby freeing us from the "payload" inspection idea. > I think that the behavior should be pretty much service-dependent and that you do have to classify. Different types of sources can have very different requirements and characteristics... Regards, Phil Chimento -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Sun, 16 Feb 2003 10:09:42 +0200 Lines: 42 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: chimento@torrentnet.com, pwe3@ietf.org Return-path: To: "'Shahram Davari'" , "'White, Craig (Level 3)'" , stbryant@cisco.com, neil.2.harrison@bt.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, February 14, 2003 11:37 PM > To: 'White, Craig (Level 3)'; stbryant@cisco.com; > neil.2.harrison@bt.com > Cc: chimento@torrentnet.com; Sasha Vainshtein; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > > So, how do we determine if packets aren't making it to the > other end? > > > > The obvious way to do it is to use seq #. But IP/MPLS have no seq #. > As I said in an earlier email, why not ask the node that is dropping > a packet to generate a Congestion notification packet for that flow? > Mainly because the router dropping a packet due to congestion does not know if it is a PW packet or something else (does not recognize any "flows" in your terms.) This knowledge is only in the PEs. To the best of my knowledge recognition of flows by intermediate routers has been the original IntServ idea - and it is its proven non-scalability that prevented usage of IntServ. I believe that we have discussed domething like that before on this list... > > Yours, > -Shahram > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 06:10:34 -0800 Lines: 66 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: chimento@torrentnet.com, pwe3@ietf.org Return-path: To: "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , stbryant@cisco.com, neil.2.harrison@bt.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Sunday, February 16, 2003 3:10 AM > To: Shahram Davari; 'White, Craig (Level 3)'; stbryant@cisco.com; > neil.2.harrison@bt.com > Cc: chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > Shahram and all, > Please see a brief comment inline. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Friday, February 14, 2003 11:37 PM > > To: 'White, Craig (Level 3)'; stbryant@cisco.com; > > neil.2.harrison@bt.com > > Cc: chimento@torrentnet.com; Sasha Vainshtein; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > So, how do we determine if packets aren't making it to the > > other end? > > > > > > > The obvious way to do it is to use seq #. But IP/MPLS have no seq #. > > As I said in an earlier email, why not ask the node that is dropping > > a packet to generate a Congestion notification packet for that flow? > > > Mainly because the router dropping a packet due to congestion > does not know > if it is a PW packet or something else (does not recognize > any "flows" in > your > terms.) This knowledge is only in the PEs. Agree. But the egress has knowledge of the payload type and could ignore congestion notification packets that don't belong to a PW. Yours, -Shahram > To the best of my knowledge recognition of flows by > intermediate routers > has been the original IntServ idea - and it is its proven > non-scalability > that > prevented usage of IntServ. > I believe that we have discussed domething like that before > on this list... > > > > Yours, > > -Shahram > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 16:17:45 +0200 Lines: 106 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: chimento@torrentnet.com, pwe3@ietf.org, "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, stbryant@cisco.com Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Looks interesting. If I understand your suggestion correctly: 1) An intermediate router must know how to send a congestion notification packet back to the ingess PE: a) Trivial over IP b) May be not so trivial over MPLS (LSPs are unidirectional) 2) The congestion notification packet must contain the information that would allow the ingress PE to find the associated PW. This may be problematic in case of hierarchical tunnels (IP or MPLS). I am not sure it is possible at all in case of an IPSec tunnel (but then I am not an IPSec expert - rather, the opposite). 3) If we solve (1) and (2), your suggestion will work. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, February 17, 2003 4:11 PM > To: Sasha Vainshtein; 'White, Craig (Level 3)'; > stbryant@cisco.com; neil.2.harrison@bt.com > Cc: chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > Sasha, > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Sunday, February 16, 2003 3:10 AM > > To: Shahram Davari; 'White, Craig (Level 3)'; stbryant@cisco.com; > > neil.2.harrison@bt.com > > Cc: chimento@torrentnet.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > > > > > > Shahram and all, > > Please see a brief comment inline. > > > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Friday, February 14, 2003 11:37 PM > > > To: 'White, Craig (Level 3)'; stbryant@cisco.com; > > > neil.2.harrison@bt.com > > > Cc: chimento@torrentnet.com; Sasha Vainshtein; pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > So, how do we determine if packets aren't making it to the > > > other end? > > > > > > > > > > The obvious way to do it is to use seq #. But IP/MPLS > have no seq #. > > > As I said in an earlier email, why not ask the node that > is dropping > > > a packet to generate a Congestion notification packet for > that flow? > > > > > Mainly because the router dropping a packet due to congestion > > does not know > > if it is a PW packet or something else (does not recognize > > any "flows" in > > your > > terms.) This knowledge is only in the PEs. > > Agree. But the egress has knowledge of the payload type and could > ignore congestion notification packets that don't belong to a PW. > > Yours, > -Shahram > > > To the best of my knowledge recognition of flows by > > intermediate routers > > has been the original IntServ idea - and it is its proven > > non-scalability > > that > > prevented usage of IntServ. > > I believe that we have discussed domething like that before > > on this list... > > > > > > Yours, > > > -Shahram > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 06:24:32 -0800 Lines: 134 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: chimento@torrentnet.com, pwe3@ietf.org, "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, stbryant@cisco.com Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Monday, February 17, 2003 9:18 AM > To: Shahram Davari > Cc: chimento@torrentnet.com; pwe3@ietf.org; 'White, Craig (Level 3)'; > neil.2.harrison@bt.com; stbryant@cisco.com > Subject: RE: [PWE3] PWE3 congestion > > > Shahram, > Looks interesting. > If I understand your suggestion correctly: Unfortunately you have not understood it correctly. What I said was that an interior node may generate in the forward direction a forward congestion notification toward the egress PE, by appending the user-data header (e.g., MPLS labels) . The egress PE could then generate a backward congestion notification toward ingress PE. Yours, -Shahram > 1) An intermediate router must know how to send a congestion > notification > packet > back to the ingess PE: > a) Trivial over IP > b) May be not so trivial over MPLS (LSPs are unidirectional) > 2) The congestion notification packet must contain the > information that > would > allow the ingress PE to find the associated PW. This may > be problematic > in case > of hierarchical tunnels (IP or MPLS). I am not sure it is > possible at > all in case > of an IPSec tunnel (but then I am not an IPSec expert - > rather, the > opposite). > 3) If we solve (1) and (2), your suggestion will work. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, February 17, 2003 4:11 PM > > To: Sasha Vainshtein; 'White, Craig (Level 3)'; > > stbryant@cisco.com; neil.2.harrison@bt.com > > Cc: chimento@torrentnet.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > > > > > > Sasha, > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > Sent: Sunday, February 16, 2003 3:10 AM > > > To: Shahram Davari; 'White, Craig (Level 3)'; stbryant@cisco.com; > > > neil.2.harrison@bt.com > > > Cc: chimento@torrentnet.com; pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > Shahram and all, > > > Please see a brief comment inline. > > > > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > > > > > > > > > > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Friday, February 14, 2003 11:37 PM > > > > To: 'White, Craig (Level 3)'; stbryant@cisco.com; > > > > neil.2.harrison@bt.com > > > > Cc: chimento@torrentnet.com; Sasha Vainshtein; pwe3@ietf.org > > > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > > So, how do we determine if packets aren't making it to the > > > > other end? > > > > > > > > > > > > > The obvious way to do it is to use seq #. But IP/MPLS > > have no seq #. > > > > As I said in an earlier email, why not ask the node that > > is dropping > > > > a packet to generate a Congestion notification packet for > > that flow? > > > > > > > Mainly because the router dropping a packet due to congestion > > > does not know > > > if it is a PW packet or something else (does not recognize > > > any "flows" in > > > your > > > terms.) This knowledge is only in the PEs. > > > > Agree. But the egress has knowledge of the payload type and could > > ignore congestion notification packets that don't belong to a PW. > > > > Yours, > > -Shahram > > > > > To the best of my knowledge recognition of flows by > > > intermediate routers > > > has been the original IntServ idea - and it is its proven > > > non-scalability > > > that > > > prevented usage of IntServ. > > > I believe that we have discussed domething like that before > > > on this list... > > > > > > > > Yours, > > > > -Shahram > > > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 16:30:42 +0200 Lines: 163 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: chimento@torrentnet.com, pwe3@ietf.org, "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, stbryant@cisco.com Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Now I see. Thank you for the explanation. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, February 17, 2003 4:25 PM > To: Sasha Vainshtein > Cc: chimento@torrentnet.com; pwe3@ietf.org; 'White, Craig > (Level 3)'; neil.2.harrison@bt.com; stbryant@cisco.com > Subject: RE: [PWE3] PWE3 congestion > > > Sasha, > > > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Monday, February 17, 2003 9:18 AM > > To: Shahram Davari > > Cc: chimento@torrentnet.com; pwe3@ietf.org; 'White, Craig > (Level 3)'; > > neil.2.harrison@bt.com; stbryant@cisco.com > > Subject: RE: [PWE3] PWE3 congestion > > > > > > Shahram, > > Looks interesting. > > If I understand your suggestion correctly: > > Unfortunately you have not understood it correctly. What I > said was that an interior node > may generate in the forward direction a forward congestion > notification toward the egress PE, by appending the user-data > header (e.g., MPLS labels) . The egress > PE could then generate a backward congestion notification > toward ingress PE. > > Yours, > -Shahram > > > > 1) An intermediate router must know how to send a congestion > > notification > > packet > > back to the ingess PE: > > a) Trivial over IP > > b) May be not so trivial over MPLS (LSPs are unidirectional) > > 2) The congestion notification packet must contain the > > information that > > would > > allow the ingress PE to find the associated PW. This may > > be problematic > > in case > > of hierarchical tunnels (IP or MPLS). I am not sure it is > > possible at > > all in case > > of an IPSec tunnel (but then I am not an IPSec expert - > > rather, the > > opposite). > > 3) If we solve (1) and (2), your suggestion will work. > > > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Monday, February 17, 2003 4:11 PM > > > To: Sasha Vainshtein; 'White, Craig (Level 3)'; > > > stbryant@cisco.com; neil.2.harrison@bt.com > > > Cc: chimento@torrentnet.com; pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > Sasha, > > > > > > > -----Original Message----- > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > Sent: Sunday, February 16, 2003 3:10 AM > > > > To: Shahram Davari; 'White, Craig (Level 3)'; > stbryant@cisco.com; > > > > neil.2.harrison@bt.com > > > > Cc: chimento@torrentnet.com; pwe3@ietf.org > > > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > Shahram and all, > > > > Please see a brief comment inline. > > > > > > > > With best regards, > > > > Sasha Vainshtein > > > > email: sasha@axerra.com > > > > tel: +972-3-7659993 (office) > > > > +972-8-9254948 (res.) > > > > +972-58-674833 (cell.) > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Friday, February 14, 2003 11:37 PM > > > > > To: 'White, Craig (Level 3)'; stbryant@cisco.com; > > > > > neil.2.harrison@bt.com > > > > > Cc: chimento@torrentnet.com; Sasha Vainshtein; pwe3@ietf.org > > > > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > > > > > So, how do we determine if packets aren't making it to the > > > > > other end? > > > > > > > > > > > > > > > > The obvious way to do it is to use seq #. But IP/MPLS > > > have no seq #. > > > > > As I said in an earlier email, why not ask the node that > > > is dropping > > > > > a packet to generate a Congestion notification packet for > > > that flow? > > > > > > > > > Mainly because the router dropping a packet due to congestion > > > > does not know > > > > if it is a PW packet or something else (does not recognize > > > > any "flows" in > > > > your > > > > terms.) This knowledge is only in the PEs. > > > > > > Agree. But the egress has knowledge of the payload type and could > > > ignore congestion notification packets that don't belong to a PW. > > > > > > Yours, > > > -Shahram > > > > > > > To the best of my knowledge recognition of flows by > > > > intermediate routers > > > > has been the original IntServ idea - and it is its proven > > > > non-scalability > > > > that > > > > prevented usage of IntServ. > > > > I believe that we have discussed domething like that before > > > > on this list... > > > > > > > > > > Yours, > > > > > -Shahram > > > > > > > > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Mon, 17 Feb 2003 14:53:44 +0000 Organization: Cisco Systems, Inc. Lines: 8 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CB6@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Agree. But the egress has knowledge of the payload type and could > ignore congestion notification packets that don't belong to a PW. > What generates these CN packets? Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 06:57:03 -0800 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > > Agree. But the egress has knowledge of the payload type and could > > ignore congestion notification packets that don't belong to a PW. > > > > What generates these CN packets? > > Stewart > An interior node that detects congestion. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Mon, 17 Feb 2003 14:57:02 +0000 Organization: Cisco Systems, Inc. Lines: 127 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Shahram Davari'" , chimento@torrentnet.com, pwe3@ietf.org, "'White, Craig (Level 3)'" , neil.2.harrison@bt.com Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Sasha Vainshtein Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha Vainshtein wrote: > Shahram, > Looks interesting. > If I understand your suggestion correctly: > 1) An intermediate router must know how to send a congestion notification > packet > back to the ingess PE: > a) Trivial over IP > b) May be not so trivial over MPLS (LSPs are unidirectional) > 2) The congestion notification packet must contain the information that > would > allow the ingress PE to find the associated PW. This may be problematic > in case > of hierarchical tunnels (IP or MPLS). I am not sure it is possible at > all in case > of an IPSec tunnel (but then I am not an IPSec expert - rather, the > opposite). > 3) If we solve (1) and (2), your suggestion will work. > Let's stay real. Routers don't do this today and a solution that requires a redesign of the Internet is not going to fly. Stewart > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > >>-----Original Message----- >>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>Sent: Monday, February 17, 2003 4:11 PM >>To: Sasha Vainshtein; 'White, Craig (Level 3)'; >>stbryant@cisco.com; neil.2.harrison@bt.com >>Cc: chimento@torrentnet.com; pwe3@ietf.org >>Subject: RE: [PWE3] PWE3 congestion >> >> >>Sasha, >> >> >>>-----Original Message----- >>>From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >>>Sent: Sunday, February 16, 2003 3:10 AM >>>To: Shahram Davari; 'White, Craig (Level 3)'; stbryant@cisco.com; >>>neil.2.harrison@bt.com >>>Cc: chimento@torrentnet.com; pwe3@ietf.org >>>Subject: RE: [PWE3] PWE3 congestion >>> >>> >>>Shahram and all, >>>Please see a brief comment inline. >>> >>>With best regards, >>> Sasha Vainshtein >>>email: sasha@axerra.com >>>tel: +972-3-7659993 (office) >>> +972-8-9254948 (res.) >>> +972-58-674833 (cell.) >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>>>Sent: Friday, February 14, 2003 11:37 PM >>>>To: 'White, Craig (Level 3)'; stbryant@cisco.com; >>>>neil.2.harrison@bt.com >>>>Cc: chimento@torrentnet.com; Sasha Vainshtein; pwe3@ietf.org >>>>Subject: RE: [PWE3] PWE3 congestion >>>> >>>> >>>> >>>>>So, how do we determine if packets aren't making it to the >>>> >>>>other end? >>>> >>>>The obvious way to do it is to use seq #. But IP/MPLS >>> >>have no seq #. >> >>>>As I said in an earlier email, why not ask the node that >>> >>is dropping >> >>>>a packet to generate a Congestion notification packet for >>> >>that flow? >> >>>Mainly because the router dropping a packet due to congestion >>>does not know >>>if it is a PW packet or something else (does not recognize >>>any "flows" in >>>your >>>terms.) This knowledge is only in the PEs. >> >>Agree. But the egress has knowledge of the payload type and could >>ignore congestion notification packets that don't belong to a PW. >> >>Yours, >>-Shahram >> >> >>>To the best of my knowledge recognition of flows by >>>intermediate routers >>>has been the original IntServ idea - and it is its proven >>>non-scalability >>>that >>>prevented usage of IntServ. >>>I believe that we have discussed domething like that before >>>on this list... >>> >>>>Yours, >>>>-Shahram >>>> >>> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 07:21:54 -0800 Lines: 43 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, Stewart is correct. The forward/backward congestion notification method that I suggested requires retrofitting the internet. The sequence number seems to be the best method to detect congestion loss without needing to change anything in the interior nodes. May I suggest then that a single flag in the PW header be used to indicate congestion in the forward direction. In other words the egress, upon detection of persistent packet loss, set a flag in the reverse PW direction header (assuming bidirectional PW). Yours, -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Monday, February 17, 2003 9:57 AM > To: 'stbryant@cisco.com' > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > Agree. But the egress has knowledge of the payload type and could > > > ignore congestion notification packets that don't belong to a PW. > > > > > > > What generates these CN packets? > > > > Stewart > > > > An interior node that detects congestion. > > -Shahram > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Alia Atlas Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 10:44:50 -0500 Lines: 60 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CBB@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'stbryant@cisco.com'" , "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03CBB@nt-exch-yow.pmc-sie rra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, What does the ingress do when it receives an indication that the PW has experienced congestion? Also, what level over what time period of missing sequence numbers would trigger such an indication? Alia At 07:21 AM 2/17/2003 -0800, Shahram Davari wrote: >Hi, > >Stewart is correct. The forward/backward congestion notification method >that I suggested requires retrofitting the internet. The sequence number >seems to be the best method to detect congestion loss without needing to >change anything in the interior nodes. > >May I suggest then that a single flag in the PW header be used to indicate >congestion in the forward direction. In other words the egress, upon >detection >of persistent packet loss, set a flag in the reverse PW direction header >(assuming >bidirectional PW). > >Yours, >-Shahram > > > -----Original Message----- > > From: Shahram Davari > > Sent: Monday, February 17, 2003 9:57 AM > > To: 'stbryant@cisco.com' > > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > > Agree. But the egress has knowledge of the payload type and could > > > > ignore congestion notification packets that don't belong to a PW. > > > > > > > > > > What generates these CN packets? > > > > > > Stewart > > > > > > > An interior node that detects congestion. > > > > -Shahram > > _______________________________________________ > > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 07:50:50 -0800 Lines: 100 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'stbryant@cisco.com'" , "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: To: "'Alia Atlas'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Alia, Good questions. Please see below. Yours, -Shahram > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Monday, February 17, 2003 10:45 AM > To: Shahram Davari > Cc: 'stbryant@cisco.com'; 'Sasha Vainshtein'; 'White, Craig > (Level 3)'; > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > Hi, > > What does the ingress do when it receives an indication that > the PW has > experienced congestion? I think the ingress should either cut the excess traffic (the traffic that is not guaranteed), or reroute the traffic. What do you think should be done? > > Also, what level over what time period of missing sequence > numbers would > trigger such an indication? Good question. This should be debated on the list. I have no particular suggestion on this at the moment. > > Alia > > At 07:21 AM 2/17/2003 -0800, Shahram Davari wrote: > >Hi, > > > >Stewart is correct. The forward/backward congestion > notification method > >that I suggested requires retrofitting the internet. The > sequence number > >seems to be the best method to detect congestion loss > without needing to > >change anything in the interior nodes. > > > >May I suggest then that a single flag in the PW header be > used to indicate > >congestion in the forward direction. In other words the egress, upon > >detection > >of persistent packet loss, set a flag in the reverse PW > direction header > >(assuming > >bidirectional PW). > > > >Yours, > >-Shahram > > > > > -----Original Message----- > > > From: Shahram Davari > > > Sent: Monday, February 17, 2003 9:57 AM > > > To: 'stbryant@cisco.com' > > > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > > > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > > > > > > > Agree. But the egress has knowledge of the payload > type and could > > > > > ignore congestion notification packets that don't > belong to a PW. > > > > > > > > > > > > > What generates these CN packets? > > > > > > > > Stewart > > > > > > > > > > An interior node that detects congestion. > > > > > > -Shahram > > > _______________________________________________ > > > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Daniel Feldman" Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 17:57:49 +0200 Lines: 257 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D69D.5202974A" Cc: "Sasha Vainshtein" , "White, Craig (Level 3)" , , , Return-path: Thread-Topic: [PWE3] PWE3 congestion Thread-Index: AcLWmzEhcgNkSXLbS0m1yqm60uefRAAAfKoQ content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 To: "Shahram Davari" , Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D69D.5202974A Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Shahram and all, sorry for the silly question but: isn't forward/backward congestion notification the idea behind IP ECN? > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, February 17, 2003 5:22 PM > To: 'stbryant@cisco.com' > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion >=20 >=20 > Hi, >=20 > Stewart is correct. The forward/backward congestion=20 > notification method > that I suggested requires retrofitting the internet. The=20 > sequence number > seems to be the best method to detect congestion loss without=20 > needing to > change anything in the interior nodes.=20 >=20 > May I suggest then that a single flag in the PW header be=20 > used to indicate > congestion in the forward direction. In other words the=20 > egress, upon detection=20 > of persistent packet loss, set a flag in the reverse PW=20 > direction header (assuming > bidirectional PW). >=20 > Yours, > -Shahram >=20 > > -----Original Message----- > > From: Shahram Davari=20 > > Sent: Monday, February 17, 2003 9:57 AM > > To: 'stbryant@cisco.com' > > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > >=20 > >=20 > >=20 > > >=20 > > > > Agree. But the egress has knowledge of the payload type=20 > and could > > > > ignore congestion notification packets that don't=20 > belong to a PW. > > > >=20 > > >=20 > > > What generates these CN packets? > > >=20 > > > Stewart > > >=20 > >=20 > > An interior node that detects congestion. > >=20 > > -Shahram > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 ------_=_NextPart_001_01C2D69D.5202974A Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Monday, February 17, 2003 5:22 PM
> To: 'stbryant@cisco.com'
> Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';=
> neil.2.harrison@bt.com; chimento@torrentnet.com; = pwe3@ietf.org
> Subject: RE: [PWE3] PWE3 congestion
>
>
> Hi,
>
> Stewart is correct. The forward/backward congesti= on
> notification method
> that I suggested requires retrofitting the intern= et. The
> sequence number
> seems to be the best method to detect congestion = loss without
> needing to
> change anything in the interior nodes.
>
> May I suggest then that a single flag in the PW h= eader be
> used to indicate
> congestion in the forward direction. In other wor= ds the
> egress, upon detection
> of persistent packet loss, set a flag in the reve= rse PW
> direction header (assuming
> bidirectional PW).
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: Shahram Davari
> > Sent: Monday, February 17, 2003 9:57 AM
> > To: 'stbryant@cisco.com'
> > Cc: 'Sasha Vainshtein'; 'White, Craig (Level= 3)';
> > neil.2.harrison@bt.com; chimento@torrentnet.= com; pwe3@ietf.org
> > Subject: RE: [PWE3] PWE3 congestion
> >
> >
> >
> > >
> > > > Agree. But the egress has knowledg= e of the payload type
> and could
> > > > ignore congestion notification pac= kets that don't
> belong to a PW.
> > > >
> > >
> > > What generates these CN packets?
> > >
> > > Stewart
> > >
> >
> > An interior node that detects congestion.
> >
> > -Shahram
> > ____________________________________________= ___
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C2D69D.5202974A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 08:03:18 -0800 Lines: 194 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D69E.16598EA0" Cc: Sasha Vainshtein , "White, Craig (Level 3)" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: To: "'Daniel Feldman'" , stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2D69E.16598EA0 Content-Type: text/plain; charset="windows-1255" Daniel, Your question is very valid (not silly). You are correct, the IP ECN was designed to do only the forward congestion notification (not backward), but unfortunately is not a standard. I guess, if ECN is implemented, it could be used for the forward congestion indication. Yours, -Shahram -----Original Message----- From: Daniel Feldman [mailto:daniel@ic4ic.com] Sent: Monday, February 17, 2003 10:58 AM To: Shahram Davari; stbryant@cisco.com Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion Hi Shahram and all, sorry for the silly question but: isn't forward/backward congestion notification the idea behind IP ECN? > -----Original Message----- > From: Shahram Davari [ mailto:Shahram_Davari@pmc-sierra.com ] > Sent: Monday, February 17, 2003 5:22 PM > To: 'stbryant@cisco.com' > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > Hi, > > Stewart is correct. The forward/backward congestion > notification method > that I suggested requires retrofitting the internet. The > sequence number > seems to be the best method to detect congestion loss without > needing to > change anything in the interior nodes. > > May I suggest then that a single flag in the PW header be > used to indicate > congestion in the forward direction. In other words the > egress, upon detection > of persistent packet loss, set a flag in the reverse PW > direction header (assuming > bidirectional PW). > > Yours, > -Shahram > > > -----Original Message----- > > From: Shahram Davari > > Sent: Monday, February 17, 2003 9:57 AM > > To: 'stbryant@cisco.com' > > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > > Agree. But the egress has knowledge of the payload type > and could > > > > ignore congestion notification packets that don't > belong to a PW. > > > > > > > > > > What generates these CN packets? > > > > > > Stewart > > > > > > > An interior node that detects congestion. > > > > -Shahram > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C2D69E.16598EA0 Content-Type: text/html; charset="windows-1255" RE: [PWE3] PWE3 congestion
Daniel,
 
Your question is very valid (not silly). You are correct, the IP ECN was designed to do only the forward
congestion notification (not backward), but unfortunately is not a standard. I guess, if ECN is implemented, it could be used
for the forward congestion indication.
 
Yours,
-Shahram
-----Original Message-----
From: Daniel Feldman [mailto:daniel@ic4ic.com]
Sent: Monday, February 17, 2003 10:58 AM
To: Shahram Davari; stbryant@cisco.com
Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org
Subject: RE: [PWE3] PWE3 congestion

        Hi Shahram and all,
        sorry for the silly question but: isn't forward/backward congestion notification the idea behind IP ECN?

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Monday, February 17, 2003 5:22 PM
> To: 'stbryant@cisco.com'
> Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';
> neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org
> Subject: RE: [PWE3] PWE3 congestion
>
>
> Hi,
>
> Stewart is correct. The forward/backward congestion
> notification method
> that I suggested requires retrofitting the internet. The
> sequence number
> seems to be the best method to detect congestion loss without
> needing to
> change anything in the interior nodes.
>
> May I suggest then that a single flag in the PW header be
> used to indicate
> congestion in the forward direction. In other words the
> egress, upon detection
> of persistent packet loss, set a flag in the reverse PW
> direction header (assuming
> bidirectional PW).
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: Shahram Davari
> > Sent: Monday, February 17, 2003 9:57 AM
> > To: 'stbryant@cisco.com'
> > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';
> > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org
> > Subject: RE: [PWE3] PWE3 congestion
> >
> >
> >
> > >
> > > > Agree. But the egress has knowledge of the payload type
> and could
> > > > ignore congestion notification packets that don't
> belong to a PW.
> > > >
> > >
> > > What generates these CN packets?
> > >
> > > Stewart
> > >
> >
> > An interior node that detects congestion.
> >
> > -Shahram
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C2D69E.16598EA0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 18:44:48 +0200 Lines: 373 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-380feebc-b808-4b34-b579-bc2002e6f92f" Cc: "White, Craig (Level 3)" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org, stbryant@cisco.com Return-path: To: "'Shahram Davari'" , "'Daniel Feldman'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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. ------=_NextPartTM-000-380feebc-b808-4b34-b579-bc2002e6f92f Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D6A3.E27AB0E0" ------_=_NextPart_001_01C2D6A3.E27AB0E0 Content-Type: text/plain; charset="windows-1255" Shahram and Daniel, RFC 3168 "The Addition of Explicit Congestion Notification (ECN) to IP" is a Proposed Standard. And it is supported, e.g., by the Cisco IOS 12.2(8) for quite a bunch of platforms. (I do not know to what extent it is actually deployed). All the standing proposals for TDM circuits emulation support a dedicated flag that allows reporting back lost packets. It can be also used to report packets received with the EC (experienced congestion) indication. The ingress could then use this information. So it looks like Shahram's proposal for PWs carrying TDM circuits over ECN-enabled IP networks is quite realistic. This still leaves a problem of non-TDM PWs (there is no flag and, what's more, there may be no packet to send back to carry the backward notification) and PWs over MPLS (no ECN - you can only look at the actually dropped packets). With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, February 17, 2003 6:03 PM To: 'Daniel Feldman'; stbryant@cisco.com Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion Daniel, Your question is very valid (not silly). You are correct, the IP ECN was designed to do only the forward congestion notification (not backward), but unfortunately is not a standard. I guess, if ECN is implemented, it could be used for the forward congestion indication. Yours, -Shahram -----Original Message----- From: Daniel Feldman [mailto:daniel@ic4ic.com] Sent: Monday, February 17, 2003 10:58 AM To: Shahram Davari; stbryant@cisco.com Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion Hi Shahram and all, sorry for the silly question but: isn't forward/backward congestion notification the idea behind IP ECN? > -----Original Message----- > From: Shahram Davari [ mailto:Shahram_Davari@pmc-sierra.com ] > Sent: Monday, February 17, 2003 5:22 PM > To: 'stbryant@cisco.com' > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > Hi, > > Stewart is correct. The forward/backward congestion > notification method > that I suggested requires retrofitting the internet. The > sequence number > seems to be the best method to detect congestion loss without > needing to > change anything in the interior nodes. > > May I suggest then that a single flag in the PW header be > used to indicate > congestion in the forward direction. In other words the > egress, upon detection > of persistent packet loss, set a flag in the reverse PW > direction header (assuming > bidirectional PW). > > Yours, > -Shahram > > > -----Original Message----- > > From: Shahram Davari > > Sent: Monday, February 17, 2003 9:57 AM > > To: 'stbryant@cisco.com' > > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > > Agree. But the egress has knowledge of the payload type > and could > > > > ignore congestion notification packets that don't > belong to a PW. > > > > > > > > > > What generates these CN packets? > > > > > > Stewart > > > > > > > An interior node that detects congestion. > > > > -Shahram > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C2D6A3.E27AB0E0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE3 congestion
Shahram and Daniel,
RFC=20 3168 "The Addition of Explicit Congestion Notification (ECN) to IP" is = a=20 Proposed Standard. And it is supported, e.g., by the Cisco IOS 12.2(8) = for quite=20 a bunch of platforms. (I do not know to what extent it is actually = deployed).
All=20 the standing proposals for TDM circuits emulation support a dedicated = flag that=20 allows reporting back lost packets. It can be also used to report = packets=20 received with the EC (experienced congestion) indication. The ingress = could then=20 use this information.
So it=20 looks like Shahram's proposal for PWs carrying TDM circuits over = ECN-enabled IP=20 networks is quite realistic.
This still leaves a problem of non-TDM PWs = (there is no=20 flag and, what's more, there may be no packet to send back to carry the = backward=20 notification) and PWs over MPLS (no ECN - you can only look at the = actually=20 dropped packets).
 
With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: Shahram Davari=20 [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Monday, = February 17,=20 2003 6:03 PM
To: 'Daniel Feldman'; = stbryant@cisco.com
Cc:=20 Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com;=20 chimento@torrentnet.com; pwe3@ietf.org
Subject: RE: [PWE3] = PWE3=20 congestion

Daniel,
 
Your=20 question is very valid (not silly). You are correct, the IP ECN = was=20 designed to do only the forward
congestion notification (not = backward), but=20 unfortunately is not a standard. I guess, if ECN is implemented, = it could=20 be used
for=20 the forward congestion indication.
 
Yours,
-Shahram
-----Original Message-----
From: Daniel Feldman=20 [mailto:daniel@ic4ic.com]
Sent: Monday, February 17, 2003 = 10:58=20 AM
To: Shahram Davari; stbryant@cisco.com
Cc: = Sasha=20 Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com;=20 chimento@torrentnet.com; pwe3@ietf.org
Subject: RE: = [PWE3] PWE3=20 congestion

        Hi = Shahram and=20 all,
        sorry for the silly question but: isn't forward/backward = congestion=20 notification the idea behind IP ECN?

> -----Original Message-----
>=20 From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]=20
> Sent: Monday, February 17, 2003 5:22 = PM=20
> To: 'stbryant@cisco.com'
>=20 Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';
> neil.2.harrison@bt.com; chimento@torrentnet.com;=20 pwe3@ietf.org
> Subject: RE: [PWE3] = PWE3=20 congestion
>
>=20
> Hi,
>=20
> Stewart is correct. The = forward/backward=20 congestion
> notification = method
> that I suggested requires retrofitting the internet. = The=20
> sequence number
>=20 seems to be the best method to detect congestion loss without=20
> needing to
> change=20 anything in the interior nodes.
>=20
> May I suggest then that a single = flag in the PW=20 header be
> used to indicate =
> congestion in the forward direction. In other words = the=20
> egress, upon detection =
> of persistent packet loss, set a flag in the reverse = PW=20
> direction header (assuming =
> bidirectional PW).
> =
> Yours,
> -Shahram =
>
> > -----Original=20 Message-----
> > From: Shahram = Davari=20
> > Sent: Monday, February 17, 2003 = 9:57=20 AM
> > To: = 'stbryant@cisco.com'=20
> > Cc: 'Sasha Vainshtein'; 'White, Craig = (Level=20 3)';
> > neil.2.harrison@bt.com;=20 chimento@torrentnet.com; pwe3@ietf.org
> >=20 Subject: RE: [PWE3] PWE3 congestion
> = >=20
> >
> = >=20
> > >
> >=20 > > Agree. But the egress has knowledge of the payload type=20
> and could
> >=20 > > ignore congestion notification packets that don't =
> belong to a PW.
> > = > >=20
> > >
> >=20 > What generates these CN packets?
> > >=20
> > > Stewart
>=20 > >
> >
>=20 > An interior node that detects congestion.
>=20 >
> > -Shahram
>=20 > _______________________________________________ =
> > pwe3 mailing list
> = >=20 pwe3@ietf.org
> > https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
> >
>=20 _______________________________________________
>=20 pwe3 mailing list
> = pwe3@ietf.org=20
> https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
> =

------_=_NextPart_001_01C2D6A3.E27AB0E0-- ------=_NextPartTM-000-380feebc-b808-4b34-b579-bc2002e6f92f-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 08:52:02 -0800 Lines: 394 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D6A4.E51FEAD0" Cc: "White, Craig (Level 3)" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org, stbryant@cisco.com Return-path: To: "'Sasha Vainshtein'" , "'Daniel Feldman'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2D6A4.E51FEAD0 Content-Type: text/plain; charset="windows-1255" Sasha, Agree with you. -Shahram -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Monday, February 17, 2003 11:45 AM To: Shahram Davari; 'Daniel Feldman' Cc: White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org; stbryant@cisco.com Subject: RE: [PWE3] PWE3 congestion Shahram and Daniel, RFC 3168 "The Addition of Explicit Congestion Notification (ECN) to IP" is a Proposed Standard. And it is supported, e.g., by the Cisco IOS 12.2(8) for quite a bunch of platforms. (I do not know to what extent it is actually deployed). All the standing proposals for TDM circuits emulation support a dedicated flag that allows reporting back lost packets. It can be also used to report packets received with the EC (experienced congestion) indication. The ingress could then use this information. So it looks like Shahram's proposal for PWs carrying TDM circuits over ECN-enabled IP networks is quite realistic. This still leaves a problem of non-TDM PWs (there is no flag and, what's more, there may be no packet to send back to carry the backward notification) and PWs over MPLS (no ECN - you can only look at the actually dropped packets). With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, February 17, 2003 6:03 PM To: 'Daniel Feldman'; stbryant@cisco.com Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion Daniel, Your question is very valid (not silly). You are correct, the IP ECN was designed to do only the forward congestion notification (not backward), but unfortunately is not a standard. I guess, if ECN is implemented, it could be used for the forward congestion indication. Yours, -Shahram -----Original Message----- From: Daniel Feldman [mailto:daniel@ic4ic.com] Sent: Monday, February 17, 2003 10:58 AM To: Shahram Davari; stbryant@cisco.com Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion Hi Shahram and all, sorry for the silly question but: isn't forward/backward congestion notification the idea behind IP ECN? > -----Original Message----- > From: Shahram Davari [ mailto:Shahram_Davari@pmc-sierra.com ] > Sent: Monday, February 17, 2003 5:22 PM > To: 'stbryant@cisco.com' > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > Hi, > > Stewart is correct. The forward/backward congestion > notification method > that I suggested requires retrofitting the internet. The > sequence number > seems to be the best method to detect congestion loss without > needing to > change anything in the interior nodes. > > May I suggest then that a single flag in the PW header be > used to indicate > congestion in the forward direction. In other words the > egress, upon detection > of persistent packet loss, set a flag in the reverse PW > direction header (assuming > bidirectional PW). > > Yours, > -Shahram > > > -----Original Message----- > > From: Shahram Davari > > Sent: Monday, February 17, 2003 9:57 AM > > To: 'stbryant@cisco.com' > > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 congestion > > > > > > > > > > > > > Agree. But the egress has knowledge of the payload type > and could > > > > ignore congestion notification packets that don't > belong to a PW. > > > > > > > > > > What generates these CN packets? > > > > > > Stewart > > > > > > > An interior node that detects congestion. > > > > -Shahram > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C2D6A4.E51FEAD0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE3 congestion
Sasha,
 
Agree=20 with you.
 
-Shahram
-----Original Message-----
From: Sasha Vainshtein=20 [mailto:Sasha@AXERRA.com]
Sent: Monday, February 17, 2003 = 11:45=20 AM
To: Shahram Davari; 'Daniel Feldman'
Cc: = White, Craig=20 (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; = pwe3@ietf.org;=20 stbryant@cisco.com
Subject: RE: [PWE3] PWE3=20 congestion

Shahram and Daniel,
RFC=20 3168 "The Addition of Explicit Congestion Notification (ECN) to IP" = is a=20 Proposed Standard. And it is supported, e.g., by the Cisco IOS = 12.2(8) for=20 quite a bunch of platforms. (I do not know to what = extent it is=20 actually deployed).
All=20 the standing proposals for TDM circuits emulation support a dedicated = flag=20 that allows reporting back lost packets. It can be also used to = report packets=20 received with the EC (experienced congestion) indication. The ingress = could=20 then use this information.
So=20 it looks like Shahram's proposal for PWs carrying TDM circuits over=20 ECN-enabled IP networks is quite realistic.
This still leaves a problem of non-TDM PWs = (there is=20 no flag and, what's more, there may be no packet to send back to = carry the=20 backward notification) and PWs over MPLS (no ECN - you can only look = at the=20 actually dropped packets).
 
With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993=20 (office)
           = +972-8-9254948 (res.)
           = +972-58-674833 (cell.)
 
-----Original Message-----
From: Shahram Davari=20 [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Monday, = February 17,=20 2003 6:03 PM
To: 'Daniel Feldman';=20 stbryant@cisco.com
Cc: Sasha Vainshtein; White, Craig = (Level 3);=20 neil.2.harrison@bt.com; chimento@torrentnet.com;=20 pwe3@ietf.org
Subject: RE: [PWE3] PWE3=20 congestion

Daniel,
 
Your question is very valid (not = silly). You=20 are correct, the IP ECN was designed to do only the=20 forward
congestion notification (not = backward), but=20 unfortunately is not a standard. I guess, if ECN is = implemented, it=20 could be used
for the forward congestion=20 indication.
 
Yours,
-Shahram
-----Original Message-----
From: Daniel = Feldman=20 [mailto:daniel@ic4ic.com]
Sent: Monday, February 17, = 2003 10:58=20 AM
To: Shahram Davari; stbryant@cisco.com
Cc: = Sasha=20 Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com;=20 chimento@torrentnet.com; pwe3@ietf.org
Subject: RE: = [PWE3] PWE3=20 congestion

        Hi = Shahram and=20 all,
        sorry for the silly question but: isn't forward/backward = congestion=20 notification the idea behind IP ECN?

> -----Original Message----- =
> From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]=20
> Sent: Monday, February 17, 2003 5:22 = PM=20
> To: 'stbryant@cisco.com'
> Cc: 'Sasha Vainshtein'; 'White, Craig (Level = 3)';=20
> neil.2.harrison@bt.com; = chimento@torrentnet.com;=20 pwe3@ietf.org
> Subject: RE: [PWE3] = PWE3=20 congestion
>
>=20
> Hi,
> =
> Stewart is correct. The = forward/backward=20 congestion
> notification = method=20
> that I suggested requires retrofitting = the internet.=20 The
> sequence number =
> seems to be the best method to detect congestion = loss without=20
> needing to
>=20 change anything in the interior nodes.
>=20
> May I suggest then that a single = flag in the=20 PW header be
> used to = indicate=20
> congestion in the forward direction. In = other words=20 the
> egress, upon detection =
> of persistent packet loss, set a flag in the = reverse PW=20
> direction header (assuming =
> bidirectional PW).
>=20
> Yours,
>=20 -Shahram
>
> >=20 -----Original Message-----
> > = From: Shahram=20 Davari
> > Sent: Monday, February = 17, 2003=20 9:57 AM
> > To: = 'stbryant@cisco.com'=20
> > Cc: 'Sasha Vainshtein'; 'White, = Craig (Level=20 3)';
> > neil.2.harrison@bt.com;=20 chimento@torrentnet.com; pwe3@ietf.org
> >=20 Subject: RE: [PWE3] PWE3 congestion
> >=20
> >
> >=20
> > >
> >=20 > > Agree. But the egress has knowledge of the payload type =
> and could
> >=20 > > ignore congestion notification packets that don't=20
> belong to a PW.
>=20 > > >
> > > =
> > > What generates these CN packets? =
> > >
> > >=20 Stewart
> > >
> >
> > An = interior node that=20 detects congestion.
> > =
> > -Shahram
> >=20 _______________________________________________
> > pwe3 mailing list
> >=20 pwe3@ietf.org
> > https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
> >
>=20 _______________________________________________
> pwe3 mailing list
>=20 pwe3@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
>=20

------_=_NextPart_001_01C2D6A4.E51FEAD0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Daniel Feldman" Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 18:53:54 +0200 Lines: 408 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D6A5.27A1C4FA" Cc: "White, Craig (Level 3)" , , , , , "Lloyd Wood" Return-path: Thread-Topic: [PWE3] PWE3 congestion Thread-Index: AcLWpDn6T2NAlTuuQ1exZ+aYaFa3cQAAFcEg content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 To: "Sasha Vainshtein" , "Shahram Davari" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D6A5.27A1C4FA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Sasha, Shahram, Lloyd et al., I think we all agreed ECN for forward congestion notification is beneficial, even though not a solution for all the cases. I am for adopting Sasha's proposal for TDM circuits over IP PSNs. Regarding MPLS, anyone knows whatever happened to the experimental bits ;-). For asymmetric flows... -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Monday, February 17, 2003 6:45 PM To: 'Shahram Davari'; Daniel Feldman Cc: White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org; stbryant@cisco.com Subject: RE: [PWE3] PWE3 congestion Shahram and Daniel, RFC 3168 "The Addition of Explicit Congestion Notification (ECN) to IP" is a Proposed Standard. And it is supported, e.g., by the Cisco IOS 12.2(8) for quite a bunch of platforms. (I do not know to what extent it is actually deployed). All the standing proposals for TDM circuits emulation support a dedicated flag that allows reporting back lost packets. It can be also used to report packets received with the EC (experienced congestion) indication. The ingress could then use this information. So it looks like Shahram's proposal for PWs carrying TDM circuits over ECN-enabled IP networks is quite realistic. This still leaves a problem of non-TDM PWs (there is no flag and, what's more, there may be no packet to send back to carry the backward notification) and PWs over MPLS (no ECN - you can only look at the actually dropped packets).=20 =20 With best regards, Sasha Vainshtein email: sasha@axerra.com =20 tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) =20 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, February 17, 2003 6:03 PM To: 'Daniel Feldman'; stbryant@cisco.com Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion Daniel, =20 Your question is very valid (not silly). You are correct, the IP ECN was designed to do only the forward congestion notification (not backward), but unfortunately is not a standard. I guess, if ECN is implemented, it could be used for the forward congestion indication. =20 Yours, -Shahram -----Original Message----- From: Daniel Feldman [mailto:daniel@ic4ic.com] Sent: Monday, February 17, 2003 10:58 AM To: Shahram Davari; stbryant@cisco.com Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion Hi Shahram and all,=20 sorry for the silly question but: isn't forward/backward congestion notification the idea behind IP ECN?=20 > -----Original Message-----=20 > From: Shahram Davari [ mailto:Shahram_Davari@pmc-sierra.com ]=20 > Sent: Monday, February 17, 2003 5:22 PM=20 > To: 'stbryant@cisco.com'=20 > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';=20 > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org=20 > Subject: RE: [PWE3] PWE3 congestion=20 >=20 >=20 > Hi,=20 >=20 > Stewart is correct. The forward/backward congestion=20 > notification method=20 > that I suggested requires retrofitting the internet. The=20 > sequence number=20 > seems to be the best method to detect congestion loss without=20 > needing to=20 > change anything in the interior nodes.=20 >=20 > May I suggest then that a single flag in the PW header be=20 > used to indicate=20 > congestion in the forward direction. In other words the=20 > egress, upon detection=20 > of persistent packet loss, set a flag in the reverse PW=20 > direction header (assuming=20 > bidirectional PW).=20 >=20 > Yours,=20 > -Shahram=20 >=20 > > -----Original Message-----=20 > > From: Shahram Davari=20 > > Sent: Monday, February 17, 2003 9:57 AM=20 > > To: 'stbryant@cisco.com'=20 > > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';=20 > > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org=20 > > Subject: RE: [PWE3] PWE3 congestion=20 > >=20 > >=20 > >=20 > > >=20 > > > > Agree. But the egress has knowledge of the payload type=20 > and could=20 > > > > ignore congestion notification packets that don't=20 > belong to a PW.=20 > > > >=20 > > >=20 > > > What generates these CN packets?=20 > > >=20 > > > Stewart=20 > > >=20 > >=20 > > An interior node that detects congestion.=20 > >=20 > > -Shahram=20 > > _______________________________________________=20 > > pwe3 mailing list=20 > > pwe3@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/pwe3 =20 > >=20 > _______________________________________________=20 > pwe3 mailing list=20 > pwe3@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/pwe3 =20 >=20 ------_=_NextPart_001_01C2D6A5.27A1C4FA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE3 congestion
    Sasha, Shahram, Lloyd et al.,
    I think we all agreed ECN for forward congestion= =20 notification is beneficial, even though not a solution for all the cases.= I am=20 for adopting Sasha's proposal for TDM circuits over IP PSNs. Regarding MP= LS,=20 anyone knows whatever happened to the experimental bits ;-).
    For asymmetric flows...
-----Original Message-----
From: Sasha Vainshtein=20 [mailto:Sasha@AXERRA.com]
Sent: Monday, February 17, 2003 6:4= 5=20 PM
To: 'Shahram Davari'; Daniel Feldman
Cc: White, = Craig=20 (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.o= rg;=20 stbryant@cisco.com
Subject: RE: [PWE3] PWE3=20 congestion

Shahram and Daniel,
RFC=20 3168 "The Addition of Explicit Congestion Notification (ECN) to IP" is = a=20 Proposed Standard. And it is supported, e.g., by the Cisco IOS 12.2(8) = for=20 quite a bunch of platforms. (I do not know to what extent= it is=20 actually deployed).
All=20 the standing proposals for TDM circuits emulation support a dedicated f= lag=20 that allows reporting back lost packets. It can be also used to report = packets=20 received with the EC (experienced congestion) indication. The ingress c= ould=20 then use this information.
So=20 it looks like Shahram's proposal for PWs carrying TDM circuits over=20 ECN-enabled IP networks is quite realistic.
This still leaves a problem of non-TDM PWs (= there is=20 no flag and, what's more, there may be no packet to send back to carry = the=20 backward notification) and PWs over MPLS (no ECN - you can only look at= the=20 actually dropped packets).
 
With best regards,
          &n= bsp;           &nb= sp;           =20 Sasha Vainshtein=
email:   =   sasha@axerra.com
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: Shahram Davari=20 [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Monday, Februa= ry 17,=20 2003 6:03 PM
To: 'Daniel Feldman';=20 stbryant@cisco.com
Cc: Sasha Vainshtein; White, Craig (Leve= l 3);=20 neil.2.harrison@bt.com; chimento@torrentnet.com;=20 pwe3@ietf.org
Subject: RE: [PWE3] PWE3=20 congestion

Daniel,
 
Your question is very valid (not silly).&n= bsp;You=20 are correct, the IP ECN was designed to do only the=20 forward
congestion notification (not backward),&nb= sp;but=20 unfortunately is not a standard. I guess, if ECN is implemented,= it=20 could be used
for the forward congestion=20 indication.
 
Yours,
-Shahram
-----Original Message-----
From: Daniel Feldman=20 [mailto:daniel@ic4ic.com]
Sent: Monday, February 17, 2003= 10:58=20 AM
To: Shahram Davari; stbryant@cisco.com
Cc: S= asha=20 Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com;=20 chimento@torrentnet.com; pwe3@ietf.org
Subject: RE: [PWE3= ] PWE3=20 congestion

        Hi Sha= hram and=20 all,
        sorry for the silly question but: isn't forward/backward c= ongestion=20 notification the idea behind IP ECN?

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari= @pmc-sierra.com]=20
> Sent: Monday, February 17, 2003 5:22 PM=20
> To: 'stbryant@cisco.com'
> Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';=20
> neil.2.harrison@bt.com; chimento@torrentnet= =2Ecom;=20 pwe3@ietf.org
> Subject: RE: [PWE3] PW= E3=20 congestion
>
>=20
> Hi,
>=20
> Stewart is correct. The forward/back= ward=20 congestion
> notification method=20
> that I suggested requires retrofitting the = internet.=20 The
> sequence number
> seems to be the best method to detect congestion loss= without=20
> needing to
>=20 change anything in the interior nodes.
&g= t;=20
> May I suggest then that a single fla= g in the=20 PW header be
> used to indicate= =20
> congestion in the forward direction. In oth= er words=20 the
> egress, upon detection > of persistent packet loss, set a flag in the reverse = PW=20
> direction header (assuming > bidirectional PW).
>=20
> Yours,
>= ;=20 -Shahram
>
&= gt; >=20 -----Original Message-----
> > From= : Shahram=20 Davari
> > Sent: Monday, February 1= 7, 2003=20 9:57 AM
> > To: 'stbryant@cisco.com= '=20
> > Cc: 'Sasha Vainshtein'; 'White, Craig = (Level=20 3)';
> > neil.2.harrison@bt.com;=20 chimento@torrentnet.com; pwe3@ietf.org
&g= t; >=20 Subject: RE: [PWE3] PWE3 congestion
> = >=20
> >
> = >=20
> > >
= > >=20 > > Agree. But the egress has knowledge of the payload type=20
> and could
= > >=20 > > ignore congestion notification packets that don't=20
> belong to a PW.
>=20 > > >
> > >
= > > > What generates these CN packets? > > >
> > >=20 Stewart
> > >
> >
> > An interior = node that=20 detects congestion.
> >
= > > -Shahram
> >=20 _______________________________________________
> > pwe3 mailing list
>= >=20 pwe3@ietf.org
> > https://www1.i= etf.org/mailman/listinfo/pwe3=20
> >
>=20 _______________________________________________
> pwe3 mailing list
>=20 pwe3@ietf.org
> https://www1.i= etf.org/mailman/listinfo/pwe3=20
>=20

------_=_NextPart_001_01C2D6A5.27A1C4FA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Chris Metz Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 12:16:32 -0500 Lines: 36 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CBB@nt-exch-yow.pmc-sierra.bc.ca> <4B6D09F3B826D411A67300D0B706EFDEB03CBB@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Shahram Davari , "'stbryant@cisco.com'" , "" Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lloyd Wood In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Couple of observations/thoughts on the notion of PWE3 congestion: - "realness" principle states no change to interior nodes for the purpose of detecting/signaling explicit congestion of the PSN. This implies that any feedback loop is directly between the PEs with no explicit input from the interior nodes - implication that PWE3 CC be applied based on a priori knowledge of PW payload ("is it carrying TCP or not?") seems problematic. Is it verifiable? I don't think we want to get into classifying packets on the ingress PE based on transport layer port # to determine if/when PWE3 CC should be applied. - At PW provisioning time (or via CE signaling) we can get a pretty good idea about the type of traffic that the PW is carrying. If it is a UBR or ABR-style PW then we know that we can reduce the sending rate with the impact on the application being within the expectation level made known to the customer. If it is a CBR-style connection then we need to engineer the network accordingly. If we can't then one should not attempt to sell/support this service. What happens to CBR-style PWs if congestion occurs? Something is broken (as far as the customer is concerned) and we should tear it down and engage in damage control with the customer. That said is there some way to re-use existing (and to date effective) TCP congestion control machinery to provide PWE3 CC feedback? - Is it possible to utilize TCP-style CC to determine if there is congestion somewhere between the PEs? There is in the case of LDP a TCP stack on the PEs. One could inject/interleave TCP packets along the PW path (same label stack for example) at a some rate proportional to the configured data rate of the PW. Analysis of the TCP feedback by ingress PE would indicate if congestion was present. From there appropriate actions on the part of the ingress PE could be taken. Just thinking outside the box :-) Cheers ... From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Alia Atlas Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 12:15:02 -0500 Lines: 116 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CBE@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Cc: "'Daniel Feldman'" , stbryant@cisco.com, Sasha Vainshtein , "White, Craig (Level 3)" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03CBE@nt-exch-yow.pmc-sie rra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O The mechanisms for ECN might help as far as deciding to indicate congestion, but PWs don't necessarily have an IP header... and if they did, it's buried underneath a random number of MPLS labels and, more critically, a control word.

Currently, I don't see that ECN is defined to work with MPLS, and we only have 3 bits for EXP. 

We could clearly define an extension to a DIFFSERV object to specify that one of the EXP bits is for ECN...  Then this would need to be signaled on the LSPs used in the PSN, not the pseudo-wire.

Alia

At 08:03 AM 2/17/2003 -0800, Shahram Davari wrote:
Daniel,
 
Your question is very valid (not silly). You are correct, the IP ECN was designed to do only the forward
congestion notification (not backward), but unfortunately is not a standard. I guess, if ECN is implemented, it could be used
for the forward congestion indication.
 
Yours,
-Shahram
-----Original Message-----
From: Daniel Feldman [mailto:daniel@ic4ic.com]
Sent: Monday, February 17, 2003 10:58 AM
To: Shahram Davari; stbryant@cisco.com
Cc: Sasha Vainshtein; White, Craig (Level 3); neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org
Subject: RE: [PWE3] PWE3 congestion

        Hi Shahram and all,
        sorry for the silly question but: isn't forward/backward congestion notification the idea behind IP ECN?

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Monday, February 17, 2003 5:22 PM
> To: 'stbryant@cisco.com'
> Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';
> neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org
> Subject: RE: [PWE3] PWE3 congestion
>
>
> Hi,
>
> Stewart is correct. The forward/backward congestion
> notification method
> that I suggested requires retrofitting the internet. The
> sequence number
> seems to be the best method to detect congestion loss without
> needing to
> change anything in the interior nodes.
>
> May I suggest then that a single flag in the PW header be
> used to indicate
> congestion in the forward direction. In other words the
> egress, upon detection
> of persistent packet loss, set a flag in the reverse PW
> direction header (assuming
> bidirectional PW).
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: Shahram Davari
> > Sent: Monday, February 17, 2003 9:57 AM
> > To: 'stbryant@cisco.com'
> > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)';
> > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org
> > Subject: RE: [PWE3] PWE3 congestion
> >
> >
> >
> > >
> > > > Agree. But the egress has knowledge of the payload type
> and could
> > > > ignore congestion notification packets that don't
> belong to a PW.
> > > >
> > >
> > > What generates these CN packets?
> > >
> > > Stewart
> > >
> >
> > An interior node that detects congestion.
> >
> > -Shahram
> > _______________________________________________
> > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Alia Atlas Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 12:23:28 -0500 Lines: 41 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CBD@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'stbryant@cisco.com'" , "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03CBD@nt-exch-yow.pmc-sie rra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Shahram, > > What does the ingress do when it receives an indication that > > the PW has > > experienced congestion? > >I think the ingress should either cut the excess traffic (the traffic >that is not guaranteed), or reroute the traffic. What do you think >should be done? Well, it seems to me that one wants levels on how much the excess traffic is cut. Otherwise, you don't have the equivalent of a slow-start... So, I could see having a policer with a rate and burst. The rate could be the minimum committed. The burst could be adjusted among a set of values, going down when a congestion indication is received in a set time window, and up when one isn't... Of course, determining the window to detect in would be a little entertaining... Conceptually, say we have an array of bursts[16], ordered in size from lowest to highest. If a congestion indication is received, then the burstIndex is divided by 2. If no congestion indication is received, then the burstIndex is incremented by 1. The question is what time-frame this would have to be done on and for how many PWs. What do you think? > > Also, what level over what time period of missing sequence > > numbers would > > trigger such an indication? > > >Good question. This should be debated on the list. I have no >particular suggestion on this at the moment. The trick is finding something fast enough to deal with congestion and not so fast that it can't be handled for thousands of PWs. Regrettably, to interact and respond similarly to TCP streams, this might mean a window of about 100ms... but, like everything else, I'm sure it could be configurable. Alia From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 19:42:37 +0200 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Shahram Davari , "'stbryant@cisco.com'" , pwe3@ietf.org, Lloyd Wood Return-path: To: "'Chris Metz'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Chris and all, Just a single brief comment inline... With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Chris Metz [mailto:chmetz@cisco.com] > Sent: Monday, February 17, 2003 7:17 PM > To: Lloyd Wood > Cc: Shahram Davari; 'stbryant@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > ... snippedm ... > If it is a CBR-style connection then we need to > engineer the > network accordingly. If we can't then one should not attempt to > sell/support this service. What happens to CBR-style PWs if > congestion > occurs? Something is broken (as far as the customer is > concerned) and we > should tear it down and engage in damage control with the customer. > My impression has been that the ADs are not ready to accept this approach. I assume that they consider the situation when a pair of PEs actually belongs to the "end customer" who has decided to deploy a CBR-like PW between them over the public Internet without explicitly "buying" this service or "engineering" any network. And the problem is not the impact on the CBR-like PW (yes, it will not work!), but on the public Internet (lots of other things will stop working as well). > ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 11:58:42 -0800 Lines: 16 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, > > > Therefore a more generic > > method that applies to all types of payloads should be used. > > False - only to those payloads that don't have the TCP friendly > property. > Even if a PE knows that the payload is TCP, how do you guarantee that the customer has intentionally or unintentionally implemented the TCP back off. Yours, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Mon, 17 Feb 2003 20:20:24 +0000 Organization: Cisco Systems, Inc. Lines: 20 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CBA@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: >>>Agree. But the egress has knowledge of the payload type and could >>>ignore congestion notification packets that don't belong to a PW. >>> >> >>What generates these CN packets? >> >>Stewart >> > > > An interior node that detects congestion. But very few of the nodes in the Internet have this property, and holding off deploying this service until they do is unrealistic. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 12:24:15 -0800 Lines: 34 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Agree. -Shahram > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, February 17, 2003 3:20 PM > To: Shahram Davari > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 congestion > > > > > Shahram Davari wrote: > >>>Agree. But the egress has knowledge of the payload type and could > >>>ignore congestion notification packets that don't belong to a PW. > >>> > >> > >>What generates these CN packets? > >> > >>Stewart > >> > > > > > > An interior node that detects congestion. > > But very few of the nodes in the Internet have this property, > and holding off deploying this service until they do is > unrealistic. > > Stewart > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Mon, 17 Feb 2003 20:33:14 +0000 Organization: Cisco Systems, Inc. Lines: 88 Sender: pwe3-admin@ietf.org References: <5.1.0.14.2.20030217104324.01b02538@mailhost.avici.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Shahram Davari , "'Sasha Vainshtein'" , "'White, Craig (Level 3)'" , neil.2.harrison@bt.com, chimento@torrentnet.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Alia Atlas Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Alia Atlas wrote: > Hi, > > What does the ingress do when it receives an indication that the PW has > experienced congestion? > A suitable strategy might be: 1) Notify the NSP that the PW is experiencing congestion 2) Wait whilst the NSP takes some action to reduce the offered load 3) If congestion still experienced, shut down the PW Step 2 gives PW services that are in a position to reduce offered load some time to take action. Step 3 ensured that PW services that are unable to back off their offered load do eventually back off for the good of the other users. > Also, what level over what time period of missing sequence numbers would > trigger such an indication? I guess that we take guidance from the TCP control loop experts. Stewart > > Alia > > At 07:21 AM 2/17/2003 -0800, Shahram Davari wrote: > >> Hi, >> >> Stewart is correct. The forward/backward congestion notification method >> that I suggested requires retrofitting the internet. The sequence number >> seems to be the best method to detect congestion loss without needing to >> change anything in the interior nodes. >> >> May I suggest then that a single flag in the PW header be used to >> indicate >> congestion in the forward direction. In other words the egress, upon >> detection >> of persistent packet loss, set a flag in the reverse PW direction >> header (assuming >> bidirectional PW). >> >> Yours, >> -Shahram >> >> > -----Original Message----- >> > From: Shahram Davari >> > Sent: Monday, February 17, 2003 9:57 AM >> > To: 'stbryant@cisco.com' >> > Cc: 'Sasha Vainshtein'; 'White, Craig (Level 3)'; >> > neil.2.harrison@bt.com; chimento@torrentnet.com; pwe3@ietf.org >> > Subject: RE: [PWE3] PWE3 congestion >> > >> > >> > >> > > >> > > > Agree. But the egress has knowledge of the payload type and could >> > > > ignore congestion notification packets that don't belong to a PW. >> > > > >> > > >> > > What generates these CN packets? >> > > >> > > Stewart >> > > >> > >> > An interior node that detects congestion. >> > >> > -Shahram >> > _______________________________________________ >> > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 12:40:53 -0800 Lines: 54 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'pwe3@ietf.org'" Return-path: To: "'Lloyd Wood'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Lloyd, > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Monday, February 17, 2003 3:38 PM > To: Shahram Davari > Cc: 'pwe3@ietf.org' > Subject: RE: [PWE3] PWE3 congestion > > > On Mon, 17 Feb 2003, Shahram Davari wrote: > > > > > Therefore a more generic > > > > method that applies to all types of payloads should be used. > > > > > > False - only to those payloads that don't have the TCP friendly > > > property. > > > > > > > Even if a PE knows that the payload is TCP, how do you > guarantee that > > the customer has intentionally or unintentionally > implemented the TCP > > back off. > > (TCP != TCP friendly congestion control, but you knew that, right?) Right. > > unintentionally implemented?? Sorry I meant unintentionally not implemented. > > There's no guarantee that the TCP sender is doing TCP backoff etc. and > playing friendly (and if it's an ancient purely RFC793-compliant > pre-Jacobson-hack TCP it won't be) - this is the area of having to > protect your receiver against Savage attacks. > This was exactly my point. We should not rely on customer back off, even if their traffic is TCP. Thanks, -Shahram > L. > > hey! I'm actually reading the shorter, edited, mails! > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Keith Knightson Subject: RE: PWE3 congestion Date: Mon, 17 Feb 2003 16:45:31 -0400 Lines: 61 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CC5@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03CC5@nt-exch-yow.pmc-sierra.bc.ca> To: "'pwe3@ietf.org'" X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.102.172.43] using ID at Mon, 17 Feb 2003 16:38:41 -0500 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Guys, If you are emulating TDM you cannot surely make any assumptions at all about the protocols being used by the customer over the TDM. Conversely, if the protocol on the CE-PE is known then TDM across the core is not necessary, since this protocol can be extracted from the TDM on the access and sent as IP payload across the core. Surely the reason for a TDM PWE in the first place is to provide a means of conveying a transparent TDM stream all the way across an IP core? If the PSN underneath a TDM PWE becomes congested, such that blocks of bits are lost, then the PEs will have to detect it, at the PWE layer. I do not think that the underlying PSN can be relied upon to perform that function. The PEs have to detect it, and take action, like presumably turn off the clock towards the CE, or use OAM framing bits or something similar. I would also have thought that "normal" TDM OAM would have to be emulated across the core for this purpose. All this talk about about customer back-off at the TCP level eludes me,..., why on earth would any customer who is already operating already TCP over IP, want some emulated TDM PWE across an IP core? Why is IP in IP not a better solution? It seems to be that an emulated TDM PWE should be just that, ie an emulated TDM pipe. TDM is the PWE payload, not the payload of the TDM. The payload of the TDM is unknown. Conversely, if it is known then the TDM is not required, since it can be handled directly. I must be missing something, brain cells probably. Regards Keith At 11:58 AM -0800 17/2/03, Shahram Davari wrote: >Stewart, > >> >> > Therefore a more generic >> > method that applies to all types of payloads should be used. >> >> False - only to those payloads that don't have the TCP friendly >> property. >> > >Even if a PE knows that the payload is TCP, how do you guarantee that >the customer has intentionally or unintentionally implemented the TCP >back off. > >Yours, >-Shahram >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Tue, 18 Feb 2003 08:14:06 +0000 Organization: Cisco Systems, Inc. Lines: 95 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03CC5@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Keith Knightson Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Keith You are correct(ish) for TDM. Some TDM emulations can hid stream damage due to packet loss. However the congestion loss is the Internet's way of crying for help, and if the packet loss continues then the PEs have to reduce the offered load, which they can only do by shutting down one of more PWs. Quite the opposite is true in the case of packet. Here packet loss in the PSN translates to packet loss in the emulated service and if the service is carrying TCP, TP4 or similar, then PSN loss will trigger exactly the right behaviour in the hosts ulimately generating the traffic. In such casses shutting down the service would be OTT. Then there is ATM, which could be carrying anything. If we KNEW it was carrying packets, then we could be sure that the right things will happen, otherwise we have to start shutting down PWs. Perhaps we can operate packet strategy in STU mode and TDM strategy in cell mode? Regards Stewart Keith Knightson wrote: > Guys, > > If you are emulating TDM you cannot surely make any assumptions at all > about the protocols being used by the customer over the TDM. > > Conversely, if the protocol on the CE-PE is known then TDM across the > core is not necessary, since this protocol can be extracted from the TDM > on the access and sent as IP payload across the core. > > Surely the reason for a TDM PWE in the first place is to provide a means > of conveying a transparent TDM stream all the way across an IP core? > > If the PSN underneath a TDM PWE becomes congested, such that blocks of > bits are lost, then the PEs will have to detect it, at the PWE layer. I > do not think that the underlying PSN can be relied upon to perform that > function. The PEs have to detect it, and take action, like presumably > turn off the clock towards the CE, or use OAM framing bits or something > similar. I would also have thought that "normal" TDM OAM would have to > be emulated across the core for this purpose. > > All this talk about about customer back-off at the TCP level eludes > me,..., why on earth would any customer who is already operating > already TCP over IP, want some emulated TDM PWE across an IP core? Why > is IP in IP not a better solution? > > It seems to be that an emulated TDM PWE should be just that, ie an > emulated TDM pipe. TDM is the PWE payload, not the payload of the TDM. > The payload of the TDM is unknown. Conversely, if it is known then the > TDM is not required, since it can be handled directly. > > I must be missing something, brain cells probably. > > Regards > > Keith > > > > > At 11:58 AM -0800 17/2/03, Shahram Davari wrote: > >> Stewart, >> >>> >>> > Therefore a more generic >>> > method that applies to all types of payloads should be used. >>> >>> False - only to those payloads that don't have the TCP friendly >>> property. >>> >> >> Even if a PE knows that the payload is TCP, how do you guarantee that >> the customer has intentionally or unintentionally implemented the TCP >> back off. >> >> Yours, >> -Shahram >> _______________________________________________ >> 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 avt-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Kreuter Ruediger Subject: updated "Clearmode" (64kbit/s unrestricted) Internet-draft Date: Tue, 18 Feb 2003 11:29:07 +0100 Lines: 28 Sender: avt-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'kschong@att.com'" , "'taylor@nortelnetworks.com'" Return-path: To: "'avt@ietf.org'" , "'mmusic@ietf.org'" , "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Status: O FYI, I have submitted an update of the CLEARMODE Internet draft. You find it at http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clearmode-01.txt The major update, due to comments according the support of Nx64kbit/s and similar standardization activities in ITU's SG 11, is the introduction of Nx64kbit/s support. Two remarks to this issue: 1) 1x64kbit/s is used in current VoIP products and supported by most DSP Providers. Therefore I would like to keep Nx64kbit/s with N>1 as an option. 2) We currently do not have a VoIP product supporting Nx64kbit/s, therefore I introduced this merely as a discussion input. So if anybody has a working Nx64kbit/s solution I would like to get some comments on the packatization method in that case. If nobody has a solution I will delete this feature from the next version of this draft. Besides, the first draft initiated a controverse discussion, if this should be "audio/CLEARMODE" or e.g. "application/CLEARMODE". IMHO none of the existing IANA content types really fits for CLEARMODE. Since 1x64kbit/s is also used for 7kHz voice (despite G.722) I kept "audio" in this draft. Regards Ruediger _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 16:30:16 +0200 Lines: 220 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'pwe3@ietf.org'" , Keith Knightson , "Mark Townsley (E-mail)" , "Luca (E-mail)" , "Shahram Davari (E-mail)" Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart and all, It looks like we have two different cases to consider. 1. On one hand, we have the TDM PWs. This case can be described as following: a) Definitely TCP-like traffic behavior in the payload b) It is easy to detect lost packets at the PW egress, because: * All the proposed encapsulations assume sequencing * All the proposed encapsulations assume packets of fixed size and hence a constant average packet arrival rate (in other words, you do not have to wait for the next received packet - which may well happen once the congestion condition is already over - to guess that you have meanwhile lost thousands of them) c) It is easy to send backward notification - all the proposed encapsulations reserve a dedicated flag in the control word exactly for these purposes d) It is easy to decide how to handle the congestion (since you cannot back off gradually, all that remains is to shut down the service and restart it after some timeout) 2. On the other hand, we have all the rest of PWs. This case can be described like following: a) They may carry TCP-like traffic - and then, they may not (BTW, is, say, SNA TCP-like? it is carried over Ethernet and FR, and these can be carried over PWs). And, BTW, nothing prevents a mix of different types of traffic over a single FR DLCI being carried over a PW - that is what RFC 1490 and its updates are about... b) It is difficult to detect lost packets, because: * Some of the proposed encapsulations do not use sequencing * Even with sequencing, you must wait for the next received packet to decide that you have lost some packets (and, if you use re-ordering, you may wait some more after that) c) None of the proposed encapsulations have flags for reporting lost packets back. And, what is even more important, you may not have an appropriate packet at hand to piggi-back such a flag; nor would you really know how to interpret it (i.e., you would probably like to know how many packets have been lost) d) Finally, you have a wide range of options for handling the detected congestion (provided, of course, that you have some deduced that a congestion is taking place), e.g.: * Relegate the responsibility to the NSP (if you have one and if you assume that it can handle the congestion) * Do some gradual back-off at the PW level and then try to come back * Shut down the service completely and then try to restart it (I do not know if this list is complete, but it is surely long enough to make the selection complicated). Please note that, until now, the discussion for congestion detection and handling concentrated on the capabilities of the PW data path. I believe that this was partially due to the fact that, for TDM PWs (that natively are the prime suspects for creating congestion) this seems an easy task; and, partly, because PWE3 explicitly allows manual setup and teardown of PWs. However, shifting the congestion-related activities to the PWE3 control plane seems to me worth considering for the following reasons: 1. Congestion condition could be easily deduced e.g., from the information about the nubmer of bytes send during a certain interval and information about the number of bytes received by the "remote" side for the same interval. The control protocol could allow exchange of this information in quite a generic way. 2. The congestion handling actions could be coordinated betwen the ends of the PW. E.g., if one PE decides to shut down a certain PW and then restart it after a certain period, such an action should be better synchronized between the two PW ends. I do not even want to think of possible consequences of one PE taking one type of action (e.g., relegate to NSP( while the other takes another action (e.g., shut down the connection). The control protocol could, hopefully, take care of this process also 3. Last but not least, should the control protocol session (be it LDP or L2TPv3) fail due to congestion, all the associated PWs would be shut down as well. Of course, congestion handling and detection using the control protocol would be probably slower than handling it in the data path - but, maybe, this could be tolerated at least in the cases when we do not see any clear way for handling it in the data path? And the problem of manually configured PWs remains in any case... Hopefully these notes will be of some interest. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, February 18, 2003 10:14 AM > To: Keith Knightson > Cc: 'pwe3@ietf.org' > Subject: Re: [PWE3] PWE3 congestion > > > Keith > > You are correct(ish) for TDM. Some TDM emulations can hid stream > damage due to packet loss. However the congestion loss is the > Internet's way of crying for help, and if the packet loss continues > then the PEs have to reduce the offered load, which they can only do > by shutting down one of more PWs. > > Quite the opposite is true in the case of packet. Here packet > loss in the PSN translates to packet loss in the emulated service > and if the service is carrying TCP, TP4 or similar, then PSN loss > will trigger exactly the right behaviour in the hosts ulimately > generating the traffic. In such casses shutting down the service > would be OTT. > > Then there is ATM, which could be carrying anything. If we KNEW it > was carrying packets, then we could be sure that the right things > will happen, otherwise we have to start shutting down PWs. Perhaps > we can operate packet strategy in STU mode and TDM strategy in cell > mode? > > Regards > > Stewart > > Keith Knightson wrote: > > Guys, > > > > If you are emulating TDM you cannot surely make any > assumptions at all > > about the protocols being used by the customer over the TDM. > > > > Conversely, if the protocol on the CE-PE is known then TDM > across the > > core is not necessary, since this protocol can be extracted > from the TDM > > on the access and sent as IP payload across the core. > > > > Surely the reason for a TDM PWE in the first place is to > provide a means > > of conveying a transparent TDM stream all the way across an IP core? > > > > If the PSN underneath a TDM PWE becomes congested, such > that blocks of > > bits are lost, then the PEs will have to detect it, at the > PWE layer. I > > do not think that the underlying PSN can be relied upon to > perform that > > function. The PEs have to detect it, and take action, like > presumably > > turn off the clock towards the CE, or use OAM framing bits > or something > > similar. I would also have thought that "normal" TDM OAM > would have to > > be emulated across the core for this purpose. > > > > All this talk about about customer back-off at the TCP level eludes > > me,..., why on earth would any customer who is already operating > > already TCP over IP, want some emulated TDM PWE across an > IP core? Why > > is IP in IP not a better solution? > > > > It seems to be that an emulated TDM PWE should be just that, ie an > > emulated TDM pipe. TDM is the PWE payload, not the payload > of the TDM. > > The payload of the TDM is unknown. Conversely, if it is > known then the > > TDM is not required, since it can be handled directly. > > > > I must be missing something, brain cells probably. > > > > Regards > > > > Keith > > > > > > > > > > At 11:58 AM -0800 17/2/03, Shahram Davari wrote: > > > >> Stewart, > >> > >>> > >>> > Therefore a more generic > >>> > method that applies to all types of payloads should be used. > >>> > >>> False - only to those payloads that don't have the TCP friendly > >>> property. > >>> > >> > >> Even if a PE knows that the payload is TCP, how do you > guarantee that > >> the customer has intentionally or unintentionally > implemented the TCP > >> back off. > >> > >> Yours, > >> -Shahram > >> _______________________________________________ > >> 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Chris Metz Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 10:34:00 -0500 Lines: 15 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'stbryant@cisco.com'" , "'pwe3@ietf.org'" , Keith Knightson , "Mark Townsley (E-mail)" , "Luca (E-mail)" , "Shahram Davari (E-mail)" Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Sasha Vainshtein In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 04:30 PM 2/18/2003 +0200, Sasha Vainshtein wrote: >Stewart and all, >It looks like we have two different cases to consider. > >1. On one hand, we have the TDM PWs. This case can be described as > following: > a) Definitely TCP-like traffic behavior in the payload Sasha, do you mean definitely NOT TCP-like traffic behavior in the payload? I am not clear as to how one could make the assumption that a TDM circuit is carrying TCP. Thanks for the clarification From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 17:37:43 +0200 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'stbryant@cisco.com'" , "'pwe3@ietf.org'" , Keith Knightson , "Mark Townsley (E-mail)" , "Luca (E-mail)" , "Shahram Davari (E-mail)" Return-path: To: "'Chris Metz'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Chris, Thanl you for correction. You are right, of course, the TDM payload is definitely NOT TCP-like. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Chris Metz [mailto:chmetz@cisco.com] > Sent: Tuesday, February 18, 2003 5:34 PM > To: Sasha Vainshtein > Cc: 'stbryant@cisco.com'; 'pwe3@ietf.org'; Keith Knightson; > Mark Townsley (E-mail); Luca (E-mail); Shahram Davari (E-mail) > Subject: RE: [PWE3] PWE3 congestion > > > At 04:30 PM 2/18/2003 +0200, Sasha Vainshtein wrote: > >Stewart and all, > >It looks like we have two different cases to consider. > > > >1. On one hand, we have the TDM PWs. This case can be described as > > following: > > a) Definitely TCP-like traffic behavior in the payload > > Sasha, do you mean definitely NOT TCP-like traffic behavior > in the payload? > I am not clear as to how one could make the assumption that a > TDM circuit > is carrying TCP. > > Thanks for the clarification > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 11:05:25 -0500 Lines: 121 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Keith, et.al. Every time I read statements about "shutting down PWs" I shudder. In my view this whole discussion is based on the wrong premise, which is that congestion is bad and the network needs to solve that situation autonomously. Why would congestion be bad? Isn't that up to the Service Provider to decide? In general, a Service Provider will use PWs to carry revenue generating services. Packet loss may be acceptable for certain services and not for others. If packet loss is to be avoided, the Service Provider will need to make sure that it doesn't occur, e.g. through bandwidth reservation and rate limiting at the ingress of his network. The network should never autonomously decide to throttle or shut down PWs. Regards, Peter -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Tuesday, February 18, 2003 3:14 AM To: Keith Knightson Cc: 'pwe3@ietf.org' Subject: Re: [PWE3] PWE3 congestion Keith You are correct(ish) for TDM. Some TDM emulations can hid stream damage due to packet loss. However the congestion loss is the Internet's way of crying for help, and if the packet loss continues then the PEs have to reduce the offered load, which they can only do by shutting down one of more PWs. Quite the opposite is true in the case of packet. Here packet loss in the PSN translates to packet loss in the emulated service and if the service is carrying TCP, TP4 or similar, then PSN loss will trigger exactly the right behaviour in the hosts ulimately generating the traffic. In such casses shutting down the service would be OTT. Then there is ATM, which could be carrying anything. If we KNEW it was carrying packets, then we could be sure that the right things will happen, otherwise we have to start shutting down PWs. Perhaps we can operate packet strategy in STU mode and TDM strategy in cell mode? Regards Stewart Keith Knightson wrote: > Guys, > > If you are emulating TDM you cannot surely make any assumptions at all > about the protocols being used by the customer over the TDM. > > Conversely, if the protocol on the CE-PE is known then TDM across the > core is not necessary, since this protocol can be extracted from the TDM > on the access and sent as IP payload across the core. > > Surely the reason for a TDM PWE in the first place is to provide a means > of conveying a transparent TDM stream all the way across an IP core? > > If the PSN underneath a TDM PWE becomes congested, such that blocks of > bits are lost, then the PEs will have to detect it, at the PWE layer. I > do not think that the underlying PSN can be relied upon to perform that > function. The PEs have to detect it, and take action, like presumably > turn off the clock towards the CE, or use OAM framing bits or something > similar. I would also have thought that "normal" TDM OAM would have to > be emulated across the core for this purpose. > > All this talk about about customer back-off at the TCP level eludes > me,..., why on earth would any customer who is already operating > already TCP over IP, want some emulated TDM PWE across an IP core? Why > is IP in IP not a better solution? > > It seems to be that an emulated TDM PWE should be just that, ie an > emulated TDM pipe. TDM is the PWE payload, not the payload of the TDM. > The payload of the TDM is unknown. Conversely, if it is known then the > TDM is not required, since it can be handled directly. > > I must be missing something, brain cells probably. > > Regards > > Keith > > > > > At 11:58 AM -0800 17/2/03, Shahram Davari wrote: > >> Stewart, >> >>> >>> > Therefore a more generic >>> > method that applies to all types of payloads should be used. >>> >>> False - only to those payloads that don't have the TCP friendly >>> property. >>> >> >> Even if a PE knows that the payload is TCP, how do you guarantee that >> the customer has intentionally or unintentionally implemented the TCP >> back off. >> >> Yours, >> -Shahram >> _______________________________________________ >> 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 12:22:10 -0500 Lines: 61 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Lloyd, I am still curious about your views on service delivery. Take a service provider who receives thousands of dollars a months for delivering a TDM service. How would you explain to him that the service is shut down, because "the NSP judges likely services using the PW can't be usefully delivered" I still maintain that shutting down a service is not an option for many services carried over PWs. A service provider will need to take action beforehand (i.e. reserve bandwidth for that service) to ensure that congestion does not occur. But if you ignore the commercial aspects of telecommunication, I agree that "Tuning specific NSP types for the traffic/services they're carrying could be a whole ball of implementation-experience fun." Peter -----Original Message----- From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] Sent: Tuesday, February 18, 2003 11:36 AM To: Busschbach, Peter B (Peter) Cc: 'pwe3@ietf.org' Subject: RE: [PWE3] PWE3 congestion On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: > Every time I read statements about "shutting down PWs" I shudder. In > my view this whole discussion is based on the wrong premise, which > is that congestion is bad and the network needs to solve that > situation autonomously. > > Why would congestion be bad? Isn't that up to the Service Provider > to decide? This is, alas, the Internet Engineering Taskforce. Not the Service Provider Engineering Taskforce (aka the mpls forum). > In general, a Service Provider will use PWs to carry > revenue generating services. Packet loss may be acceptable for > certain services and not for others. If packet loss is to be > avoided, the Service Provider will need to make sure that it doesn't > occur, e.g. through bandwidth reservation and rate limiting at the > ingress of his network. shutting down PWs *is* very simple rate limiting at ingress. Ingress to the Internet... > The network should never autonomously decide to throttle or shut down PWs. The (inter)network doesn't make the decision; throttling/loss happens under congestion as a byproduct anyway. The decision to shut down a PW gets made by the NSP if the NSP judges likely services using the PW can't be usefully delivered (e.g. TDM rates not being met). It's not a network decision, because the network is stupid. It's an NSP decision, once you've set your NSP for the PW type and the expected traffic/services over that. Tuning specific NSP types for the traffic/services they're carrying could be a whole ball of implementation-experience fun. L. snipped four list sigs. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Tue, 18 Feb 2003 18:56:40 +0000 Organization: Cisco Systems, Inc. Lines: 165 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) wrote: > Keith, et.al. > > Every time I read statements about "shutting down PWs" I shudder. In > my view this whole discussion is based on the wrong premise, which is > that congestion is bad and the network needs to solve that situation > autonomously. Well congestion is certainly not good and can lead to the collapse of the network if it is not addressed. At some level you need a safetly valve. > > Why would congestion be bad? Because the Internet has a single data-plane used to carry both control and user traffic. Aside from any issues of fairness, there is the need to get routing packets through the network. A network that is so congested that the routing messages get discarded rapidly becomes unstable and collapses. > Isn't that up to the Service Provider to > decide? In general, a Service Provider will use PWs to carry revenue > generating services. Packet loss may be acceptable for certain services > and not for others. If packet loss is to be avoided, the Service Provider > will need to make sure that it doesn't occur, e.g. through bandwidth > reservation and rate limiting at the ingress of his network. The SP can try their best, but what happens when there is a failure, or a missconfiguration? > > The network should never autonomously decide to throttle or shut down PWs. > But it always will. Eventually congestion will get to the point where the routers discard packets. Stewart > Regards, > > Peter > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, February 18, 2003 3:14 AM > To: Keith Knightson > Cc: 'pwe3@ietf.org' > Subject: Re: [PWE3] PWE3 congestion > > > Keith > > You are correct(ish) for TDM. Some TDM emulations can hid stream > damage due to packet loss. However the congestion loss is the > Internet's way of crying for help, and if the packet loss continues > then the PEs have to reduce the offered load, which they can only do > by shutting down one of more PWs. > > Quite the opposite is true in the case of packet. Here packet > loss in the PSN translates to packet loss in the emulated service > and if the service is carrying TCP, TP4 or similar, then PSN loss > will trigger exactly the right behaviour in the hosts ulimately > generating the traffic. In such casses shutting down the service > would be OTT. > > Then there is ATM, which could be carrying anything. If we KNEW it > was carrying packets, then we could be sure that the right things > will happen, otherwise we have to start shutting down PWs. Perhaps > we can operate packet strategy in STU mode and TDM strategy in cell > mode? > > Regards > > Stewart > > Keith Knightson wrote: > >>Guys, >> >>If you are emulating TDM you cannot surely make any assumptions at all >>about the protocols being used by the customer over the TDM. >> >>Conversely, if the protocol on the CE-PE is known then TDM across the >>core is not necessary, since this protocol can be extracted from the TDM >>on the access and sent as IP payload across the core. >> >>Surely the reason for a TDM PWE in the first place is to provide a means >>of conveying a transparent TDM stream all the way across an IP core? >> >>If the PSN underneath a TDM PWE becomes congested, such that blocks of >>bits are lost, then the PEs will have to detect it, at the PWE layer. I >>do not think that the underlying PSN can be relied upon to perform that >>function. The PEs have to detect it, and take action, like presumably >>turn off the clock towards the CE, or use OAM framing bits or something >>similar. I would also have thought that "normal" TDM OAM would have to >>be emulated across the core for this purpose. >> >>All this talk about about customer back-off at the TCP level eludes >>me,..., why on earth would any customer who is already operating >>already TCP over IP, want some emulated TDM PWE across an IP core? Why >>is IP in IP not a better solution? >> >>It seems to be that an emulated TDM PWE should be just that, ie an >>emulated TDM pipe. TDM is the PWE payload, not the payload of the TDM. >>The payload of the TDM is unknown. Conversely, if it is known then the >>TDM is not required, since it can be handled directly. >> >>I must be missing something, brain cells probably. >> >>Regards >> >>Keith >> >> >> >> >>At 11:58 AM -0800 17/2/03, Shahram Davari wrote: >> >> >>>Stewart, >>> >>> >>>> > Therefore a more generic >>>> > method that applies to all types of payloads should be used. >>>> >>>> False - only to those payloads that don't have the TCP friendly >>>> property. >>>> >>> >>>Even if a PE knows that the payload is TCP, how do you guarantee that >>>the customer has intentionally or unintentionally implemented the TCP >>>back off. >>> >>>Yours, >>>-Shahram >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Tue, 18 Feb 2003 19:10:10 +0000 Organization: Cisco Systems, Inc. Lines: 96 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) wrote: > Lloyd, > > I am still curious about your views on service delivery. Take a service > provider who receives thousands of dollars a months for delivering a TDM > service. How would you explain to him that the service is shut down, > because "the NSP judges likely services using the PW can't be usefully delivered" Better to shut down the PW and save the network than loose the whole network. > > I still maintain that shutting down a service is not an option for many > services carried over PWs. A service provider will need to take action > beforehand (i.e. reserve bandwidth for that service) to ensure that congestion > does not occur. I guess that I could accept that no congestion avoidance scheme is needed in a TE network, but the majority of networks are not TE. In a non-TE network, having a congestion discard scheme is an important safety valve. > > But if you ignore the commercial aspects of telecommunication, I agree > that "Tuning specific NSP types for the traffic/services they're > carrying could be a whole ball of implementation-experience fun." > Stewart > Peter > > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Tuesday, February 18, 2003 11:36 AM > To: Busschbach, Peter B (Peter) > Cc: 'pwe3@ietf.org' > Subject: RE: [PWE3] PWE3 congestion > > > On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: > > >>Every time I read statements about "shutting down PWs" I shudder. In >>my view this whole discussion is based on the wrong premise, which >>is that congestion is bad and the network needs to solve that >>situation autonomously. >> >>Why would congestion be bad? Isn't that up to the Service Provider >>to decide? > > > This is, alas, the Internet Engineering Taskforce. > > Not the Service Provider Engineering Taskforce (aka the mpls forum). > > >>In general, a Service Provider will use PWs to carry >>revenue generating services. Packet loss may be acceptable for >>certain services and not for others. If packet loss is to be >>avoided, the Service Provider will need to make sure that it doesn't >>occur, e.g. through bandwidth reservation and rate limiting at the >>ingress of his network. > > > shutting down PWs *is* very simple rate limiting at ingress. Ingress > to the Internet... > > >>The network should never autonomously decide to throttle or shut down PWs. > > > The (inter)network doesn't make the decision; throttling/loss happens > under congestion as a byproduct anyway. The decision to shut down a PW > gets made by the NSP if the NSP judges likely services using the PW > can't be usefully delivered (e.g. TDM rates not being met). > > It's not a network decision, because the network is stupid. It's an > NSP decision, once you've set your NSP for the PW type and the > expected traffic/services over that. > > Tuning specific NSP types for the traffic/services they're carrying > could be a whole ball of implementation-experience fun. > > L. > > snipped four list sigs. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 22:15:57 -0000 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org Return-path: To: stbryant@cisco.com, busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart Bryant wrote 18 February 2003 18:57 > > > > Why would congestion be bad? > > Because the Internet has a single data-plane used to carry > both control > and user traffic. NH=> Stewart, OK.....fine for me with a cnls mode, but can you therefore please explain what GMPLS is about? This is a co cct-sw mode. I assume from this statement GMPLS has no place in the "Internet" because the traffic's data-plane and the control's (and/or management) data-plane are disjoint networks in all functional senses. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 22:39:03 -0000 Lines: 22 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, busschbach@lucent.com, pwe3@ietf.org Return-path: To: L.Wood@eim.surrey.ac.uk X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Opinion or fact? neil > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: 18 February 2003 22:32 > To: Harrison,N,Neil,IKL2 R > Cc: stbryant@cisco.com; ; > Subject: RE: [PWE3] PWE3 congestion > > > On Tue, 18 Feb 2003 neil.2.harrison@bt.com wrote: > > I assume > > from this statement GMPLS has no place in the "Internet" because > > ...it's not IP. > > L. > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 congestion Date: Tue, 18 Feb 2003 18:00:14 -0500 Lines: 115 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'pwe3@ietf.org'" Return-path: To: "'Lloyd Wood'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Lloyd, The charter of the PWE3 WG talks about service emulation over a PSN. Therefore, I thought that this WG was focused on the creation of the mechanism and protocols required for an adequate delivery of these services. I hope this answers your question about what I think the IETF _does_ >From an end-user perspective, shutting down a service is highly undesirable. I agree that excessive packet loss is undesirable also, but I would think that the consequent actions should be focused on restoring an acceptable service level, e.g. through some form of rerouting or protection switching. Stewart wrote in an earlier email: packet "loss is the Internet's way of crying for help" and he argued for the need of a safety valve. This might be a valid point for the Internet at large. And to your point: if a Service Provider decides to offer PW services over The Internet, then he might need to accept that the service can be shut down. However, the charter of the WG doesn't mention The Internet. It mentions PSNs. I think you need to be very careful to mandate such safety valves for PSNs in general. E.g. a PSN might be under complete control of one single Service Provider and hence, for whatever reason, a certain level of congestion might be perfectly fine. Also, for whatever reason, a Service Provider might prefer to keep a PW up, even if packet loss is too high and rerouting is not possible, rather than to shut it down. To come back to my original point when I joined this email threat: I think the discussion should not be: how can we lower the traffic load in the network in case of congestion, e.g. by shutting down PWs. It should be focused on: what tools does a Service Provider need to manage the total portfolio of services he supports over his PSN in a manner that meets his business needs. Peter -----Original Message----- From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] Sent: Tuesday, February 18, 2003 1:03 PM To: Busschbach, Peter B (Peter) Cc: 'pwe3@ietf.org' Subject: RE: [PWE3] PWE3 congestion On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: > I am still curious about your views on service delivery. Take a > service provider who receives thousands of dollars a months for > delivering a TDM service. How would you explain to him that the > service is shut down, because "the NSP judges likely services using > the PW can't be usefully delivered" Well, I'd explain that if the service hadn't been shut down, it would be unuseable for its intended traffic. I'd explain that the network path the service was carried across had not been dimensioned/selected appropriately for its intended traffic -- or was being used for entirely other traffic than agreed in the SLA with the customer and which the NSP was configured for. Such explanations and implementation specifics are outside the scope of PWE3, and outside the scope of the IETF. The service provider's job is to understand the tools he uses to deliver the solution to his customers: their uses, their limitations, so that he knows that the service he is selling can be reasonably provided and guaranteed. (Which is why they build test networks, etc.) This is why the service provider receives those thousands of dollars a month. I am curious about what you think the IETF _does_. L. > I still maintain that shutting down a service is not an option for > many services carried over PWs. A service provider will need to take > action beforehand (i.e. reserve bandwidth for that service) to > ensure that congestion does not occur. > > But if you ignore the commercial aspects of telecommunication, I > agree that "Tuning specific NSP types for the traffic/services > they're carrying could be a whole ball of implementation-experience > fun." > > Peter > > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Tuesday, February 18, 2003 11:36 AM > To: Busschbach, Peter B (Peter) > Cc: 'pwe3@ietf.org' > Subject: RE: [PWE3] PWE3 congestion > > > On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: > > > Every time I read statements about "shutting down PWs" I shudder. In > > my view this whole discussion is based on the wrong premise, which > > is that congestion is bad and the network needs to solve that > > situation autonomously. > > > > Why would congestion be bad? Isn't that up to the Service Provider > > to decide? > > This is, alas, the Internet Engineering Taskforce. > > Not the Service Provider Engineering Taskforce (aka the mpls forum). > > > In general, a Service Provider will use PWs to carry > > revenue generating services. Packet loss may be acceptable for > > certain services and not for others. If packet loss is to be > > avoided, the Service Provider will need to make sure that it doesn't > > occur, e.g. through bandwidth reservation and rate limiting at the > > ingress of his network. > > shutting down PWs *is* very simple rate limiting at ingress. Ingress > to the Internet... > > > The network should never autonomously decide to throttle or shut down PWs. > > The (inter)network doesn't make the decision; throttling/loss happens > under congestion as a byproduct anyway. The decision to shut down a PW > gets made by the NSP if the NSP judges likely services using the PW > can't be usefully delivered (e.g. TDM rates not being met). > > It's not a network decision, because the network is stupid. It's an > NSP decision, once you've set your NSP for the PW type and the > expected traffic/services over that. > > Tuning specific NSP types for the traffic/services they're carrying > could be a whole ball of implementation-experience fun. > > L. > > snipped four list sigs. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Eduard Metz" Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 09:29:36 +0100 Lines: 171 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Return-path: To: "'Busschbach, Peter B \(Peter\)'" , "'Lloyd Wood'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > From an end-user perspective, shutting down a service is > highly undesirable. I agree that excessive packet loss is > undesirable also, but I would think that the consequent > actions should be focused on restoring an acceptable service > level, e.g. through some form of rerouting or protection switching. > For some services, e.g. TDM, the user-perception of excessive packet-loss and a shut down is likely to be the same or similar. Given that some PW services do not tolerate loss very well, shutting down some of these in a PSN may be the only way to restore acceptable service levels for the remaining PW services of the same nature. > However, the charter of the WG doesn't mention The Internet. > It mentions PSNs. I think you need to be very careful to > mandate such safety valves for PSNs in general. E.g. a PSN > might be under complete control of one single Service > Provider and hence, for whatever reason, a certain level of > congestion might be perfectly fine. Also, for whatever > reason, a Service Provider might prefer to keep a PW up, even > if packet loss is too high and rerouting is not possible, > rather than to shut it down. > Would you prefer a situation in which the average packet loss per PW is low, but the service degradation of all PW may be high, over a situation in which some PW are shut, and the remaining are operating normally? > To come back to my original point when I joined this email > threat: I think the discussion should not be: how can we > lower the traffic load in the network in case of congestion, > e.g. by shutting down PWs. It should be focused on: what > tools does a Service Provider need to manage the total > portfolio of services he supports over his PSN in a manner > that meets his business needs. > IMHO congestion in the end will conflict with business needs, and thus needs to be relieved. [I think there is at least some basic agreement here ;-)] Ofcourse measures should be taken to prevent congestion in the first place, however, in case of network failures (link, node) congestion may still occur. In these situations mechanisms need to be availabe to relieve congestion (aka restore acceptable service levels, meet business needs), also for PW. Which mechanism to choose for which PW type, when/how these mechanisms kick-in (and 'kick-out' for that matter) are IMHO the set of "tools" that are within the scope PWE3 (tools for the remainder service portfolio are clearly not). I'm curious to which other 'tools' you envision. cheers, Eduard > Peter > > > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Tuesday, February 18, 2003 1:03 PM > To: Busschbach, Peter B (Peter) > Cc: 'pwe3@ietf.org' > Subject: RE: [PWE3] PWE3 congestion > > > On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: > > > I am still curious about your views on service delivery. Take a > > service provider who receives thousands of dollars a months for > > delivering a TDM service. How would you explain to him that the > > service is shut down, because "the NSP judges likely services using > > the PW can't be usefully delivered" > > Well, I'd explain that if the service hadn't been shut down, it would > be unuseable for its intended traffic. I'd explain that the network > path the service was carried across had not been dimensioned/selected > appropriately for its intended traffic -- or was being used for > entirely other traffic than agreed in the SLA with the customer and > which the NSP was configured for. > > Such explanations and implementation specifics are outside the scope > of PWE3, and outside the scope of the IETF. > > The service provider's job is to understand the tools he uses to > deliver the solution to his customers: their uses, their limitations, > so that he knows that the service he is selling can be reasonably > provided and guaranteed. (Which is why they build test networks, etc.) > This is why the service provider receives those thousands of dollars a > month. > > I am curious about what you think the IETF _does_. > > L. > > > I still maintain that shutting down a service is not an option for > > many services carried over PWs. A service provider will need to take > > action beforehand (i.e. reserve bandwidth for that service) to > > ensure that congestion does not occur. > > > > But if you ignore the commercial aspects of telecommunication, I > > agree that "Tuning specific NSP types for the traffic/services > > they're carrying could be a whole ball of implementation-experience > > fun." > > > > Peter > > > > -----Original Message----- > > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > > Sent: Tuesday, February 18, 2003 11:36 AM > > To: Busschbach, Peter B (Peter) > > Cc: 'pwe3@ietf.org' > > Subject: RE: [PWE3] PWE3 congestion > > > > > > On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: > > > > > Every time I read statements about "shutting down PWs" I > shudder. In > > > my view this whole discussion is based on the wrong premise, which > > > is that congestion is bad and the network needs to solve that > > > situation autonomously. > > > > > > Why would congestion be bad? Isn't that up to the Service Provider > > > to decide? > > > > This is, alas, the Internet Engineering Taskforce. > > > > Not the Service Provider Engineering Taskforce (aka the mpls forum). > > > > > In general, a Service Provider will use PWs to carry > > > revenue generating services. Packet loss may be acceptable for > > > certain services and not for others. If packet loss is to be > > > avoided, the Service Provider will need to make sure that > it doesn't > > > occur, e.g. through bandwidth reservation and rate limiting at the > > > ingress of his network. > > > > shutting down PWs *is* very simple rate limiting at ingress. Ingress > > to the Internet... > > > > > The network should never autonomously decide to throttle > or shut down PWs. > > > > The (inter)network doesn't make the decision; > throttling/loss happens > > under congestion as a byproduct anyway. The decision to > shut down a PW > > gets made by the NSP if the NSP judges likely services using the PW > > can't be usefully delivered (e.g. TDM rates not being met). > > > > It's not a network decision, because the network is stupid. It's an > > NSP decision, once you've set your NSP for the PW type and the > > expected traffic/services over that. > > > > Tuning specific NSP types for the traffic/services they're carrying > > could be a whole ball of implementation-experience fun. > > > > L. > > > > snipped four list sigs. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Wed, 19 Feb 2003 09:17:52 +0000 Organization: Cisco Systems, Inc. Lines: 184 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Lloyd Wood'" , "'pwe3@ietf.org'" Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) wrote: > Lloyd, > > The charter of the PWE3 WG talks about service emulation over a PSN. > Therefore, I thought that this WG was focused on the creation of the > mechanism and protocols required for an adequate delivery of these > services. Over the Internet as it is today. > I hope this answers your question about what I think the IETF _does_ > >>From an end-user perspective, shutting down a service is highly > undesirable. I agree that excessive packet loss is undesirable also, > but I would think that the consequent actions should be focused on > restoring an acceptable service level, e.g. through some form of > rerouting or protection switching. So are you advocating that the only PSN that we specify is MPLS-TE? > > Stewart wrote in an earlier email: packet "loss is the Internet's > way of crying for help" and he argued for the need of a safety valve. > This might be a valid point for the Internet at large. And to your > point: if a Service Provider decides to offer PW services over > The Internet, then he might need to accept that the service can be > shut down. > > However, the charter of the WG doesn't mention The Internet. I think that as this is an IETF WG we can take that as read: Overview of the IETF The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. > It mentions PSNs. I think you need to be very careful to mandate such > safety valves for PSNs in general. E.g. a PSN might be under complete > control of one single Service Provider and hence, for whatever reason, > a certain level of congestion might be perfectly fine. But the concern of the IESG is that PWE3 can and will get connected to the Internet, and if and when that happens, it must not break the Internet. > Also, for whatever reason, a Service Provider might prefer to keep a PW > up, even if packet loss is too high and rerouting is not possible, > rather than to shut it down. > > To come back to my original point when I joined this email threat: I > think the discussion should not be: how can we lower the traffic load > in the network in case of congestion, e.g. by shutting down PWs. > It should be focused on: what tools does a Service Provider need to > manage the total portfolio of services he supports over his PSN in a > manner that meets his business needs. > Other than the design of the PWE3-MIB and network management tools this sounds out of scope. Stewart > Peter > > > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Tuesday, February 18, 2003 1:03 PM > To: Busschbach, Peter B (Peter) > Cc: 'pwe3@ietf.org' > Subject: RE: [PWE3] PWE3 congestion > > > On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: > > >>I am still curious about your views on service delivery. Take a >>service provider who receives thousands of dollars a months for >>delivering a TDM service. How would you explain to him that the >>service is shut down, because "the NSP judges likely services using >>the PW can't be usefully delivered" > > > Well, I'd explain that if the service hadn't been shut down, it would > be unuseable for its intended traffic. I'd explain that the network > path the service was carried across had not been dimensioned/selected > appropriately for its intended traffic -- or was being used for > entirely other traffic than agreed in the SLA with the customer and > which the NSP was configured for. > > Such explanations and implementation specifics are outside the scope > of PWE3, and outside the scope of the IETF. > > The service provider's job is to understand the tools he uses to > deliver the solution to his customers: their uses, their limitations, > so that he knows that the service he is selling can be reasonably > provided and guaranteed. (Which is why they build test networks, etc.) > This is why the service provider receives those thousands of dollars a > month. > > I am curious about what you think the IETF _does_. > > L. > > >>I still maintain that shutting down a service is not an option for >>many services carried over PWs. A service provider will need to take >>action beforehand (i.e. reserve bandwidth for that service) to >>ensure that congestion does not occur. >> >>But if you ignore the commercial aspects of telecommunication, I >>agree that "Tuning specific NSP types for the traffic/services >>they're carrying could be a whole ball of implementation-experience >>fun." >> >>Peter >> >>-----Original Message----- >>From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] >>Sent: Tuesday, February 18, 2003 11:36 AM >>To: Busschbach, Peter B (Peter) >>Cc: 'pwe3@ietf.org' >>Subject: RE: [PWE3] PWE3 congestion >> >> >>On Tue, 18 Feb 2003, Busschbach, Peter B (Peter) wrote: >> >> >>>Every time I read statements about "shutting down PWs" I shudder. In >>>my view this whole discussion is based on the wrong premise, which >>>is that congestion is bad and the network needs to solve that >>>situation autonomously. >>> >>>Why would congestion be bad? Isn't that up to the Service Provider >>>to decide? >> >>This is, alas, the Internet Engineering Taskforce. >> >>Not the Service Provider Engineering Taskforce (aka the mpls forum). >> >> >>>In general, a Service Provider will use PWs to carry >>>revenue generating services. Packet loss may be acceptable for >>>certain services and not for others. If packet loss is to be >>>avoided, the Service Provider will need to make sure that it doesn't >>>occur, e.g. through bandwidth reservation and rate limiting at the >>>ingress of his network. >> >>shutting down PWs *is* very simple rate limiting at ingress. Ingress >>to the Internet... >> >> >>>The network should never autonomously decide to throttle or shut down PWs. >> >>The (inter)network doesn't make the decision; throttling/loss happens >>under congestion as a byproduct anyway. The decision to shut down a PW >>gets made by the NSP if the NSP judges likely services using the PW >>can't be usefully delivered (e.g. TDM rates not being met). >> >>It's not a network decision, because the network is stupid. It's an >>NSP decision, once you've set your NSP for the PW type and the >>expected traffic/services over that. >> >>Tuning specific NSP types for the traffic/services they're carrying >>could be a whole ball of implementation-experience fun. >> >>L. >> >>snipped four list sigs. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Wed, 19 Feb 2003 09:24:18 +0000 Organization: Cisco Systems, Inc. Lines: 72 Sender: pwe3-admin@ietf.org References: <002601c2d7f1$09927ac0$0210010b@grumble> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Busschbach, Peter B (Peter)'" , "'Lloyd Wood'" , pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Eduard Metz Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I completely agree with this position Stewart Eduard Metz wrote: > > >>From an end-user perspective, shutting down a service is >>highly undesirable. I agree that excessive packet loss is >>undesirable also, but I would think that the consequent >>actions should be focused on restoring an acceptable service >>level, e.g. through some form of rerouting or protection switching. >> > > > For some services, e.g. TDM, the user-perception of excessive packet-loss > and a shut down is likely to be the same or similar. Given that some PW > services do not tolerate loss very well, shutting down some of these in a > PSN may be the only way to restore acceptable service levels for the > remaining PW services of the same nature. > > > >>However, the charter of the WG doesn't mention The Internet. >>It mentions PSNs. I think you need to be very careful to >>mandate such safety valves for PSNs in general. E.g. a PSN >>might be under complete control of one single Service >>Provider and hence, for whatever reason, a certain level of >>congestion might be perfectly fine. Also, for whatever >>reason, a Service Provider might prefer to keep a PW up, even >>if packet loss is too high and rerouting is not possible, >>rather than to shut it down. >> > > > Would you prefer a situation in which the average packet loss per PW is low, > but the service degradation of all PW may be high, over a situation in which > some PW are shut, and the remaining are operating normally? > > >>To come back to my original point when I joined this email >>threat: I think the discussion should not be: how can we >>lower the traffic load in the network in case of congestion, >>e.g. by shutting down PWs. It should be focused on: what >>tools does a Service Provider need to manage the total >>portfolio of services he supports over his PSN in a manner >>that meets his business needs. >> > > > IMHO congestion in the end will conflict with business needs, and thus needs > to be relieved. [I think there is at least some basic agreement here ;-)] > > Ofcourse measures should be taken to prevent congestion in the first place, > however, in case of network failures (link, node) congestion may still > occur. In these situations mechanisms need to be availabe to relieve > congestion (aka restore acceptable service levels, meet business needs), > also for PW. > > Which mechanism to choose for which PW type, when/how these mechanisms > kick-in (and 'kick-out' for that matter) are IMHO the set of "tools" that > are within the scope PWE3 (tools for the remainder service portfolio are > clearly not). I'm curious to which other 'tools' you envision. > > cheers, > Eduard > > >>Peter >> From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 11:35:32 -0000 Lines: 48 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org Return-path: To: stbryant@cisco.com, busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Stewart Bryant wrote 19 February 2003 09:18 > Busschbach, Peter B (Peter) wrote: > > Lloyd, > >>From an end-user perspective, shutting down a service is highly > > undesirable. I agree that excessive packet loss is > undesirable also, > > but I would think that the consequent actions should be focused on > > restoring an acceptable service level, e.g. through some form of > > rerouting or protection switching. > > So are you advocating that the only PSN that we specify is MPLS-TE? NH= Yes and no. There are only certain client/server relationships between the 3 network modes of cnls, co pkt-sw and co cct-sw that make sense. - a cnls client can use any of the modes as server - a co pkt-sw client should only use a co pkt-sw or a co cct-sw mode as server - a co cct-sw client should only use a co cct-sw server. Any other relationships lead to one or more functional management problems, eg timing recovery, performance-management, fault-management, traffic-management, etc. However, even though our architectural policy states might state this I would not stop anyone else from doing crazy things if they want....we all have choices and sometimes learning from (bad) experience is the only way. Those who have children will immediately recognise what I mean here. So the trite answer is 'yes' but whether one would use a given technology would be an operators choice....it would depend on the functional 'quality' of the technolgy and fit for purpose....some are better than others. > But the concern of the IESG is that PWE3 can and will get connected to > the Internet, and if and when that happens, it must not break > the Internet. NH=> Which particular 'Internet' are you/IESG talking about here Stewart? Is it: - the classical IP cnls variety? - the MPLS co pkt-sw variety? - or the GMPLS (ie SDH, OTN) co cct-sw variety? Seems to me the 'Internet' means different things to different people.....or have I not grasped the purpose of CCAMPs? regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 12:42:48 -0000 Lines: 16 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, busschbach@lucent.com, pwe3@ietf.org Return-path: To: L.Wood@eim.surrey.ac.uk X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Lloyd Wood wrote 19 February 2003 12:03 > On Tue, 18 Feb 2003 neil.2.harrison@bt.com wrote: > > > Opinion or fact? > > Fact. > > L. NH=> Thanks Lloyd.....but how do you square this remark with CCAMPS activities? > > > On Tue, 18 Feb 2003 neil.2.harrison@bt.com wrote: > > > > I assume > > > > from this statement GMPLS has no place in the "Internet" because > > > > > > ...it's not IP. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Eduard Metz" Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 13:46:08 +0100 Lines: 63 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389014CFFCD@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Return-path: To: , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389014CFFCD@i2km07-ukbr.domain1.systemhost.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > > > So are you advocating that the only PSN that we specify is MPLS-TE? > > NH= Yes and no. There are only certain client/server > relationships between > the 3 network modes of cnls, co pkt-sw and co cct-sw that make sense. > - a cnls client can use any of the modes as server > - a co pkt-sw client should only use a co pkt-sw or a co > cct-sw mode > as server > - a co cct-sw client should only use a co cct-sw server. > Any other relationships lead to one or more functional > management problems, Maybe so, but unfortunately "sense" is not only a function of functional management. It involves a whole lot of other forces that apparently have created a demand for "non-sense" solutions. If the problems associated with these solutions cannot be solved (or not sufficiently solved), maybe the demand goes away (or the solution may not be offered). Anyway the current problem is "PWE3 congestion" .... do you think this is unsolvable when running a co pkt-sw or co cct-sw client (PW) over a clns or co pkt-sw server? > > > But the concern of the IESG is that PWE3 can and will get > connected to > > the Internet, and if and when that happens, it must not break > > the Internet. > NH=> Which particular 'Internet' are you/IESG talking about > here Stewart? > Is it: > - the classical IP cnls variety? > - the MPLS co pkt-sw variety? > - or the GMPLS (ie SDH, OTN) co cct-sw variety? Cannot speak for anybody else, but my vote goes to IP as the technology that successfully implements internetworking functionality. On the other hand, an unfortunate case of PW congestion could break all three. > Seems to me the 'Internet' means different things to > different people.....or > have I not grasped the purpose of CCAMPs? > As far as I understand CCAMP it defines extensions to IP/MPLS control plane technologies so that these can be applied to other type of networks. But does that make the other networks "Internet". If I would modify PSTN control plane technologies for use on IP networks, that does not make my IP network a telephony network does it? (but this is well besides the point of the discussion) cheers, Eduard > regards, Neil > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 14:31:55 -0000 Lines: 90 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org Return-path: To: emetz@thrupoint.net, stbryant@cisco.com, busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eduard....please see below. regards, Neil Eduard Metz wrote 19 February 2003 12:46 > > > So are you advocating that the only PSN that we specify > is MPLS-TE? > > > > NH= Yes and no. There are only certain client/server > > relationships between > > the 3 network modes of cnls, co pkt-sw and co cct-sw that > make sense. > > - a cnls client can use any of the modes as server > > - a co pkt-sw client should only use a co pkt-sw or a co > > cct-sw mode > > as server > > - a co cct-sw client should only use a co cct-sw server. > > Any other relationships lead to one or more functional > > management problems, > > Maybe so, but unfortunately "sense" is not only a function of > functional > management. It involves a whole lot of other forces that > apparently have > created a demand for "non-sense" solutions. If the problems > associated with > these solutions cannot be solved (or not sufficiently > solved), maybe the > demand goes away (or the solution may not be offered). Anyway > the current > problem is "PWE3 congestion" .... do you think this is unsolvable when > running a co pkt-sw or co cct-sw client (PW) over a clns or co pkt-sw > server? NH=> Unfortunately you snipped the remarks in my preceding mail so I'll repeat one of them: "However, even though our architectural policy might state this I would not stop anyone else from doing crazy things if they want....we all have choices and sometimes learning from (bad) experience is the only way." I would not say they are unsolvable, but they may not be 'effectively' solvable....and by this I mean by whatever metric of cost/quality one wants to apply to judge this. Those who do want to do this stuff need to make a call on this. > > > > > > > > But the concern of the IESG is that PWE3 can and will get > > connected to > > > the Internet, and if and when that happens, it must not break > > > the Internet. > > NH=> Which particular 'Internet' are you/IESG talking about > > here Stewart? > > Is it: > > - the classical IP cnls variety? > > - the MPLS co pkt-sw variety? > > - or the GMPLS (ie SDH, OTN) co cct-sw variety? > > Cannot speak for anybody else, but my vote goes to IP as the > technology that > successfully implements internetworking functionality. On the > other hand, an > unfortunate case of PW congestion could break all three. > > > Seems to me the 'Internet' means different things to > > different people.....or > > have I not grasped the purpose of CCAMPs? > > > > As far as I understand CCAMP it defines extensions to IP/MPLS > control plane > technologies so that these can be applied to other type of > networks. NH=> For what purpose? > But > does that make the other networks "Internet". NH=> So why are IETF doing this then? > If I would > modify PSTN control > plane technologies for use on IP networks, that does not make > my IP network > a telephony network does it? (but this is well besides the > point of the > discussion) NH=> No it does not....you are quite right there. So why are IETF working on this stuff then if its nothing to do with the Internet? However, you are right that this discussion does not belong here even though it is pretty well a fundamantal point to everything else. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Eduard Metz" Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 16:41:51 +0100 Lines: 70 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389014CFFD4@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389014CFFD4@i2km07-ukbr.domain1.systemhost.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > neil.2.harrison@bt.com > Sent: woensdag 19 februari 2003 15:32 > To: emetz@thrupoint.net; stbryant@cisco.com; busschbach@lucent.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > Eduard....please see below. regards, Neil > > Eduard Metz wrote 19 February 2003 12:46 > > > > So are you advocating that the only PSN that we specify > > is MPLS-TE? > > > > > > NH= Yes and no. There are only certain client/server > > > relationships between > > > the 3 network modes of cnls, co pkt-sw and co cct-sw that > > make sense. > > > - a cnls client can use any of the modes as server > > > - a co pkt-sw client should only use a co pkt-sw or a co > > > cct-sw mode > > > as server > > > - a co cct-sw client should only use a co cct-sw server. > > > Any other relationships lead to one or more functional > > > management problems, > > > > Maybe so, but unfortunately "sense" is not only a function of > > functional > > management. It involves a whole lot of other forces that > > apparently have > > created a demand for "non-sense" solutions. If the problems > > associated with > > these solutions cannot be solved (or not sufficiently > > solved), maybe the > > demand goes away (or the solution may not be offered). Anyway > > the current > > problem is "PWE3 congestion" .... do you think this is > unsolvable when > > running a co pkt-sw or co cct-sw client (PW) over a clns or > co pkt-sw > > server? > NH=> Unfortunately you snipped the remarks in my preceding > mail so I'll > repeat one of them: > "However, even though our architectural policy might state > this I would not > stop anyone else from doing crazy things if they want....we > all have choices > and sometimes learning from (bad) experience is the only way." > I would not say they are unsolvable, but they may not be 'effectively' > solvable....and by this I mean by whatever metric of > cost/quality one wants > to apply to judge this. Those who do want to do this stuff > need to make a > call on this. > Okay good, though I'm not sure how to relate the remark to the issue (who is the owner of "our policy" and why are things not compliant with that policy "crazy"?). However, pointing out the inefficiencies of particular solutions and their impact on the PW service delivery and operation is indeed important. cheers, Eduard From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Bob Barrett" Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 13:59:11 -0000 Lines: 41 Sender: pwe3-admin@ietf.org References: <3E534BC0.4010907@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "'Lloyd Wood'" , Return-path: To: , "Busschbach, Peter B (Peter)" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E534BC0.4010907@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Snip > It mentions PSNs. I think you need to be very careful to mandate such > safety valves for PSNs in general. E.g. a PSN might be under complete > control of one single Service Provider and hence, for whatever reason, > a certain level of congestion might be perfectly fine. But the concern of the IESG is that PWE3 can and will get connected to the Internet, and if and when that happens, it must not break the Internet. Snip But it is OK if the internet affects the performance of the PWE3 to such a degree that the PWE3 is effectively broken. Users (SPs) with control of their own PSNs are specific cases, the internet (with all of it's uncertainties) is the general case, and PWE3 must address the general case. The user base for PWE3 is very broad in terms of type and performance of PSN. A lot of the issue comes down to how implementations handle late and lost frames in the most part caused by congestion. How much of this process is written into the PWE3 rfcs and how much is left to implementers is the issue. Any mechanism that requires that both ends are using the same method really needs to be in the PWE3 to ensure interoperability. Any mechanism that can work within a PWE3 edge device without any knowledge of the partner does not need to be in the PWE3 drafts. The feedback that I have had from the market is that whilst operators expect their PSNs to be near perfect, they still want Circuit Emulation kit to be able to cope with imperfect PSNs. The profile of variable packet latency and packet loss is the key issue in deciding how complex to make the replay mechanisms and clock mechanism. For example a PSN that drops 1 in 25 of the packets on a regular basis needs special handling for signalling, and network that is 100% most of the time and then has a 50ms outage will not be help by this. Even customers with perfect networks will require the functionality to cope with imperfections, even if they hope it will never be 'used' in anger. Thanks Bob From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: updated "Clearmode" (64kbit/s unrestricted) Internet-d raft Date: Wed, 19 Feb 2003 18:50:28 +0200 Lines: 64 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'kschong@att.com'" , "'taylor@nortelnetworks.com'" , Alik Shimelmits , Akiva Sadovski , Israel Sasson Return-path: To: "'Kreuter Ruediger'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" , "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ruediger and all, Please take a look at http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-05.txt , Section 6.6.2. It seems that the approach and the resulting format are pretty similar. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Kreuter Ruediger [mailto:ruediger.kreuter@siemens.com] > Sent: Tuesday, February 18, 2003 12:29 PM > To: 'avt@ietf.org'; 'mmusic@ietf.org'; 'pwe3@ietf.org' > Cc: 'kschong@att.com'; 'taylor@nortelnetworks.com' > Subject: [PWE3] updated "Clearmode" (64kbit/s unrestricted) > Internet-draft > > > FYI, > I have submitted an update of the CLEARMODE Internet draft. > You find it at > http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clea > rmode-01.txt > > The major update, due to comments according the support of Nx64kbit/s > and similar standardization activities in ITU's SG 11, is the > introduction of > Nx64kbit/s support. Two remarks to this issue: > 1) 1x64kbit/s is used in current VoIP products and supported > by most DSP > Providers. Therefore I would like to keep Nx64kbit/s with > N>1 as an option. > 2) We currently do not have a VoIP product supporting > Nx64kbit/s, therefore > I introduced this merely as a discussion input. > So if anybody has a working Nx64kbit/s solution I would > like to get some > comments on the packatization method in that case. If nobody has a > solution I will delete this feature from the next version > of this draft. > > Besides, the first draft initiated a controverse discussion, > if this should be > "audio/CLEARMODE" or e.g. "application/CLEARMODE". > IMHO none of the existing IANA content types really fits for > CLEARMODE. > Since 1x64kbit/s is also used for 7kHz voice (despite G.722) > I kept "audio" > in this draft. > > Regards > Ruediger > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 congestion Date: Wed, 19 Feb 2003 13:09:15 -0500 Lines: 83 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org Return-path: To: "'Eduard Metz'" , neil.2.harrison@bt.com, stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eduart, The tools that I was talking about are probably the same as the ones you have in mind: the ability to detect packet loss on a PW, the ability to reroute traffic, the ability to change bandwidth reservation parameters and the ability to shut down a PW. I agree with Stewart that not all tools are available in all networks. You use what you have. But a Service Provider should have flexibility. In case of congestion, he might decide to shut down one or more PWs, but not necessarily the ones that are experiencing packet loss. It all depends on the SLA agreements that are in place. I agree with statements made in other emails that the way a Service Provider responds to certain network conditions is outside the scope of the WG. I was not proposing to bring these things into the WG. My point was: why is congestion avoidence in the scope of the WG? Shutting down a PW if you detect congestion is one of many different actions and why would that one be standardized if the others are outside the scope of the WG? The answer is apparently: to protect the Internet. I can accept that. But if we standardize this "PW Back-off mechanism" a Service Provider should be allowed to disable it if the traffic stays within his own network or if the traffic is guaranteed to traverse the networks of other Service Providers that don't require this back-off mechanism. Peter -----Original Message----- From: Eduard Metz [mailto:emetz@thrupoint.net] Sent: Wednesday, February 19, 2003 7:46 AM To: neil.2.harrison@bt.com; stbryant@cisco.com; busschbach@lucent.com Cc: pwe3@ietf.org Subject: RE: [PWE3] PWE3 congestion > > > > So are you advocating that the only PSN that we specify is MPLS-TE? > > NH= Yes and no. There are only certain client/server > relationships between > the 3 network modes of cnls, co pkt-sw and co cct-sw that make sense. > - a cnls client can use any of the modes as server > - a co pkt-sw client should only use a co pkt-sw or a co > cct-sw mode > as server > - a co cct-sw client should only use a co cct-sw server. > Any other relationships lead to one or more functional > management problems, Maybe so, but unfortunately "sense" is not only a function of functional management. It involves a whole lot of other forces that apparently have created a demand for "non-sense" solutions. If the problems associated with these solutions cannot be solved (or not sufficiently solved), maybe the demand goes away (or the solution may not be offered). Anyway the current problem is "PWE3 congestion" .... do you think this is unsolvable when running a co pkt-sw or co cct-sw client (PW) over a clns or co pkt-sw server? > > > But the concern of the IESG is that PWE3 can and will get > connected to > > the Internet, and if and when that happens, it must not break > > the Internet. > NH=> Which particular 'Internet' are you/IESG talking about > here Stewart? > Is it: > - the classical IP cnls variety? > - the MPLS co pkt-sw variety? > - or the GMPLS (ie SDH, OTN) co cct-sw variety? Cannot speak for anybody else, but my vote goes to IP as the technology that successfully implements internetworking functionality. On the other hand, an unfortunate case of PW congestion could break all three. > Seems to me the 'Internet' means different things to > different people.....or > have I not grasped the purpose of CCAMPs? > As far as I understand CCAMP it defines extensions to IP/MPLS control plane technologies so that these can be applied to other type of networks. But does that make the other networks "Internet". If I would modify PSTN control plane technologies for use on IP networks, that does not make my IP network a telephony network does it? (but this is well besides the point of the discussion) cheers, Eduard > regards, Neil > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: Re: PWE3 congestion Date: Thu, 20 Feb 2003 10:03:45 +0000 Organization: Cisco Systems, Inc. Lines: 124 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Eduard Metz'" , neil.2.harrison@bt.com, pwe3@ietf.org Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) wrote: > Eduart, > > The tools that I was talking about are probably the same as the ones > you have in mind: the ability to detect packet loss on a PW, the ability to > reroute traffic, the ability to change bandwidth reservation parameters and > the ability to shut down a PW. > > I agree with Stewart that not all tools are available in all networks. You > use what you have. But a Service Provider should have flexibility. In case of > congestion, he might decide to shut down one or more PWs, but not necessarily > the ones that are experiencing packet loss. It all depends on the SLA agreements > that are in place. > > I agree with statements made in other emails that the way a Service Provider > responds to certain network conditions is outside the scope of the WG. I was > not proposing to bring these things into the WG. My point was: why is > congestion avoidence in the scope of the WG? Shutting down a PW if you > detect congestion is one of many different actions and why would that one > be standardized if the others are outside the scope of the WG? > > The answer is apparently: to protect the Internet. I can accept that. But if > we standardize this "PW Back-off mechanism" a Service Provider should be > allowed to disable it if the traffic stays within his own network or if the > traffic is guaranteed to traverse the networks of other Service Providers > that don't require this back-off mechanism. I agree with most of what you say except the idea of wiring shut the safety valve (although I acknowledge that if customers demand it, then vendors will build it). A better approach would perhaps be to set the protective shutdown at a higher level than that at which the other more selective mechanisms cut in. After all, even well engineered "private" networks may have an unanticipated failure. Stewart > > Peter > > -----Original Message----- > From: Eduard Metz [mailto:emetz@thrupoint.net] > Sent: Wednesday, February 19, 2003 7:46 AM > To: neil.2.harrison@bt.com; stbryant@cisco.com; busschbach@lucent.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > > >>>So are you advocating that the only PSN that we specify is MPLS-TE? >> >>NH= Yes and no. There are only certain client/server >>relationships between >>the 3 network modes of cnls, co pkt-sw and co cct-sw that make sense. >>- a cnls client can use any of the modes as server >>- a co pkt-sw client should only use a co pkt-sw or a co >>cct-sw mode >>as server >>- a co cct-sw client should only use a co cct-sw server. >>Any other relationships lead to one or more functional >>management problems, > > > Maybe so, but unfortunately "sense" is not only a function of functional > management. It involves a whole lot of other forces that apparently have > created a demand for "non-sense" solutions. If the problems associated with > these solutions cannot be solved (or not sufficiently solved), maybe the > demand goes away (or the solution may not be offered). Anyway the current > problem is "PWE3 congestion" .... do you think this is unsolvable when > running a co pkt-sw or co cct-sw client (PW) over a clns or co pkt-sw > server? > > > >> >> >>>But the concern of the IESG is that PWE3 can and will get >> >>connected to >> >>>the Internet, and if and when that happens, it must not break >>>the Internet. >> >>NH=> Which particular 'Internet' are you/IESG talking about >>here Stewart? >>Is it: >>- the classical IP cnls variety? >>- the MPLS co pkt-sw variety? >>- or the GMPLS (ie SDH, OTN) co cct-sw variety? > > > Cannot speak for anybody else, but my vote goes to IP as the technology that > successfully implements internetworking functionality. On the other hand, an > unfortunate case of PW congestion could break all three. > > >>Seems to me the 'Internet' means different things to >>different people.....or >>have I not grasped the purpose of CCAMPs? >> > > > As far as I understand CCAMP it defines extensions to IP/MPLS control plane > technologies so that these can be applied to other type of networks. But > does that make the other networks "Internet". If I would modify PSTN control > plane technologies for use on IP networks, that does not make my IP network > a telephony network does it? (but this is well besides the point of the > discussion) > > cheers, > Eduard > > >>regards, Neil >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-atm-encap-01.txt Date: Thu, 20 Feb 2003 07:37:46 -0500 Lines: 82 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart 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 : Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks Author(s) : L. Martini et al. Filename : draft-ietf-pwe3-atm-encap-01.txt Pages : 34 Date : 2003-2-19 A framework for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [3]. This draft provides encapsulation formats and guidelines for transporting a variety of ATM services over a PSN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-atm-encap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-atm-encap-01.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-atm-encap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-ethernet-encap-02.txt Date: Thu, 20 Feb 2003 07:37:51 -0500 Lines: 84 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart 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 : Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks Author(s) : L. Martini et al. Filename : draft-ietf-pwe3-ethernet-encap-02.txt Pages : 18 Date : 2003-2-19 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an IP or MPLS network. This enables service providers to offer 'emulated' ethernet services over existing IP or MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a 'point-to-point ethernet' service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ethernet-encap-02.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-ethernet-encap-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-00.txt Date: Thu, 20 Feb 2003 07:37:57 -0500 Lines: 83 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart 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 : IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) Author(s) : L. Martini, W. Townsley Filename : draft-ietf-pwe3-iana-allocation-00.txt Pages : 0 Date : 2003-2-19 The Control and maintenance protocol for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [2]. This document pre-allocates the fixed Pseudo-wire identifier , and other fixed protocol values that are to be assigned by IANA using the 'IETF Consensus' policy defined in RFC2434 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-iana-allocation-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-iana-allocation-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 congestion Date: Thu, 20 Feb 2003 09:36:12 -0500 Lines: 134 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Eduard Metz'" , neil.2.harrison@bt.com, pwe3@ietf.org Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I agree -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Thursday, February 20, 2003 5:04 AM To: Busschbach, Peter B (Peter) Cc: 'Eduard Metz'; neil.2.harrison@bt.com; pwe3@ietf.org Subject: Re: [PWE3] PWE3 congestion Busschbach, Peter B (Peter) wrote: > Eduart, > > The tools that I was talking about are probably the same as the ones > you have in mind: the ability to detect packet loss on a PW, the ability to > reroute traffic, the ability to change bandwidth reservation parameters and > the ability to shut down a PW. > > I agree with Stewart that not all tools are available in all networks. You > use what you have. But a Service Provider should have flexibility. In case of > congestion, he might decide to shut down one or more PWs, but not necessarily > the ones that are experiencing packet loss. It all depends on the SLA agreements > that are in place. > > I agree with statements made in other emails that the way a Service Provider > responds to certain network conditions is outside the scope of the WG. I was > not proposing to bring these things into the WG. My point was: why is > congestion avoidence in the scope of the WG? Shutting down a PW if you > detect congestion is one of many different actions and why would that one > be standardized if the others are outside the scope of the WG? > > The answer is apparently: to protect the Internet. I can accept that. But if > we standardize this "PW Back-off mechanism" a Service Provider should be > allowed to disable it if the traffic stays within his own network or if the > traffic is guaranteed to traverse the networks of other Service Providers > that don't require this back-off mechanism. I agree with most of what you say except the idea of wiring shut the safety valve (although I acknowledge that if customers demand it, then vendors will build it). A better approach would perhaps be to set the protective shutdown at a higher level than that at which the other more selective mechanisms cut in. After all, even well engineered "private" networks may have an unanticipated failure. Stewart > > Peter > > -----Original Message----- > From: Eduard Metz [mailto:emetz@thrupoint.net] > Sent: Wednesday, February 19, 2003 7:46 AM > To: neil.2.harrison@bt.com; stbryant@cisco.com; busschbach@lucent.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 congestion > > > > >>>So are you advocating that the only PSN that we specify is MPLS-TE? >> >>NH= Yes and no. There are only certain client/server >>relationships between >>the 3 network modes of cnls, co pkt-sw and co cct-sw that make sense. >>- a cnls client can use any of the modes as server >>- a co pkt-sw client should only use a co pkt-sw or a co >>cct-sw mode >>as server >>- a co cct-sw client should only use a co cct-sw server. >>Any other relationships lead to one or more functional >>management problems, > > > Maybe so, but unfortunately "sense" is not only a function of functional > management. It involves a whole lot of other forces that apparently have > created a demand for "non-sense" solutions. If the problems associated with > these solutions cannot be solved (or not sufficiently solved), maybe the > demand goes away (or the solution may not be offered). Anyway the current > problem is "PWE3 congestion" .... do you think this is unsolvable when > running a co pkt-sw or co cct-sw client (PW) over a clns or co pkt-sw > server? > > > >> >> >>>But the concern of the IESG is that PWE3 can and will get >> >>connected to >> >>>the Internet, and if and when that happens, it must not break >>>the Internet. >> >>NH=> Which particular 'Internet' are you/IESG talking about >>here Stewart? >>Is it: >>- the classical IP cnls variety? >>- the MPLS co pkt-sw variety? >>- or the GMPLS (ie SDH, OTN) co cct-sw variety? > > > Cannot speak for anybody else, but my vote goes to IP as the technology that > successfully implements internetworking functionality. On the other hand, an > unfortunate case of PW congestion could break all three. > > >>Seems to me the 'Internet' means different things to >>different people.....or >>have I not grasped the purpose of CCAMPs? >> > > > As far as I understand CCAMP it defines extensions to IP/MPLS control plane > technologies so that these can be applied to other type of networks. But > does that make the other networks "Internet". If I would modify PSTN control > plane technologies for use on IP networks, that does not make my IP network > a telephony network does it? (but this is well besides the point of the > discussion) > > cheers, > Eduard > > >>regards, Neil >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Renwei Li" Subject: Confusion in Header Processing Date: Thu, 20 Feb 2003 14:51:30 -0800 Lines: 16 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: Confusion in Header Processing Thread-Index: AcLZMpvD02BidxL6TdWQ+Usebj8hNw== To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KMsvp23419 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O There is a confusion between [pwe3-control] draft and [pwe3-ether-encap] draft with respect to header processing. According to [pwe3-ether-encap], the header processing of L2 PDUs is part of NSP functions which can be done at either of ingress PE and egress PE (see Fig. 3). But according to [pwe3-control], if the header of the transported L2 PDU is modified, it MUST be done at the egress LSR only (see Section 3). Two different drafts should be made consistent with each other, and I think that [pwe3-ether-encap] makes more sense than [pwe3-control] with respect to the above point. Just 2 cents, Renwei From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Tommy Long" Subject: RE: Confusion in Header Processing Date: Fri, 21 Feb 2003 18:48:30 -0500 Lines: 49 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: To: "'Renwei Li'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O To add a few more cents.... pwe3-ethernet-encap version 2 has a conflict on whether "tag" mode has to contain a tag. - bottom page 4 "An ethernet PW can operate in one of two modes: "raw mode" or "tagged mode". In tagged mode, each frame MUST contain an 802.1Q VLAN tag, and the tag value is meaningful to the NSPs at the two PW endpoints" - "3.1.2. Tagged Mode The ethernet frame may contain an 802.1Q tag, in this..." Tommy Long Allied Telesyn Networks > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Renwei Li > Sent: Thursday, February 20, 2003 5:52 PM > To: pwe3@ietf.org > Subject: [PWE3] Confusion in Header Processing > > > There is a confusion between [pwe3-control] draft and > [pwe3-ether-encap] draft with respect to header processing. > > According to [pwe3-ether-encap], the header processing of L2 > PDUs is part of NSP functions which can be done at either of > ingress PE and egress PE (see Fig. 3). But according to > [pwe3-control], if the header of the transported L2 PDU is > modified, it MUST be done at the egress LSR only (see Section 3). > > Two different drafts should be made consistent with each > other, and I think that [pwe3-ether-encap] makes more sense > than [pwe3-control] with respect to the above point. > > Just 2 cents, > > Renwei > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Tommy Long" Subject: RE: Confusion in Header Processing Date: Mon, 24 Feb 2003 10:37:26 -0500 Lines: 106 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: To: "'Bob Barrett'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hello Bob Barrett, hope all is well.... It appears to be required as you say below to have the tag present for tag mode; just want any ambiguity removed. As for raw mode, I read it that the system is VLAN-unaware so there may or may not be a tag but there's little need for the NSP to look for a TPID to determine whether the tag is there or not. You do bring up an interesting point about how a PW should handle nested tags.....is this in scope and if so is it tag mode and signaled with PW Type ="0x0004 Ethernet VLAN"? Tommy > -----Original Message----- > From: Bob Barrett [mailto:bob.barrett@fitl.com] > Sent: Monday, February 24, 2003 7:42 AM > To: Tommy Long; 'Renwei Li'; pwe3@ietf.org > Subject: RE: [PWE3] Confusion in Header Processing > > > Tommy > > Isn't this resolved by the content of the type field? > > I agree that the PWE3 spec should be unambiguous. Raw mode > requires a normal type field, tagged mode requires a VLAN type field. > > Note that 802.1 is currently debating nested tagging. > > Bob > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On > Behalf Of Tommy Long > Sent: Friday, February 21, 2003 11:48 PM > To: 'Renwei Li'; pwe3@ietf.org > Subject: RE: [PWE3] Confusion in Header Processing > > > To add a few more cents.... > > pwe3-ethernet-encap version 2 has a conflict on whether > "tag" mode has to contain a tag. > > - bottom page 4 > "An ethernet PW can operate in one of two modes: "raw > mode" or "tagged > mode". In tagged mode, each frame MUST contain an 802.1Q VLAN tag, > and the tag value is meaningful to the NSPs at the two PW > endpoints" > > - "3.1.2. Tagged Mode > > The ethernet frame may contain an 802.1Q tag, in this..." > > Tommy Long > Allied Telesyn Networks > > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of > > Renwei Li > > Sent: Thursday, February 20, 2003 5:52 PM > > To: pwe3@ietf.org > > Subject: [PWE3] Confusion in Header Processing > > > > > > There is a confusion between [pwe3-control] draft and > > [pwe3-ether-encap] draft with respect to header processing. > > > > According to [pwe3-ether-encap], the header processing of > L2 PDUs is > > part of NSP functions which can be done at either of ingress PE and > > egress PE (see Fig. 3). But according to [pwe3-control], if > the header > > of the transported L2 PDU is modified, it MUST be done at > the egress > > LSR only (see Section 3). > > > > Two different drafts should be made consistent with each > other, and I > > think that [pwe3-ether-encap] makes more sense than [pwe3-control] > > with respect to the above point. > > > > Just 2 cents, > > > > Renwei > > _______________________________________________ > > 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-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: 56th IETF WG & BOF Scheduling - Draft Agenda as of February 24 (fwd) Date: Mon, 24 Feb 2003 16:16:42 -0700 Lines: 207 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Note the change for PWE3... It's now tentatively slated for Wednesday @1530. -danny From dinaras@ietf.org Wed Dec 27 16:41:43 2006 Date: Mon, 24 Feb 2003 17:12:14 -0500 To: wgchairs@ietf.org, bofchairs@ietf.org, iesg@ietf.org From: Dinara Suleymanova Subject: 56th IETF WG & BOF Scheduling - Draft Agenda as of February 24 Status: O Please find below the DRAFT Agenda as of Today. Tomorrow, Tuesday, February 25th at 1700 the scheduling will close. Make sure that you have requested to meet at the 56th IETF . The below Draft Agenda has changed (mostly TSV groups' schedules) Send your comments (if you have them) as soon as possible before we close the scheduling. Thanks. +++ (As of February 24th, 2003) Draft Agenda of the Fifty-sixth IETF March 16-21, 2003 SUNDAY, March 16, 2003 1000-1700 IEPG Meeting - 1200-1900 Registration - 1300-1330 Newcomer's Orientation - 1330-1400 IETF Standards Process Orientation - 1500-1700 Security Tutorial - 1700-1900 Welcome Reception - MONDAY, March 17, 2003 0800-1930 IETF Registration - 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting GEN ipr Intellectual Property Rights WG INT dhc Dynamic Host Configuration WG SUB ccamp Common Control and Measurement Plane WG TSV nsis Next Steps in Signaling WG TSV rddp Remote Direct Data Placement WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP trade Internet Open Trading Protocol WG INT pana Protocol for carrying Authentication for Network Access WG OPS mboned MBONE Deployment WG OPS rmonmib Remote Network Monitoring WG RTG ospf Open Shortest Path First IGP WG SEC krb-wg Kerberos WG TSV sip Session Initiation Protocol WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP opes Open Pluggable Edge Services WG APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT eap Extensible Authentication Protocol WG OPS opsarea Operations & Management Open Area SEC ipsp IP Security Policy WG TSV rmt Reliable Multicast Transport WG TSV rserpool Reliable Server Pooling WG 1730-1930 Break 1930-2200 Evening Sessions APP xmpp Extensible Messaging and Presence Protocol WG INT ipv6 IP Version 6 Working Group WG RTG rtgarea Routing Area Meeting SEC msec Multicast Security WG SUB tewg Internet Traffic Engineering WG TSV rohc Robust Header Compression WG TSV sipping Session Initiation Proposal Investigation WG TUESDAY, March 18, 2003 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP geopriv Geographic Location/Privacy WG INT dnsext DNS Extensions WG INT ipoib IP over InfiniBand WG OPS bmwg Benchmarking Methodology WG RTG rpsec Routing Protocol Security Requirements WG SUB mpls Multiprotocol Label Switching WG TSV nfsv4 Network File System Version 4 WG 1130-1300 Break 1300-1400 Afternoon Sessions I APP fax Internet Fax WG APP ldup LDAP Duplication/Replication/Update Protocols WG INT nemo Network Mobility WG OPS entmib Entity MIB WG SEC smime S/MIME Mail Security WG TSV nsis Next Steps in Signaling WG TSV spirits Service in the PSTN/IN Requesting InTernet Service WG 1415-1515 Afternoon Sessions II APP ldapbis LDAP (v3) Revision WG OPS dnsop Domain Name Server Operations WG RTG forces Forwarding and Control Element Separation WG SEC syslog Security Issues in Network Event Logging WG TSV ips IP Storage WG TSV speechsc Speech Services Control WG 1515-1545 Break (Refreshments provided) - 1545-1645 Afternoon Sessions III APP webdav WWW Distributed Authoring and Versioning WG INT send Securing Neighbor Discovery WG RTG pim Protocol Independent Multicast WG TSV ippm IP Performance Metrics WG TSV midcom Middlebox Communication WG 1700-1800 Afternoon Sessions IV APP lemonade License to Enhance Messaging Oriented Network Access for Diverse Endpoints PWG APP webdav WWW Distributed Authoring and Versioning WG INT itrace ICMP Traceback WG OPS grow Global Routing Operations BOF SEC ipseckey IPSEC KEYing information resource record WG TSV iptel IP Telephony WG TSV rddp Remote Direct Data Placement WG WEDNESDAY, March 19, 2003 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG OPS v6ops IPv6 Operations WG TSV dccp Datagram Congestion Control Protocol WG TSV enum Telephone Number Mapping WG 1130-1300 Break 1300-1500 Afternoon Sessions I INT ipcdn IP over Cable Data Network WG INT magma Multicast & Anycast Group Membership WG OPS aaa Authentication, Authorization and Accounting WG SEC inch Extended Incident Handling WG SUB ppvpn Provider Provisioned Virtual Private Networks WG TSV avt Audio/Video Transport WG TSV ieprep Internet Emergency Preparedness WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP crisp Cross Registry Information Service Protocol WG INT mobileip IP Routing for Wireless/Mobile Hosts WG RTG idr Inter-Domain Routing WG SEC ipsec IP Security Protocol WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG TSV sipping Session Initiation Proposal Investigation WG 1730-1930 Break 1930-2200 Open IESG Plenary - 2230 Late Night Session PGP Key Signing THURSDAY, March 20, 2003 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP provreg Provisioning Registry Protocol WG INT ipv6 IP Version 6 Working Group WG SEC pkix Public-Key Infrastructure (X.509) WG TSV avt Audio/Video Transport WG TSV trigtran Triggers for Transport BOF 1130-1300 Break 1300-1500 Afternoon Sessions I INT nsiim Next Steps in IP Mobility BOF RTG manet Mobile Ad-hoc Networks WG SEC sasl Simple Authentication and Security Layer WG SUB gsmp General Switch Management Protocol WG TSV seamoby Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting WG TSV tsvwg Transport Area Working Group 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II INT eap Extensible Authentication Protocol WG OPS ipfix IP Flow Information Export WG RTG vrrp Virtual Router Redundancy Protocol WG SEC saag Open Security Area Directorate TSV mmusic Multiparty Multimedia Session Control WG TSV pads & Path-Decoupled Signaling BOF & plpmtud Packetization Layer Path MTU Discovery BOF 1730-1930 Break 1930-2200 Open IAB Plenary - FRIDAY, March 21, 2003 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions GEN problem Problem Statement BOF OPS psamp Packet Sampling WG TSV intersec Transport Service at Intermediary BOF TSV sigtran Signaling Transport WG ------- End of Forwarded Message From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: Draft PWE3 Agenda for IETF 56 Date: Mon, 24 Feb 2003 20:16:59 -0700 Lines: 88 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O If you've requested a slot and don't seen it below please let me know ASAP. If you see "****NEED [] INFO****" under you slot name please provide it or your slot may be reallocated. If any operators are interested in talking about deployment experience with any of the chartered services please let me know. -danny ************ Draft Agenda ************ Pseudo Wire Emulation Edge to Edge (pwe3) Wednesday, March 19 1530-1730 ============================= CHAIR: "Danny McPherson" AGENDA: 1530-1540 Administrivia "Danny McPherson" Agenda Bashing Minutes Blue Sheets WG Document Status 1540-1600 PWE3 Architecture & Congestion Control "Stewart Bryant" http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-02.txt Discussion: 1) Update on current architecture document 2) Discussion of PWE3 Congestion Control 1600-1610 PWE3 OAM: Virtual Circuit Connection Verification "Thomas Nadeau" Discussion: PWE3 OAM Message Mapping and MPLS OAM. Discussion of the VCCV and OAM message mapping drafts, how they fit into and satisfy the MPLS OAM requirements, and next steps. ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-ietf-pwe3-vccv-00.txt ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-ietf-pwe3-msg-map-00.txt ftp://anonymous@ftp-eng.cisco.com/draft-nadeau-ietf-oam-requirements-00.txt 1610-1620 "Tom K. Johnson" ****NEED DISCUSSION INFO**** ****NEED PUBLICLY ACCESSIBLE DOCUMENT INFO**** 1620-1630 Open Issues in TDM Requirements Draft "Max Riegel" Discussion: Discussion of open issues from the mailing list and clarification of further proceeding with the document in alignment with other WG I-Ds. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-00.txt 1630-1640 TDM Packet Loss Concealment "Yaakov Stein" ****NEED DISCUSSION INFO**** ****NEED PUBLICLY ACCESSIBLE DOCUMENT INFO**** 1640-1650 PW Setup & Maintenance Using LDP "Luca Martini" Discussion: Discuss changes regarding move of LDP setup and control protocol to separate document. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-00.txt 1650-1700 **Available 1700-1720 "W. Mark Townsley" ****NEED DISCUSSION INFO**** ****NEED PUBLICLY ACCESSIBLE DOCUMENT INFO**** 1720-1730 Wrap Up From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Yaakov Stein" Subject: TDMoIP-LE (Loop Emulation) draft Date: Tue, 25 Feb 2003 11:36:07 +0200 Lines: 70 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DCB1.52790942" Cc: "Ronen Shashoua" , "Tuvia Segal" , "Orly Nicklass" Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: TDMoIP-LE (Loop Emulation) draft Thread-Index: AcLcsSPsqOARQtagS/OGixKgjjSaUg== To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C2DCB1.52790942 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I missed the deadline for submission of initial drafts (but only by a few hours ...) so I have put the draft I had intended to submit on my own web site. The draft, entitled TDMoIP using Loop Emulation (TDMoIP-LE), discusses the AAL2 mode of draft-anavi-tdmoip. In particular it demonstrates the superiority of loop emulation for TDM trunking during short periods of congestion. The draft can be viewed at http://www.dspcsp.com/tdmoip/draft-stein-pwe3-tdmoiple-00.txt Y(J)S ------_=_NextPart_001_01C2DCB1.52790942 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable TDMoIP-LE (Loop Emulation) draft

I missed the deadline for submission of initial = drafts
(but only by a few hours ...)
so I have put the draft I had intended to submit
on my own web site.

The draft, entitled TDMoIP using Loop Emulation (TDMoIP-LE),
discusses the AAL2 mode of draft-anavi-tdmoip.
In particular it demonstrates the superiority of loop emulation
for TDM trunking during short periods of congestion.

The draft can be viewed at
   ht= tp://www.dspcsp.com/tdmoip/draft-stein-pwe3-tdmoiple-00.txt


Y(J)S

------_=_NextPart_001_01C2DCB1.52790942-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Renwei Li" Subject: TTL in ATM over MPLS Date: Wed, 26 Feb 2003 15:14:09 -0800 Lines: 11 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: TTL in ATM over MPLS Thread-Index: AcLd7MRLDPyDcaurTeeGT4YIFFvz8g== To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QNKTp20427 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O In the draft pwe3-atm-encap-01.txt, it says: The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a value of 2. IMHO, it is better to set to 255. The egress PE2 should discard the packets if its TTL is other than 255. TTL 255 will prevent from the use of VC label for transporting purpose. Renwei From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 06:57:20 -0000 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: To: renwei@procket.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Renwei Li wrote 26 February 2003 23:14 > To: pwe3@ietf.org > Subject: [PWE3] TTL in ATM over MPLS > > > In the draft pwe3-atm-encap-01.txt, it says: > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a > value of 2. > > IMHO, it is better to set to 255. The egress PE2 should discard the > packets if its TTL is other than 255. TTL 255 will prevent > from the use > of VC label for transporting purpose. NH=> Good point....but it has a downside: If there is a defect that causes misdelivery (ie swap/mismerge fault) then the traffic could be delivered to wrong location. Setting the TTL to 2 helps stop this possibility. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: John Fischer Subject: Re: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 09:06:29 -0500 Organization: Alcatel Canada Lines: 32 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389014D0016@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: renwei@procket.com, pwe3@ietf.org Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O In addition, the tunneling context (could be an outer MPLS label) may be popped at the penultimate node if PHP was requested by the PE. The inner label should only be exposed for 1 hop. Setting the TTL to 2 prevents the the packet from travelling any further than it should need to go. John neil.2.harrison@bt.com wrote: > Renwei Li wrote 26 February 2003 23:14 > > To: pwe3@ietf.org > > Subject: [PWE3] TTL in ATM over MPLS > > > > > > In the draft pwe3-atm-encap-01.txt, it says: > > > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a > > value of 2. > > > > IMHO, it is better to set to 255. The egress PE2 should discard the > > packets if its TTL is other than 255. TTL 255 will prevent > > from the use > > of VC label for transporting purpose. > NH=> Good point....but it has a downside: If there is a defect that causes > misdelivery (ie swap/mismerge fault) then the traffic could be delivered to > wrong location. Setting the TTL to 2 helps stop this possibility. > > regards, Neil > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "David Allan" Subject: RE: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 11:44:02 -0500 Lines: 119 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE7E.D96ED962" Return-path: To: "'neil.2.harrison@bt.com'" , renwei@procket.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2DE7E.D96ED962 Content-Type: text/plain Correct me if I'm wrong, but for PHP scenarios, 255 is not what will be seen at the egress PE. 2 is the smallest value (hence smallest blast footprint ;-) that would not decrement to zero prior to handling at the egress. No modifications to look for special values are required. Dave -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Thursday, February 27, 2003 1:57 AM To: renwei@procket.com; pwe3@ietf.org Subject: RE: [PWE3] TTL in ATM over MPLS Renwei Li wrote 26 February 2003 23:14 > To: pwe3@ietf.org > Subject: [PWE3] TTL in ATM over MPLS > > > In the draft pwe3-atm-encap-01.txt, it says: > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a > value of 2. > > IMHO, it is better to set to 255. The egress PE2 should discard the > packets if its TTL is other than 255. TTL 255 will prevent from the > use of VC label for transporting purpose. NH=> Good point....but it has a downside: If there is a defect that causes misdelivery (ie swap/mismerge fault) then the traffic could be delivered to wrong location. Setting the TTL to 2 helps stop this possibility. regards, Neil _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C2DE7E.D96ED962 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] TTL in ATM over MPLS

Correct me if I'm wrong, but for PHP scenarios, 255 = is not what will be seen at the egress PE.

2 is the smallest value (hence smallest blast = footprint ;-) that would not decrement to zero prior to handling at the = egress. No modifications to look for special values are = required.

Dave

-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com= ]
Sent: Thursday, February 27, 2003 1:57 AM
To: renwei@procket.com; pwe3@ietf.org
Subject: RE: [PWE3] TTL in ATM over MPLS


Renwei Li wrote 26 February 2003 23:14
> To: pwe3@ietf.org
> Subject: [PWE3] TTL in ATM over MPLS
>
>
> In the draft pwe3-atm-encap-01.txt, it = says:
>
>    The ingress LSR, PE1, SHOULD = set the TTL field of the VC label to a
> value of 2.
>
> IMHO, it is better to set to 255. The egress = PE2 should discard the
> packets if its TTL is other than 255. TTL 255 = will prevent from the
> use of VC label for transporting = purpose.
NH=3D> Good point....but it has a downside:  = If there is a defect that causes misdelivery (ie swap/mismerge fault) = then the traffic could be delivered to wrong location.  Setting = the TTL to 2 helps stop this possibility.

regards, Neil
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3=

------_=_NextPart_001_01C2DE7E.D96ED962-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Renwei Li" Subject: RE: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 10:15:33 -0800 Lines: 169 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE8C.37DDC9CA" Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] TTL in ATM over MPLS Thread-Index: AcLef3c0kBMoeQDnSKCiN3D5zrvBigADFT9A To: "David Allan" , , Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C2DE8C.37DDC9CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the PHP scenario, the tunnel label will be popped off, and the egress PE should see 255 for VC label. =20 The main advantage for VC label TTL 255 will prevent some mis-configurations. =20 Renwei =20 =20 -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com]=20 Sent: Thursday, February 27, 2003 8:44 AM To: 'neil.2.harrison@bt.com'; Renwei Li; pwe3@ietf.org Subject: RE: [PWE3] TTL in ATM over MPLS Correct me if I'm wrong, but for PHP scenarios, 255 is not what will be seen at the egress PE.=20 2 is the smallest value (hence smallest blast footprint ;-) that would not decrement to zero prior to handling at the egress. No modifications to look for special values are required. Dave=20 -----Original Message-----=20 From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Thursday, February 27, 2003 1:57 AM=20 To: renwei@procket.com; pwe3@ietf.org=20 Subject: RE: [PWE3] TTL in ATM over MPLS=20 Renwei Li wrote 26 February 2003 23:14=20 > To: pwe3@ietf.org=20 > Subject: [PWE3] TTL in ATM over MPLS=20 >=20 >=20 > In the draft pwe3-atm-encap-01.txt, it says:=20 >=20 > The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a=20 > value of 2.=20 >=20 > IMHO, it is better to set to 255. The egress PE2 should discard the=20 > packets if its TTL is other than 255. TTL 255 will prevent from the=20 > use of VC label for transporting purpose.=20 NH=3D> Good point....but it has a downside: If there is a defect that causes misdelivery (ie swap/mismerge fault) then the traffic could be delivered to wrong location. Setting the TTL to 2 helps stop this possibility. regards, Neil=20 _______________________________________________=20 pwe3 mailing list=20 pwe3@ietf.org=20 https://www1.ietf.org/mailman/listinfo/pwe3=20 ------_=_NextPart_001_01C2DE8C.37DDC9CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
For=20 the PHP scenario, the tunnel label will be popped off, and the egress PE = should=20 see 255 for VC label.
 
The=20 main advantage for VC label TTL 255 will prevent some=20 mis-configurations.
 
Renwei
 
 
-----Original = Message-----
From: David=20 Allan [mailto:dallan@nortelnetworks.com]
Sent: Thursday, = February 27,=20 2003 8:44 AM
To: 'neil.2.harrison@bt.com'; Renwei Li;=20 pwe3@ietf.org
Subject: RE: [PWE3] TTL in ATM over=20 MPLS

Correct me if I'm wrong, but for PHP scenarios, 255 = is not=20 what will be seen at the egress PE.

2 is the smallest value (hence smallest blast = footprint ;-)=20 that would not decrement to zero prior to handling at the egress. No=20 modifications to look for special values are required.

Dave

-----Original Message-----
From:=20 neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]= =20
Sent: Thursday, February 27, 2003 1:57 = AM=20
To: renwei@procket.com; pwe3@ietf.org =
Subject: RE: [PWE3] TTL in ATM over MPLS


Renwei Li wrote 26 February 2003 23:14 =
> To: pwe3@ietf.org
> = Subject: [PWE3] TTL=20 in ATM over MPLS
>
>=20
> In the draft pwe3-atm-encap-01.txt, it=20 says:
>
>    The ingress LSR, PE1, SHOULD set the = TTL field=20 of the VC label to a
> value of 2. =
>
> IMHO, it is better to set = to 255. The=20 egress PE2 should discard the
> packets = if its TTL=20 is other than 255. TTL 255 will prevent from the
>=20 use of VC label for transporting purpose.
NH=3D> Good=20 point....but it has a downside:  If there is a defect that causes = misdelivery (ie swap/mismerge fault) then the traffic could be = delivered to=20 wrong location.  Setting the TTL to 2 helps stop this=20 possibility.

regards, Neil
_______________________________________________ =
pwe3 mailing list
pwe3@ietf.org=20
https://www1.ietf.org/mailman/listinfo/pwe3 =

=00 ------_=_NextPart_001_01C2DE8C.37DDC9CA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "David Allan" Subject: RE: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 13:38:04 -0500 Lines: 191 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE8F.5D65359E" Return-path: To: "'Renwei Li'" , neil.2.harrison@bt.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2DE8F.5D65359E Content-Type: text/plain Hi Renwei: Depending on your implementation you'd see 255, 254 or depending on the upstream implementation (as Shahram noted), you'll see the PSN TTL. I would presume the value two in the specification provides coverage for pipe mode, and how and when in the LSR forwarding sequence TTL handling is implemented. TTL will explicit exhaust if forwarded beyond the PE, but will not be deemed to have exhausted at precisely the moment it made it to the PE. All bets are off for uniform as you lost that limiting property, but in a well behaved system the payload would still be value. Cannot make that claim for explicitly expecting 255. Dave -----Original Message----- From: Renwei Li [mailto:renwei@procket.com] Sent: Thursday, February 27, 2003 1:16 PM To: Allan, David [CAR:NS00:EXCH]; neil.2.harrison@bt.com; pwe3@ietf.org Subject: RE: [PWE3] TTL in ATM over MPLS For the PHP scenario, the tunnel label will be popped off, and the egress PE should see 255 for VC label. The main advantage for VC label TTL 255 will prevent some mis-configurations. Renwei -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Thursday, February 27, 2003 8:44 AM To: 'neil.2.harrison@bt.com'; Renwei Li; pwe3@ietf.org Subject: RE: [PWE3] TTL in ATM over MPLS Correct me if I'm wrong, but for PHP scenarios, 255 is not what will be seen at the egress PE. 2 is the smallest value (hence smallest blast footprint ;-) that would not decrement to zero prior to handling at the egress. No modifications to look for special values are required. Dave -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com ] Sent: Thursday, February 27, 2003 1:57 AM To: renwei@procket.com; pwe3@ietf.org Subject: RE: [PWE3] TTL in ATM over MPLS Renwei Li wrote 26 February 2003 23:14 > To: pwe3@ietf.org > Subject: [PWE3] TTL in ATM over MPLS > > > In the draft pwe3-atm-encap-01.txt, it says: > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a > value of 2. > > IMHO, it is better to set to 255. The egress PE2 should discard the > packets if its TTL is other than 255. TTL 255 will prevent from the > use of VC label for transporting purpose. NH=> Good point....but it has a downside: If there is a defect that causes misdelivery (ie swap/mismerge fault) then the traffic could be delivered to wrong location. Setting the TTL to 2 helps stop this possibility. regards, Neil _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C2DE8F.5D65359E Content-Type: text/html Message
Hi Renwei:
 
Depending on your implementation you'd see 255, 254 or depending on the upstream implementation (as Shahram noted), you'll see the PSN TTL.
 
I would presume the value two in the specification provides coverage for pipe mode, and how and when in the LSR forwarding sequence TTL handling is implemented. TTL will explicit exhaust if forwarded beyond the PE, but will not be deemed to have exhausted at precisely the moment it made it to the PE. All bets are off for uniform as you lost that limiting property, but in a well behaved system the payload would still be value. Cannot make that claim for explicitly expecting 255.
 
Dave
 
 
-----Original Message-----
From: Renwei Li [mailto:renwei@procket.com]
Sent: Thursday, February 27, 2003 1:16 PM
To: Allan, David [CAR:NS00:EXCH]; neil.2.harrison@bt.com; pwe3@ietf.org
Subject: RE: [PWE3] TTL in ATM over MPLS

For the PHP scenario, the tunnel label will be popped off, and the egress PE should see 255 for VC label.
 
The main advantage for VC label TTL 255 will prevent some mis-configurations.
 
Renwei
 
 
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Thursday, February 27, 2003 8:44 AM
To: 'neil.2.harrison@bt.com'; Renwei Li; pwe3@ietf.org
Subject: RE: [PWE3] TTL in ATM over MPLS

Correct me if I'm wrong, but for PHP scenarios, 255 is not what will be seen at the egress PE.

2 is the smallest value (hence smallest blast footprint ;-) that would not decrement to zero prior to handling at the egress. No modifications to look for special values are required.

Dave

-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Thursday, February 27, 2003 1:57 AM
To: renwei@procket.com; pwe3@ietf.org
Subject: RE: [PWE3] TTL in ATM over MPLS


Renwei Li wrote 26 February 2003 23:14
> To: pwe3@ietf.org
> Subject: [PWE3] TTL in ATM over MPLS
>
>
> In the draft pwe3-atm-encap-01.txt, it says:
>
>    The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a
> value of 2.
>
> IMHO, it is better to set to 255. The egress PE2 should discard the
> packets if its TTL is other than 255. TTL 255 will prevent from the
> use of VC label for transporting purpose.
NH=> Good point....but it has a downside:  If there is a defect that causes misdelivery (ie swap/mismerge fault) then the traffic could be delivered to wrong location.  Setting the TTL to 2 helps stop this possibility.

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

------_=_NextPart_001_01C2DE8F.5D65359E-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Renwei Li" Subject: RE: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 10:39:32 -0800 Lines: 57 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Cc: Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] TTL in ATM over MPLS Thread-Index: AcLeaXHLpX5lioX+SR+EPfpLwA206AAJX+5w To: "John Fischer" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RIkEp11601 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O You are assuming the network is well-configured. But I am considering what will happen if the network is not well-configured. The bottom line is: when an LSR receives a packet with TTL 255, it is sure that the packet was sent one hop away from. But if it receives a packet with TTL 2, it is not sure how far the packet was sent away from. Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from that. In view of the above, I believe you can easily give a mis-configured network so that the egress PE receives a packet with TTL 2, but the packet is not really a valid one sent from the ingress PE. Renwei -----Original Message----- From: John Fischer [mailto:john.fischer@alcatel.com] Sent: Thursday, February 27, 2003 6:06 AM To: neil.2.harrison@bt.com Cc: Renwei Li; pwe3@ietf.org Subject: Re: [PWE3] TTL in ATM over MPLS In addition, the tunneling context (could be an outer MPLS label) may be popped at the penultimate node if PHP was requested by the PE. The inner label should only be exposed for 1 hop. Setting the TTL to 2 prevents the the packet from travelling any further than it should need to go. John neil.2.harrison@bt.com wrote: > Renwei Li wrote 26 February 2003 23:14 > > To: pwe3@ietf.org > > Subject: [PWE3] TTL in ATM over MPLS > > > > > > In the draft pwe3-atm-encap-01.txt, it says: > > > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a > > value of 2. > > > > IMHO, it is better to set to 255. The egress PE2 should discard the > > packets if its TTL is other than 255. TTL 255 will prevent > > from the use > > of VC label for transporting purpose. > NH=> Good point....but it has a downside: If there is a defect that causes > misdelivery (ie swap/mismerge fault) then the traffic could be delivered to > wrong location. Setting the TTL to 2 helps stop this possibility. > > regards, Neil > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: John Fischer Subject: Re: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 15:15:24 -0500 Organization: Alcatel Canada Lines: 71 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: neil.2.harrison@bt.com, pwe3@ietf.org, dallan@nortelnetworks.com Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Renwei Li Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yes you're correct, but I think that it would be quite difficult to get this packet with a correct label and TTL=2 delivered to the PE in the first place if that label was exposed for several hops. The inner MPLS label is only known by the PE in L2 VPN, L3 VPN and VPLS. I agree that setting TTL to 255 and checking for 254/255 at the PE is more secure. As David Allan indicates though, this depends on the pipe or uniform behaviour of the penultimate LSR and requires extra checks at the PE. By using TTL 2, basic TTL handling can be used at the PE. John Renwei Li wrote: > You are assuming the network is well-configured. But I am considering > what will happen if the network is not well-configured. > > The bottom line is: when an LSR receives a packet with TTL 255, it is > sure that the packet was sent one hop away from. But if it receives a > packet with TTL 2, it is not sure how far the packet was sent away from. > Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from that. > > In view of the above, I believe you can easily give a mis-configured > network so that the egress PE receives a packet with TTL 2, but the > packet is not really a valid one sent from the ingress PE. > > Renwei > > -----Original Message----- > From: John Fischer [mailto:john.fischer@alcatel.com] > Sent: Thursday, February 27, 2003 6:06 AM > To: neil.2.harrison@bt.com > Cc: Renwei Li; pwe3@ietf.org > Subject: Re: [PWE3] TTL in ATM over MPLS > > In addition, the tunneling context (could be an outer MPLS label) > may be popped at the penultimate node if PHP was requested by > the PE. The inner label should only be exposed for 1 hop. Setting > the TTL to 2 prevents the the packet from travelling any further than > it should need to go. > John > > neil.2.harrison@bt.com wrote: > > > Renwei Li wrote 26 February 2003 23:14 > > > To: pwe3@ietf.org > > > Subject: [PWE3] TTL in ATM over MPLS > > > > > > > > > In the draft pwe3-atm-encap-01.txt, it says: > > > > > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label to > a > > > value of 2. > > > > > > IMHO, it is better to set to 255. The egress PE2 should discard the > > > packets if its TTL is other than 255. TTL 255 will prevent > > > from the use > > > of VC label for transporting purpose. > > NH=> Good point....but it has a downside: If there is a defect that > causes > > misdelivery (ie swap/mismerge fault) then the traffic could be > delivered to > > wrong location. Setting the TTL to 2 helps stop this possibility. > > > > regards, Neil > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "David Allan" Subject: RE: TTL in ATM over MPLS Date: Thu, 27 Feb 2003 16:36:41 -0500 Lines: 244 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DEA8.512E9216" Cc: neil.2.harrison@bt.com, pwe3@ietf.org Return-path: To: "'John Fischer'" , Renwei Li X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2DEA8.512E9216 Content-Type: text/plain A more realistic scenario is that the PW payload is leaked into the network core, in which case if TTL=2, the misdirected traffic will "self destruct" fairly quickly.... If you really want checking that stuff is not being misdirected at the PE, TTL is hardly authoritative as all PWs will have the same value. I'd point you to the FEC-CV proposed for 1711 as authoritative tests of connectivity of a label. Dave BTW apologies if not plain text, still wrestling with new email s/w -----Original Message----- From: John Fischer [mailto:john.fischer@alcatel.com] Sent: Thursday, February 27, 2003 3:15 PM To: Renwei Li Cc: neil.2.harrison@bt.com; pwe3@ietf.org; Allan, David [CAR:NS00:EXCH] Subject: Re: [PWE3] TTL in ATM over MPLS Yes you're correct, but I think that it would be quite difficult to get this packet with a correct label and TTL=2 delivered to the PE in the first place if that label was exposed for several hops. The inner MPLS label is only known by the PE in L2 VPN, L3 VPN and VPLS. I agree that setting TTL to 255 and checking for 254/255 at the PE is more secure. As David Allan indicates though, this depends on the pipe or uniform behaviour of the penultimate LSR and requires extra checks at the PE. By using TTL 2, basic TTL handling can be used at the PE. John Renwei Li wrote: > You are assuming the network is well-configured. But I am considering > what will happen if the network is not well-configured. > > The bottom line is: when an LSR receives a packet with TTL 255, it is > sure that the packet was sent one hop away from. But if it receives a > packet with TTL 2, it is not sure how far the packet was sent away > from. Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from > that. > > In view of the above, I believe you can easily give a mis-configured > network so that the egress PE receives a packet with TTL 2, but the > packet is not really a valid one sent from the ingress PE. > > Renwei > > -----Original Message----- > From: John Fischer [mailto:john.fischer@alcatel.com] > Sent: Thursday, February 27, 2003 6:06 AM > To: neil.2.harrison@bt.com > Cc: Renwei Li; pwe3@ietf.org > Subject: Re: [PWE3] TTL in ATM over MPLS > > In addition, the tunneling context (could be an outer MPLS label) may > be popped at the penultimate node if PHP was requested by the PE. The > inner label should only be exposed for 1 hop. Setting the TTL to 2 > prevents the the packet from travelling any further than it should > need to go. John > > neil.2.harrison@bt.com wrote: > > > Renwei Li wrote 26 February 2003 23:14 > > > To: pwe3@ietf.org > > > Subject: [PWE3] TTL in ATM over MPLS > > > > > > > > > In the draft pwe3-atm-encap-01.txt, it says: > > > > > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label > > > to > a > > > value of 2. > > > > > > IMHO, it is better to set to 255. The egress PE2 should discard > > > the packets if its TTL is other than 255. TTL 255 will prevent > > > from the use of VC label for transporting purpose. > > NH=> Good point....but it has a downside: If there is a defect that > causes > > misdelivery (ie swap/mismerge fault) then the traffic could be > delivered to > > wrong location. Setting the TTL to 2 helps stop this possibility. > > > > regards, Neil _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C2DEA8.512E9216 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] TTL in ATM over MPLS

A more realistic scenario is that the PW payload is = leaked into the network core, in which case if TTL=3D2, the misdirected = traffic will "self destruct" fairly quickly....

If you really want checking that stuff is not being = misdirected at the PE, TTL is hardly authoritative as all PWs will have = the same value. I'd point you to the FEC-CV proposed for 1711 as = authoritative tests of connectivity of a label.

Dave

BTW apologies if not plain text, still wrestling with = new email s/w

-----Original Message-----
From: John Fischer [mailto:john.fischer@alcatel.com= ]
Sent: Thursday, February 27, 2003 3:15 PM
To: Renwei Li
Cc: neil.2.harrison@bt.com; pwe3@ietf.org; Allan, = David [CAR:NS00:EXCH]
Subject: Re: [PWE3] TTL in ATM over MPLS


Yes you're correct, but I think that it would be = quite difficult to get this packet with a correct label and TTL=3D2 = delivered to the PE in the first place if that label was exposed for = several hops.  The inner MPLS label is only known by the PE in L2 = VPN, L3 VPN and VPLS.

I agree that setting TTL to 255 and checking for = 254/255 at the PE is more secure.  As David Allan indicates = though, this depends on the pipe or uniform behaviour of the = penultimate LSR and requires extra checks at the PE.  By using TTL = 2, basic TTL handling can be used at the PE. John

Renwei Li wrote:

> You are assuming the network is well-configured. = But I am considering
> what will happen if the network is not = well-configured.
>
> The bottom line is: when an LSR receives a = packet with TTL 255, it is
> sure that the packet was sent one hop away = from. But if it receives a
> packet with TTL 2, it is not sure how far the = packet was sent away
> from. Maybe 1 hop, 2 hops, 3 hops, .... We = really can't judge from
> that.
>
> In view of the above, I believe you can easily = give a mis-configured
> network so that the egress PE receives a packet = with TTL 2, but the
> packet is not really a valid one sent from the = ingress PE.
>
> Renwei
>
> -----Original Message-----
> From: John Fischer [mailto:john.fischer@alcatel.com= ]
> Sent: Thursday, February 27, 2003 6:06 = AM
> To: neil.2.harrison@bt.com
> Cc: Renwei Li; pwe3@ietf.org
> Subject: Re: [PWE3] TTL in ATM over MPLS
>
> In addition, the tunneling context (could be an = outer MPLS label) may
> be popped at the penultimate node if PHP was = requested by the PE.  The
> inner label should only be exposed for 1 hop.&nb= sp; Setting the TTL to 2
> prevents the the packet from travelling any = further than it should
> need to go. John
>
> neil.2.harrison@bt.com wrote:
>
> > Renwei Li wrote 26 February 2003 = 23:14
> > > To: pwe3@ietf.org
> > > Subject: [PWE3] TTL in ATM over = MPLS
> > >
> > >
> > > In the draft pwe3-atm-encap-01.txt, = it says:
> > >
> > >    The ingress LSR, = PE1, SHOULD set the TTL field of the VC label
> > > to
> a
> > > value of 2.
> > >
> > > IMHO, it is better to set to 255. The = egress PE2 should discard
> > > the packets if its TTL is other than = 255. TTL 255 will prevent
> > > from the use of VC label for = transporting purpose.
> > NH=3D> Good point....but it has a = downside:  If there is a defect that
> causes
> > misdelivery (ie swap/mismerge fault) then = the traffic could be
> delivered to
> > wrong location.  Setting the TTL to 2 = helps stop this possibility.
> >
> > regards, Neil = _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3=

------_=_NextPart_001_01C2DEA8.512E9216-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: neil.2.harrison@bt.com Subject: RE: TTL in ATM over MPLS Date: Fri, 28 Feb 2003 09:09:33 -0000 Lines: 249 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DF09.1BC26FBC" Cc: pwe3@ietf.org Return-path: To: dallan@nortelnetworks.com, john.fischer@alcatel.com, renwei@procket.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2DF09.1BC26FBC Content-Type: text/plain; charset="iso-8859-1" Just a small point here..... Dave mentions the FEC-CV below which is being proposed/considered to augment the simpler 'plain CV'......the plain CV is already an agreed format in Y.1711. The plain CV pkt contain the source identification of an LSP and I would suggest this is used when p2p LSPs are considered. ATM/MPLS relationships are something we see as of increasing importance to get right.......and I am not just referring to the client(ATM)/server(MPLS) case but also the service-interworking case........where the plain CV is all one needs IMO. I agree with Dave wrt to the setting of the TTL, but my preference would be to set this at 1 and don't do PHP. regards, Neil -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: 27 February 2003 21:37 To: 'John Fischer'; Renwei Li Cc: Harrison,N,Neil,IKL2 R; pwe3@ietf.org Subject: RE: [PWE3] TTL in ATM over MPLS A more realistic scenario is that the PW payload is leaked into the network core, in which case if TTL=2, the misdirected traffic will "self destruct" fairly quickly.... If you really want checking that stuff is not being misdirected at the PE, TTL is hardly authoritative as all PWs will have the same value. I'd point you to the FEC-CV proposed for 1711 as authoritative tests of connectivity of a label. Dave BTW apologies if not plain text, still wrestling with new email s/w -----Original Message----- From: John Fischer [ mailto:john.fischer@alcatel.com ] Sent: Thursday, February 27, 2003 3:15 PM To: Renwei Li Cc: neil.2.harrison@bt.com; pwe3@ietf.org; Allan, David [CAR:NS00:EXCH] Subject: Re: [PWE3] TTL in ATM over MPLS Yes you're correct, but I think that it would be quite difficult to get this packet with a correct label and TTL=2 delivered to the PE in the first place if that label was exposed for several hops. The inner MPLS label is only known by the PE in L2 VPN, L3 VPN and VPLS. I agree that setting TTL to 255 and checking for 254/255 at the PE is more secure. As David Allan indicates though, this depends on the pipe or uniform behaviour of the penultimate LSR and requires extra checks at the PE. By using TTL 2, basic TTL handling can be used at the PE. John Renwei Li wrote: > You are assuming the network is well-configured. But I am considering > what will happen if the network is not well-configured. > > The bottom line is: when an LSR receives a packet with TTL 255, it is > sure that the packet was sent one hop away from. But if it receives a > packet with TTL 2, it is not sure how far the packet was sent away > from. Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from > that. > > In view of the above, I believe you can easily give a mis-configured > network so that the egress PE receives a packet with TTL 2, but the > packet is not really a valid one sent from the ingress PE. > > Renwei > > -----Original Message----- > From: John Fischer [ mailto:john.fischer@alcatel.com ] > Sent: Thursday, February 27, 2003 6:06 AM > To: neil.2.harrison@bt.com > Cc: Renwei Li; pwe3@ietf.org > Subject: Re: [PWE3] TTL in ATM over MPLS > > In addition, the tunneling context (could be an outer MPLS label) may > be popped at the penultimate node if PHP was requested by the PE. The > inner label should only be exposed for 1 hop. Setting the TTL to 2 > prevents the the packet from travelling any further than it should > need to go. John > > neil.2.harrison@bt.com wrote: > > > Renwei Li wrote 26 February 2003 23:14 > > > To: pwe3@ietf.org > > > Subject: [PWE3] TTL in ATM over MPLS > > > > > > > > > In the draft pwe3-atm-encap-01.txt, it says: > > > > > > The ingress LSR, PE1, SHOULD set the TTL field of the VC label > > > to > a > > > value of 2. > > > > > > IMHO, it is better to set to 255. The egress PE2 should discard > > > the packets if its TTL is other than 255. TTL 255 will prevent > > > from the use of VC label for transporting purpose. > > NH=> Good point....but it has a downside: If there is a defect that > causes > > misdelivery (ie swap/mismerge fault) then the traffic could be > delivered to > > wrong location. Setting the TTL to 2 helps stop this possibility. > > > > regards, Neil _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C2DF09.1BC26FBC Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] TTL in ATM over MPLS
Just a small point here.....
 
Dave mentions the FEC-CV below which is being proposed/considered to augment the simpler 'plain CV'......the plain CV is already an agreed format in Y.1711.  The plain CV pkt contain the source identification of an LSP and I would suggest this is used when p2p LSPs are considered.  ATM/MPLS relationships are something we see as of increasing importance to get right.......and I am not just referring to the client(ATM)/server(MPLS) case but also the service-interworking case........where the plain CV is all one needs IMO.
 
I agree with Dave wrt to the setting of the TTL, but my preference would be to set this at 1 and don't do PHP.
 
regards, Neil
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: 27 February 2003 21:37
To: 'John Fischer'; Renwei Li
Cc: Harrison,N,Neil,IKL2 R; pwe3@ietf.org
Subject: RE: [PWE3] TTL in ATM over MPLS

A more realistic scenario is that the PW payload is leaked into the network core, in which case if TTL=2, the misdirected traffic will "self destruct" fairly quickly....

If you really want checking that stuff is not being misdirected at the PE, TTL is hardly authoritative as all PWs will have the same value. I'd point you to the FEC-CV proposed for 1711 as authoritative tests of connectivity of a label.

Dave

BTW apologies if not plain text, still wrestling with new email s/w

-----Original Message-----
From: John Fischer [mailto:john.fischer@alcatel.com]
Sent: Thursday, February 27, 2003 3:15 PM
To: Renwei Li
Cc: neil.2.harrison@bt.com; pwe3@ietf.org; Allan, David [CAR:NS00:EXCH]
Subject: Re: [PWE3] TTL in ATM over MPLS


Yes you're correct, but I think that it would be quite difficult to get this packet with a correct label and TTL=2 delivered to the PE in the first place if that label was exposed for several hops.  The inner MPLS label is only known by the PE in L2 VPN, L3 VPN and VPLS.

I agree that setting TTL to 255 and checking for 254/255 at the PE is more secure.  As David Allan indicates though, this depends on the pipe or uniform behaviour of the penultimate LSR and requires extra checks at the PE.  By using TTL 2, basic TTL handling can be used at the PE. John

Renwei Li wrote:

> You are assuming the network is well-configured. But I am considering
> what will happen if the network is not well-configured.
>
> The bottom line is: when an LSR receives a packet with TTL 255, it is
> sure that the packet was sent one hop away from. But if it receives a
> packet with TTL 2, it is not sure how far the packet was sent away
> from. Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from
> that.
>
> In view of the above, I believe you can easily give a mis-configured
> network so that the egress PE receives a packet with TTL 2, but the
> packet is not really a valid one sent from the ingress PE.
>
> Renwei
>
> -----Original Message-----
> From: John Fischer [mailto:john.fischer@alcatel.com]
> Sent: Thursday, February 27, 2003 6:06 AM
> To: neil.2.harrison@bt.com
> Cc: Renwei Li; pwe3@ietf.org
> Subject: Re: [PWE3] TTL in ATM over MPLS
>
> In addition, the tunneling context (could be an outer MPLS label) may
> be popped at the penultimate node if PHP was requested by the PE.  The
> inner label should only be exposed for 1 hop.  Setting the TTL to 2
> prevents the the packet from travelling any further than it should
> need to go. John
>
> neil.2.harrison@bt.com wrote:
>
> > Renwei Li wrote 26 February 2003 23:14
> > > To: pwe3@ietf.org
> > > Subject: [PWE3] TTL in ATM over MPLS
> > >
> > >
> > > In the draft pwe3-atm-encap-01.txt, it says:
> > >
> > >    The ingress LSR, PE1, SHOULD set the TTL field of the VC label
> > > to
> a
> > > value of 2.
> > >
> > > IMHO, it is better to set to 255. The egress PE2 should discard
> > > the packets if its TTL is other than 255. TTL 255 will prevent
> > > from the use of VC label for transporting purpose.
> > NH=> Good point....but it has a downside:  If there is a defect that
> causes
> > misdelivery (ie swap/mismerge fault) then the traffic could be
> delivered to
> > wrong location.  Setting the TTL to 2 helps stop this possibility.
> >
> > regards, Neil _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3

------_=_NextPart_001_01C2DF09.1BC26FBC-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Fri, 28 Feb 2003 07:25:42 -0500 Lines: 85 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TDM Circuit Emulation over Packet (CEP-TDM) Author(s) : T. Johnson Filename : draft-johnson-pwe3-tdm-00.txt Pages : 17 Date : 2003-2-27 This draft proposes a TDM emulation protocol for consideration by the PWE3 Working Group. The protocol defines methods for transporting DS3, E3, DS1, E1, and NxDS0 circuits over packet switched networks. It is based on ATM Circuit Emulation, but optimized for variable length packet networks. The intent is to provide a relatively simple but flexible method for transporting TDM signals over packet switched networks that also provides a path for interworking with ATM Circuit Emulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johnson-pwe3-tdm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-johnson-pwe3-tdm-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-johnson-pwe3-tdm-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Eric Rosen Subject: Re: TTL in ATM over MPLS Date: Fri, 28 Feb 2003 10:25:48 -0500 Lines: 19 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org Return-path: To: "Renwei Li" In-reply-to: Your message of Thu, 27 Feb 2003 10:39:32 -0800. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O One thing to remember is that the TTL is part of the PSN layer, not part of the PWE3 layer. Adding a rule like "throw away a packet if its label indicates that it is a PWE3 packet but its TTL is not 255", would be making a change to the basic MPLS forwarding logic. And as Dave Allan has pointed out several times, the MPLS forwarding logic is not even guaranteed to preserve edge-to-edge the TTL of the bottom label stack entry. Frankly, I don't like the rule of setting the TTL of the PW label to 2. This rule embeds two assumptions: - The PW label is always at the bottom of the label stack. - There will never been any "tunnel switching", in which a single PW travels part way through one LSP tunnel, exits the tunnel, and then gets switched into another LSP tunnel. I'm not sure that either of these assumptions can be inferred from the architecture. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: PWE3 Draft Agenda - IETF 56 Date: Fri, 28 Feb 2003 08:54:28 -0700 Lines: 88 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Any last comments before I post? -danny ================================================================== Pseudo Wire Emulation Edge to Edge (pwe3) Wednesday, March 19 1530-1730 ============================= CHAIR: "Danny McPherson" AGENDA: 1530-1540 Administrivia "Danny McPherson" Agenda Bashing Minutes Blue Sheets WG Document Status 1540-1600 PWE3 Architecture & Congestion Control "Stewart Bryant" http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-02.txt> Discussion: 1) Update on current architecture document 2) Discussion of PWE3 Congestion Control 1600-1610 PWE3 OAM: Virtual Circuit Connection Verification "Thomas Nadeau" Discussion: PWE3 OAM Message Mapping and MPLS OAM. Discussion of the VCCV and OAM message mapping drafts, how they fit into and satisfy the MPLS OAM requirements, and next steps. ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-vccv-00.txt ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-oam-msgmap-00.txt ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-mpls-oam-requirements-00.txt 1610-1615 ATM PW MIB "Thomas D. Nadeau" Discussion: Discussion of PW ATM MIB and how it fits into accepted PW MIB management model for PWE3. http://www.ietf.org/internet-drafts/draft-sathappan-pw-atm-mib-00.txt 1615-1625 TDM Proposals "Tom K. Johnson" Discussion: Discuss alternate proposal for DS3, E3, DS1, E1, and NxDS0 circuit emulation. http://www.ietf.org/internet-drafts/draft-johnson-pwe3-tdm-00.txt 1625-1635 Open Issues in TDM Requirements Draft "Max Riegel" Discussion: Discussion of open issues from the mailing list and clarification of further proceeding with the document in alignment with other WG I-Ds. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-00.txt 1635-1645 TDM over IP Using Loop Emulation "Yaakov Stein" Discussion: TDM o IP using Loop Emulation, with emphasis on bandwidth conservation and the possibilities it opens for congestion avoidance. http://www.dspcsp.com/tdmoip/draft-stein-pwe3-tdmoiple-00.txt 1645-1655 PW Setup & Maintenance Using LDP "Luca Martini" Discussion: Discuss changes regarding move of LDP setup and control protocol to separate document. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-00.txt 1655-1700 Aligning PDU transport mode with ATM Forum "Shahram Davari" Discussion: ATM Forum detected problems with PDU mode and as a result has revised it. I will try to explain what those problems are and why PWE3 should revise the PDU mode and align it with ATM Forum http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-over-psn-00.txt 1700-1710 Available 1710-1720 L2TPv3: "Just an Update" "W. Mark Townsley" Discussion: Give an update on the state of L2TPv3 http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-06.txt 1720-1730 Wrap Up From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "David Allan" Subject: RE: PWE3 Draft Agenda - IETF 56 Date: Fri, 28 Feb 2003 11:13:48 -0500 Lines: 382 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DF44.603C3E6A" Return-path: To: "'danny@tcb.net'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2DF44.603C3E6A Content-Type: text/plain; charset="iso-8859-1" I am unable to obtain the drafts from the Cisco anonymous server. Will they be available via normal channels for review? Thx Dave -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Friday, February 28, 2003 10:54 AM To: pwe3@ietf.org Subject: [PWE3] PWE3 Draft Agenda - IETF 56 Any last comments before I post? -danny ================================================================== Pseudo Wire Emulation Edge to Edge (pwe3) Wednesday, March 19 1530-1730 ============================= CHAIR: "Danny McPherson" AGENDA: 1530-1540 Administrivia "Danny McPherson" Agenda Bashing Minutes Blue Sheets WG Document Status 1540-1600 PWE3 Architecture & Congestion Control "Stewart Bryant" http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-02.txt> Discussion: 1) Update on current architecture document 2) Discussion of PWE3 Congestion Control 1600-1610 PWE3 OAM: Virtual Circuit Connection Verification "Thomas Nadeau" Discussion: PWE3 OAM Message Mapping and MPLS OAM. Discussion of the VCCV and OAM message mapping drafts, how they fit into and satisfy the MPLS OAM requirements, and next steps. ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-vccv-00.txt ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-oam-msgmap-0 0.txt ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-mpls-oam-requirem ents-00.txt 1610-1615 ATM PW MIB "Thomas D. Nadeau" Discussion: Discussion of PW ATM MIB and how it fits into accepted PW MIB management model for PWE3. http://www.ietf.org/internet-drafts/draft-sathappan-pw-atm-mib-00.txt 1615-1625 TDM Proposals "Tom K. Johnson" Discussion: Discuss alternate proposal for DS3, E3, DS1, E1, and NxDS0 circuit emulation. http://www.ietf.org/internet-drafts/draft-johnson-pwe3-tdm-00.txt 1625-1635 Open Issues in TDM Requirements Draft "Max Riegel" Discussion: Discussion of open issues from the mailing list and clarification of further proceeding with the document in alignment with other WG I-Ds. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-00.txt 1635-1645 TDM over IP Using Loop Emulation "Yaakov Stein" Discussion: TDM o IP using Loop Emulation, with emphasis on bandwidth conservation and the possibilities it opens for congestion avoidance. http://www.dspcsp.com/tdmoip/draft-stein-pwe3-tdmoiple-00.txt 1645-1655 PW Setup & Maintenance Using LDP "Luca Martini" Discussion: Discuss changes regarding move of LDP setup and control protocol to separate document. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-00.txt 1655-1700 Aligning PDU transport mode with ATM Forum "Shahram Davari" Discussion: ATM Forum detected problems with PDU mode and as a result has revised it. I will try to explain what those problems are and why PWE3 should revise the PDU mode and align it with ATM Forum http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-over-psn-00.txt 1700-1710 Available 1710-1720 L2TPv3: "Just an Update" "W. Mark Townsley" Discussion: Give an update on the state of L2TPv3 http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-06.txt 1720-1730 Wrap Up _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C2DF44.603C3E6A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE3 Draft Agenda - IETF 56

I am unable to obtain the drafts from the Cisco = anonymous server. Will they be available via normal channels for = review?

Thx
Dave

-----Original Message-----
From: Danny McPherson [mailto:danny@tcb.net]
Sent: Friday, February 28, 2003 10:54 AM
To: pwe3@ietf.org
Subject: [PWE3] PWE3 Draft Agenda - IETF 56



Any last comments before I post?

-danny


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pseudo Wire Emulation Edge to Edge (pwe3)

Wednesday, March 19 1530-1730
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

CHAIR: "Danny McPherson" = <danny@tcb.net>

AGENDA:

1530-1540 Administrivia
   "Danny McPherson" = <danny@tcb.net>

          &nb= sp; Agenda Bashing
          &nb= sp; Minutes
          &nb= sp; Blue Sheets
          &nb= sp; WG Document Status

1540-1600 PWE3 Architecture & Congestion = Control
  "Stewart Bryant" = <stbryant@cisco.com>  http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ar= ch-02.txt>
 Discussion: 1) Update on current architecture = document
          &nb= sp;  2) Discussion of PWE3 Congestion Control

1600-1610 PWE3 OAM: Virtual Circuit Connection = Verification
  "Thomas Nadeau" = <tnadeau@cisco.com>
  Discussion: PWE3 OAM Message Mapping and MPLS = OAM.  Discussion
          &nb= sp;   of the VCCV and OAM message mapping drafts, how = they
          &nb= sp;   fit into and satisfy the MPLS OAM requirements, = and
          &nb= sp;   next steps.  ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-na= deau-pwe3-vccv-00.txt
 ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-na= deau-pwe3-oam-msgmap-00.txt
 ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-na= deau-mpls-oam-requirements-00.txt

1610-1615 ATM PW MIB
  "Thomas D. Nadeau" = <tnadeau@cisco.com>
  Discussion: Discussion of PW ATM MIB and how = it fits into
          &nb= sp;   accepted PW MIB management model for PWE3.  =
 http://www.ietf.org/internet-drafts/draft-sathappan-pw= -atm-mib-00.txt

1615-1625 TDM Proposals
  "Tom K. Johnson" = <tom_johnson@litchfieldcomm.com>
  Discussion: Discuss alternate proposal for = DS3, E3, DS1, E1,
          &nb= sp;   and NxDS0 circuit emulation.  http://www.ietf.org/internet-drafts/draft-johnson-pwe3= -tdm-00.txt

1625-1635 Open Issues in TDM Requirements = Draft
  "Max Riegel" = <maximilian.riegel@siemens.com>
  Discussion: Discussion of open issues from = the mailing list
          &nb= sp;   and clarification of further proceeding with the
          &nb= sp;   document in alignment with other WG I-Ds.  http://www.ietf.org/internet-drafts/draft-ietf-pwe3-td= m-requirements-00.txt

1635-1645 TDM over IP Using Loop Emulation
  "Yaakov Stein" = <yaakov_s@rad.com>
  Discussion: TDM o IP using Loop Emulation, = with emphasis on
          &nb= sp;   bandwidth conservation and the possibilities it
          &nb= sp;   opens for congestion avoidance.  http://www.dspcsp.com/tdmoip/draft-stein-pwe3-tdmoiple= -00.txt

1645-1655 PW Setup & Maintenance Using LDP
  "Luca Martini" = <luca@level3.net>
  Discussion: Discuss changes regarding move of = LDP setup
          &nb= sp;   and control protocol to separate document.  http://www.ietf.org/internet-drafts/draft-ietf-pwe3-co= ntrol-protocol-00.txt

1655-1700 Aligning PDU transport mode with ATM = Forum
  "Shahram Davari" = <Shahram_Davari@pmc-sierra.com>
  Discussion: ATM Forum detected problems with = PDU mode and as a result
          &nb= sp;   has revised it.  I will try to explain what those = problems
          &nb= sp;   are and why PWE3 should revise the PDU mode and align = it
          &nb= sp;   with ATM Forum  http://www.ietf.org/internet-drafts/draft-davari-pwe3-= aal12-over-psn-00.txt

1700-1710 Available

1710-1720 L2TPv3: "Just an Update"
  "W. Mark Townsley" = <townsley@cisco.com>
  Discussion: Give an update on the state of = L2TPv3  http://www.ietf.org/internet-drafts/draft-ietf-l2tpext= -l2tp-base-06.txt

1720-1730 Wrap Up





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

------_=_NextPart_001_01C2DF44.603C3E6A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: Re: PWE3 Draft Agenda - IETF 56 Date: Fri, 28 Feb 2003 09:21:43 -0700 Lines: 53 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O You should be able to grab them via normal ftp... If not, I'll have Tom post them to the list. They'll be submitted to internet-drafts@ietf.org when the windows opens again. danny@nomad% ftp ftp-eng.cisco.com Connected to ftp-eng.cisco.com (198.92.30.33). 220- Welcome to the Cisco Systems Engineering FTP server 220- 220- ftpeng.cisco.com supports only the Engineering community at Cisco Systems 220- 220- For product information, job opportunities and software images, please 220- disconnect from ftpeng.cisco.com and connect instead to cco.cisco.com. 220- or point your web browser at http://www.cisco.com 220- 220- ftpeng.cisco.com is accessible only for anonymous FTP. 220- 220- | | 220- If you have any questions about this, ||| ||| 220- please send e-mail to ftpeng@cisco.com ||||| ||||| 220- .:|||||||:..:|||||||:. 220- ------------------------------------------------------------------------- 220- 220 ftp-eng.cisco.com FTP server (Version wu-2.6.2(1) Thu Dec 13 23:14:01 PST 2001) ready . Name (ftp-eng.cisco.com:danny): ftp 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls tnadeau/oam 227 Entering Passive Mode (198,92,30,33,123,110) 150 Opening ASCII mode data connection for /bin/ls. total 88 -rwxr-xr-x 1 57057 eng 25529 Feb 26 14:50 draft-nadeau-mpls-oam-requirements-00.txt -rwxr-xr-x 1 57057 eng 32514 Feb 26 14:50 draft-nadeau-pwe3-oam-msgmap-00.txt -rwxr-xr-x 1 57057 eng 25017 Feb 28 06:08 draft-nadeau-pwe3-vccv-00.txt 226 Transfer complete. ftp> ftp> ls tnadeau/PWEMIB 227 Entering Passive Mode (198,92,30,33,178,112) 150 Opening ASCII mode data connection for /bin/ls. total 40 -rwxr-xr-x 1 57057 eng 40323 Feb 28 06:19 draft-sathappan-pw-atm-mib-00.txt 226 Transfer complete. -danny > I am unable to obtain the drafts from the Cisco anonymous server. Will they > be available via normal channels for review? From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "David Allan" Subject: RE: PWE3 Draft Agenda - IETF 56 Date: Fri, 28 Feb 2003 11:40:08 -0500 Lines: 236 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DF48.08B08260" Return-path: To: "'danny@tcb.net'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2DF48.08B08260 Content-Type: text/plain; charset="iso-8859-1" I think Tom should post this stuff ASAP to at least be within the spirit of the "-00" deadline. Any browser or FTP tools on my laptop are not working with the URLs provided, so I'd presume that MAY be true for others. Cheers Dave -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Friday, February 28, 2003 11:22 AM To: pwe3@ietf.org Subject: Re: [PWE3] PWE3 Draft Agenda - IETF 56 You should be able to grab them via normal ftp... If not, I'll have Tom post them to the list. They'll be submitted to internet-drafts@ietf.org when the windows opens again. danny@nomad% ftp ftp-eng.cisco.com Connected to ftp-eng.cisco.com (198.92.30.33). 220- Welcome to the Cisco Systems Engineering FTP server 220- 220- ftpeng.cisco.com supports only the Engineering community at Cisco Systems 220- 220- For product information, job opportunities and software images, please 220- disconnect from ftpeng.cisco.com and connect instead to cco.cisco.com. 220- or point your web browser at http://www.cisco.com 220- 220- ftpeng.cisco.com is accessible only for anonymous FTP. 220- 220- | | 220- If you have any questions about this, ||| ||| 220- please send e-mail to ftpeng@cisco.com ||||| ||||| 220- .:|||||||:..:|||||||:. 220- ------------------------------------------------------------------------- 220- 220 ftp-eng.cisco.com FTP server (Version wu-2.6.2(1) Thu Dec 13 23:14:01 PST 2001) ready . Name (ftp-eng.cisco.com:danny): ftp 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls tnadeau/oam 227 Entering Passive Mode (198,92,30,33,123,110) 150 Opening ASCII mode data connection for /bin/ls. total 88 -rwxr-xr-x 1 57057 eng 25529 Feb 26 14:50 draft-nadeau-mpls-oam-requirements-00.txt -rwxr-xr-x 1 57057 eng 32514 Feb 26 14:50 draft-nadeau-pwe3-oam-msgmap-00.txt -rwxr-xr-x 1 57057 eng 25017 Feb 28 06:08 draft-nadeau-pwe3-vccv-00.txt 226 Transfer complete. ftp> ftp> ls tnadeau/PWEMIB 227 Entering Passive Mode (198,92,30,33,178,112) 150 Opening ASCII mode data connection for /bin/ls. total 40 -rwxr-xr-x 1 57057 eng 40323 Feb 28 06:19 draft-sathappan-pw-atm-mib-00.txt 226 Transfer complete. -danny > I am unable to obtain the drafts from the Cisco anonymous server. Will > they be available via normal channels for review? _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C2DF48.08B08260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE3 Draft Agenda - IETF 56

I think Tom should post this stuff ASAP to at least = be within the spirit of the "-00" deadline. Any browser or = FTP tools on my laptop are not working with the URLs provided, so I'd = presume that MAY be true for others.

Cheers
Dave

-----Original Message-----
From: Danny McPherson [mailto:danny@tcb.net]
Sent: Friday, February 28, 2003 11:22 AM
To: pwe3@ietf.org
Subject: Re: [PWE3] PWE3 Draft Agenda - IETF 56 =



You should be able to grab them via normal = ftp...

If not, I'll have Tom post them to the list.  = They'll be submitted to internet-drafts@ietf.org when the windows opens = again.

danny@nomad% ftp ftp-eng.cisco.com
Connected to ftp-eng.cisco.com = (198.92.30.33).
220-  Welcome to the Cisco Systems Engineering = FTP server
220-
220-  ftpeng.cisco.com supports only the = Engineering community at Cisco Systems
220-
220-  For product information, job = opportunities and software images, please
220-  disconnect from ftpeng.cisco.com and = connect instead to cco.cisco.com.
220-  or point your web browser at http://www.cisco.com
220-
220-  ftpeng.cisco.com is accessible only for = anonymous FTP.
220-
220-          = ;            = ;            = ;            = ;          = |          |
220-  If you have any questions about = this,           &= nbsp;    |||        = |||
220-  please send e-mail to = ftpeng@cisco.com         &n= bsp;    |||||      |||||
220-          = ;            = ;            = ;            = ;     .:|||||||:..:|||||||:.
220-  = ------------------------------------------------------------------------= -
220-
220 ftp-eng.cisco.com FTP server (Version = wu-2.6.2(1) Thu Dec 13 23:14:01 PST 2001) ready . Name = (ftp-eng.cisco.com:danny): ftp 331 Guest login ok, send your complete = e-mail address as password.

Password:
230 Guest login ok, access restrictions = apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls tnadeau/oam
227 Entering Passive Mode = (198,92,30,33,123,110)
150 Opening ASCII mode data connection for = /bin/ls.
total 88
-rwxr-xr-x   1 57057    = eng         25529 Feb 26 14:50 = draft-nadeau-mpls-oam-requirements-00.txt
-rwxr-xr-x   1 57057    = eng         32514 Feb 26 14:50 = draft-nadeau-pwe3-oam-msgmap-00.txt
-rwxr-xr-x   1 57057    = eng         25017 Feb 28 06:08 = draft-nadeau-pwe3-vccv-00.txt
226 Transfer complete.
ftp>
ftp> ls tnadeau/PWEMIB
227 Entering Passive Mode = (198,92,30,33,178,112)
150 Opening ASCII mode data connection for = /bin/ls.
total 40
-rwxr-xr-x   1 57057    = eng         40323 Feb 28 06:19 = draft-sathappan-pw-atm-mib-00.txt
226 Transfer complete.


-danny

> I am unable to obtain the drafts from the Cisco = anonymous server. Will
> they be available via normal channels for = review?

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

------_=_NextPart_001_01C2DF48.08B08260-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Thomas D. Nadeau" Subject: Re: PWE3 Draft Agenda - IETF 56 Date: Fri, 28 Feb 2003 11:47:39 -0500 Lines: 69 Sender: pwe3-admin@ietf.org References: <20030228162148.9D1F555F62@nomad.tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: danny@tcb.net, pwe3@ietf.org In-Reply-To: <20030228162148.9D1F555F62@nomad.tcb.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 09:21 AM 2/28/2003 -0700, Danny McPherson wrote: >You should be able to grab them via normal ftp... > >If not, I'll have Tom post them to the list. They'll be submitted >to internet-drafts@ietf.org when the windows opens again. > >danny@nomad% ftp ftp-eng.cisco.com >Connected to ftp-eng.cisco.com (198.92.30.33). >220- Welcome to the Cisco Systems Engineering FTP server >220- >220- ftpeng.cisco.com supports only the Engineering community at Cisco >Systems >220- >220- For product information, job opportunities and software images, please >220- disconnect from ftpeng.cisco.com and connect instead to cco.cisco.com. >220- or point your web browser at http://www.cisco.com >220- >220- ftpeng.cisco.com is accessible only for anonymous FTP. >220- >220- | | >220- If you have any questions about this, ||| ||| >220- please send e-mail to ftpeng@cisco.com ||||| ||||| >220- .:|||||||:..:|||||||:. >220- >------------------------------------------------------------------------- >220- >220 ftp-eng.cisco.com FTP server (Version wu-2.6.2(1) Thu Dec 13 23:14:01 >PST 2001) ready >. >Name (ftp-eng.cisco.com:danny): ftp >331 Guest login ok, send your complete e-mail address as password. >Password: >230 Guest login ok, access restrictions apply. >Remote system type is UNIX. >Using binary mode to transfer files. >ftp> ls tnadeau/oam >227 Entering Passive Mode (198,92,30,33,123,110) >150 Opening ASCII mode data connection for /bin/ls. >total 88 >-rwxr-xr-x 1 57057 eng 25529 Feb 26 14:50 >draft-nadeau-mpls-oam-requirements-00.txt >-rwxr-xr-x 1 57057 eng 32514 Feb 26 14:50 >draft-nadeau-pwe3-oam-msgmap-00.txt >-rwxr-xr-x 1 57057 eng 25017 Feb 28 06:08 >draft-nadeau-pwe3-vccv-00.txt >226 Transfer complete. >ftp> >ftp> ls tnadeau/PWEMIB >227 Entering Passive Mode (198,92,30,33,178,112) >150 Opening ASCII mode data connection for /bin/ls. >total 40 >-rwxr-xr-x 1 57057 eng 40323 Feb 28 06:19 >draft-sathappan-pw-atm-mib-00.txt >226 Transfer complete. > > >-danny > > > I am unable to obtain the drafts from the Cisco anonymous server. Will they > > be available via normal channels for review? You have to go to ftp-eng.cisco.com and log in anonymously. Once logged in, cd to "/tnadeau/oam" or "tnadeau/PWEMIB". You should see the files there. I just double-checked that it worked both from the web and directly. --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: Re: PWE3 Draft Agenda - IETF 56 Date: Fri, 28 Feb 2003 09:48:54 -0700 Lines: 15 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I think Tom should post this stuff ASAP to at least be within the spirit of > the "-00" deadline. Any browser or FTP tools on my laptop are not working > with the URLs provided, so I'd presume that MAY be true for others. Tom missed the -00 deadline (2/24), else they'd be posted now. If you have problems accessing them send email to Tom (so he can have his IT folks remove the Nortel PTR filter -- just kidding :-), or perhaps your IT folks :-) If you can't get them let me know and I'll send them to you. If they weren't publicly accessible they wouldn't be on the agenda. -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Draft Agenda - IETF 56 Date: Fri, 28 Feb 2003 11:57:40 -0500 Lines: 142 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "David Allan" , "'danny@tcb.net'" , pwe3@ietf.org In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >I am unable to obtain the drafts from the Cisco anonymous server. Will >they be available via normal channels for review? The links were incorrect; here are the right ones. Danny, please update the agenda with these links. I just verified that they work: ftp://ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-mpls-oam-requirements-00.txt ftp://ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-oam-msgmap-00.txt ftp://ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-vccv-00.txt ftp://ftp-eng.cisco.com/tnadeau/PWEMIB/draft-sathappan-pw-atm-mib-00.txt Sorry for the confusion. --Tom >Thx >Dave > >-----Original Message----- >From: Danny McPherson [mailto:danny@tcb.net] >Sent: Friday, February 28, 2003 10:54 AM >To: pwe3@ietf.org >Subject: [PWE3] PWE3 Draft Agenda - IETF 56 > > >Any last comments before I post? > >-danny > >================================================================== >Pseudo Wire Emulation Edge to Edge (pwe3) > >Wednesday, March 19 1530-1730 >============================= > >CHAIR: "Danny McPherson" > >AGENDA: > >1530-1540 Administrivia > "Danny McPherson" > > Agenda Bashing > Minutes > Blue Sheets > WG Document Status > >1540-1600 PWE3 Architecture & Congestion Control > "Stewart Bryant" > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-02.txt> > > Discussion: 1) Update on current architecture document > 2) Discussion of PWE3 Congestion Control > >1600-1610 PWE3 OAM: Virtual Circuit Connection Verification > "Thomas Nadeau" > Discussion: PWE3 OAM Message Mapping and MPLS OAM. Discussion > of the VCCV and OAM message mapping drafts, how they > fit into and satisfy the MPLS OAM requirements, and > next > steps. > ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-vccv-00.txt > > >ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-pwe3-oam-msgmap-00.txt > > >ftp://anonymous@ftp-eng.cisco.com/tnadeau/oam/draft-nadeau-mpls-oam-requirements-00.txt > > >1610-1615 ATM PW MIB > "Thomas D. Nadeau" > Discussion: Discussion of PW ATM MIB and how it fits into > accepted PW MIB management model for PWE3. > >http://www.ietf.org/internet-drafts/draft-sathappan-pw-atm-mib-00.txt > > >1615-1625 TDM Proposals > "Tom K. Johnson" > Discussion: Discuss alternate proposal for DS3, E3, DS1, E1, > and NxDS0 circuit > emulation. > http://www.ietf.org/internet-drafts/draft-johnson-pwe3-tdm-00.txt > > >1625-1635 Open Issues in TDM Requirements Draft > "Max Riegel" > Discussion: Discussion of open issues from the mailing list > and clarification of further proceeding with the > document in alignment with other WG > I-Ds. > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-00.txt > >1635-1645 TDM over IP Using Loop Emulation > "Yaakov Stein" > Discussion: TDM o IP using Loop Emulation, with emphasis on > bandwidth conservation and the possibilities it > opens for congestion > avoidance. > http://www.dspcsp.com/tdmoip/draft-stein-pwe3-tdmoiple-00.txt > > >1645-1655 PW Setup & Maintenance Using LDP > "Luca Martini" > Discussion: Discuss changes regarding move of LDP setup > and control protocol to separate > document. > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-00.txt > >1655-1700 Aligning PDU transport mode with ATM Forum > "Shahram Davari" > Discussion: ATM Forum detected problems with PDU mode and as a result > has revised it. I will try to explain what those problems > are and why PWE3 should revise the PDU mode and align it > with ATM > Forum > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-over-psn-00.txt > > >1700-1710 Available > >1710-1720 L2TPv3: "Just an Update" > "W. Mark Townsley" > Discussion: Give an update on the state of > L2TPv3 > http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-06.txt > >1720-1730 Wrap Up > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Walsh, Thomas D (Tom)" Subject: Liaison from MPLS Forum to PWE3 Date: Fri, 28 Feb 2003 13:20:03 -0500 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O To: IETF PWE3 working group From: MPLS Forum The MPLS Forum Technical Committee has been discussing the transport of TDM over MPLS networks, and we now have a draft of the "TDM Transport over MPLS using AAL1 Implementation Agreement" reaching its final stages. Since the PWE3 working group has also been working on this issue, we would like to invite comments from the WG before progressing this text to final ballot. For this purpose, we have placed the straw ballot text of the Implementation Agreement in the public area of our web site, at http://www.mplsforum.org/tech/mpls2003.036.01.pdf . We have temporarily delayed the advancement of our Implementation Agreement in order to avoid conflicts between the specifications. Alignment with IETF RFCs is a key objective for implementation agreements reached in the MPLS Forum. However, there is also significant interest in the MPLS Forum to bring this work to a conclusion. The MPLS Forum encourages the PWE3 WG to reach a timely agreement on this topic so that our two bodies can produce an aligned solution. Comments are invited from individual IETF and IESG participants, the working group as a body, and the IESG as a body. We will look for comments and discussion on the PWE3 mailing list. Best regards, Andy Malis MPLS Forum President Tom Walsh MPLS Forum External Relations From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Chris Metz Subject: RE: Comments on Martini PDU mode Date: Fri, 28 Feb 2003 15:45:18 -0500 Lines: 181 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDEB03C7C@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_28293543==_.ALT" Cc: Shahram Davari , "'pwe3@ietf.org'" Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03C7C@nt-exch-yow.pmc-sie rra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --=====================_28293543==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:21 AM 2/7/2003 -0800, Shahram Davari wrote: >Dear colleagues, > >I forgot to mention another important reason for such a proposed change: > >3) As stated in the draft, Fragmentation is mainly used for preserving the >ATM OAM cell position in respect to AAL5 composite cells. Reassembling the >AAL5 PDU at the egress PE would cause repositioning of the OAM cells with >respect to the AAL5 composite cells. Therefore to preserve OAM cells >position, the egress should not reassemble the AAL5 PDU. And since no >reassembling is required, there there is no need to identify beginning and >middle of message. Hey Shahram- So to be clear, what is happening at the egress PE is that the no assembly of the original AAL5 PDU is taking place, correct?. How about the fragments of the original AAL5 PDU? If those are not being reassembled then what is happening? ... each constituent cell of the AAL5 PDU transmitted individually (and in order)? Thanks for the clarification, cheers ... > >Yours, >Shahram >>-----Original Message----- >>From: Shahram Davari >>Sent: Friday, February 07, 2003 11:00 AM >>To: 'pwe3@ietf.org' >>Subject: [PWE3] Comments on Martini PDU mode >> >>Dear colleagues, >> >>As some of you may know, ATM Forum has recently approved a minor change >>to the PDU frame transport mode. >>ATM Forum has changed the 2-bit FRAG field to a single field called >>UU-bit, that would be copied from the last >>encapsulated ATM cell's header. The reasons for this change are as following: >> >>1) Although PDU mode does not state explicitly what are the procedures >>for fragmentation at the ingress and de-fragmentation at the egress side, >>but it implicitly assumes that the AAL5 PDU is reassembled at the egress >>PE. It seems that for reducing the latency and for simplicity in >>processing, there is no need to reassemble the fragments at the egress >>PE. Rather each received fragment could be segmented to constituents ATM >>cells without waiting to reassemble the whole AAL5 frame. All known >>implementation of PDU mode behave as such. >> >>2) Considering the above point, it seems that out of the currently >>defined values for FRAG: >> >>"Frg (Fragmentation) Bits >> >> This field is used to support the fragmentation functionality >> described later in this section. >> - 11 Single Segment Message (Beginning and End of Message) >> - 10 Beginning of Message >> - 00 Continuation of Message >> - 01 End of Message " >> >>The Beginning of Message (10) and the continuation of message (00) are >>not needed for the egress >>processing. And therefore a single bit could be used to keep the >>transparency of the AAL5 EOM (End of Message). >>This field could be called UU-bit and be copied from the header of the >>last cell of the fragment to the PW header. >> >>I would like to propose changing the PDU mode in Martini draft to >>simplify the processing, reduce latency and buffering requirements at the >>egress PE. >> >>Yours, >>Shahram Davari >>Senior Product Research Engineer >>R&D Research Ottawa >>PMC-Sierra, Inc. >>Phone: (613) 271-4018 >>Fax: (613) 271-6468 >> --=====================_28293543==_.ALT Content-Type: text/html; charset="us-ascii" At 08:21 AM 2/7/2003 -0800, Shahram Davari wrote:
Dear colleagues,
 
I forgot to mention another important reason for such a proposed change:
 
3) As stated in the draft, Fragmentation is mainly used for preserving the ATM OAM cell position in respect to AAL5 composite cells. Reassembling the AAL5 PDU at the egress PE would cause repositioning of the OAM cells with respect to the AAL5 composite cells. Therefore to preserve OAM cells position, the egress should not reassemble the AAL5 PDU. And since no reassembling is required, there there is no need to identify beginning and middle of message.

Hey Shahram-
So to be clear, what is happening at the egress PE is that the no assembly of the original AAL5 PDU is taking place, correct?. How about the fragments of the original AAL5 PDU? If those are not being reassembled then what is happening? ... each constituent cell of the AAL5 PDU transmitted individually (and in order)?

Thanks for the clarification, cheers ...


 
Yours,
Shahram
-----Original Message-----
From: Shahram Davari
Sent: Friday, February 07, 2003 11:00 AM
To: 'pwe3@ietf.org'
Subject: [PWE3] Comments on Martini PDU mode

Dear colleagues,
 
As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode.
ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last
encapsulated ATM cell's header. The reasons for this change are as following:
 
1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such.
 
2) Considering the above point, it seems that out of the currently defined values for FRAG:
 
"Frg (Fragmentation) Bits

       This field is used to support the fragmentation functionality
       described later in this section.
     - 11 Single Segment Message (Beginning and End of Message)
     - 10 Beginning of Message
     - 00 Continuation of Message
     - 01 End of Message "
 
The Beginning of Message (10) and the continuation of message (00) are not needed for the egress
processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message).
This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header.
 
I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE.
 
Yours,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc.
Phone: (613) 271-4018
Fax:   (613) 271-6468
 
--=====================_28293543==_.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: Comments on Martini PDU mode Date: Fri, 28 Feb 2003 12:48:58 -0800 Lines: 171 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DF6A.D0C6C490" Cc: "'pwe3@ietf.org'" Return-path: To: "'Chris Metz'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C2DF6A.D0C6C490 Content-Type: text/plain Yes, the fragments will be chopped to individual cells and sent in order they arrive at the egress PE. -Shahram -----Original Message----- From: Chris Metz [mailto:chmetz@cisco.com] Sent: Friday, February 28, 2003 3:45 PM To: Shahram Davari Cc: Shahram Davari; 'pwe3@ietf.org' Subject: RE: [PWE3] Comments on Martini PDU mode At 08:21 AM 2/7/2003 -0800, Shahram Davari wrote: Dear colleagues, I forgot to mention another important reason for such a proposed change: 3) As stated in the draft, Fragmentation is mainly used for preserving the ATM OAM cell position in respect to AAL5 composite cells. Reassembling the AAL5 PDU at the egress PE would cause repositioning of the OAM cells with respect to the AAL5 composite cells. Therefore to preserve OAM cells position, the egress should not reassemble the AAL5 PDU. And since no reassembling is required, there there is no need to identify beginning and middle of message. Hey Shahram- So to be clear, what is happening at the egress PE is that the no assembly of the original AAL5 PDU is taking place, correct?. How about the fragments of the original AAL5 PDU? If those are not being reassembled then what is happening? ... each constituent cell of the AAL5 PDU transmitted individually (and in order)? Thanks for the clarification, cheers ... Yours, Shahram -----Original Message----- From: Shahram Davari Sent: Friday, February 07, 2003 11:00 AM To: 'pwe3@ietf.org' Subject: [PWE3] Comments on Martini PDU mode Dear colleagues, As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode. ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last encapsulated ATM cell's header. The reasons for this change are as following: 1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such. 2) Considering the above point, it seems that out of the currently defined values for FRAG: "Frg (Fragmentation) Bits This field is used to support the fragmentation functionality described later in this section. - 11 Single Segment Message (Beginning and End of Message) - 10 Beginning of Message - 00 Continuation of Message - 01 End of Message " The Beginning of Message (10) and the continuation of message (00) are not needed for the egress processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message). This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header. I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE. Yours, Shahram Davari Senior Product Research Engineer R&D Research Ottawa PMC-Sierra, Inc. Phone: (613) 271-4018 Fax: (613) 271-6468 ------_=_NextPart_001_01C2DF6A.D0C6C490 Content-Type: text/html
Yes, the fragments will be chopped to individual cells and sent in order they arrive at the egress PE.
 
-Shahram
-----Original Message-----
From: Chris Metz [mailto:chmetz@cisco.com]
Sent: Friday, February 28, 2003 3:45 PM
To: Shahram Davari
Cc: Shahram Davari; 'pwe3@ietf.org'
Subject: RE: [PWE3] Comments on Martini PDU mode

At 08:21 AM 2/7/2003 -0800, Shahram Davari wrote:
Dear colleagues,
 
I forgot to mention another important reason for such a proposed change:
 
3) As stated in the draft, Fragmentation is mainly used for preserving the ATM OAM cell position in respect to AAL5 composite cells. Reassembling the AAL5 PDU at the egress PE would cause repositioning of the OAM cells with respect to the AAL5 composite cells. Therefore to preserve OAM cells position, the egress should not reassemble the AAL5 PDU. And since no reassembling is required, there there is no need to identify beginning and middle of message.

Hey Shahram-
So to be clear, what is happening at the egress PE is that the no assembly of the original AAL5 PDU is taking place, correct?. How about the fragments of the original AAL5 PDU? If those are not being reassembled then what is happening? ... each constituent cell of the AAL5 PDU transmitted individually (and in order)?

Thanks for the clarification, cheers ...



Yours,
Shahram
-----Original Message-----
From: Shahram Davari
Sent: Friday, February 07, 2003 11:00 AM
To: 'pwe3@ietf.org'
Subject: [PWE3] Comments on Martini PDU mode

Dear colleagues,
 
As some of you may know, ATM Forum has recently approved a minor change to the PDU frame transport mode.
ATM Forum has changed the 2-bit FRAG field to a single field called UU-bit, that would be copied from the last
encapsulated ATM cell's header. The reasons for this change are as following:
 
1) Although PDU mode does not state explicitly what are the procedures for fragmentation at the ingress and de-fragmentation at the egress side, but it implicitly assumes that the AAL5 PDU is reassembled at the egress PE. It seems that for reducing the latency and for simplicity in processing, there is no need to reassemble the fragments at the egress PE. Rather each received fragment could be segmented to constituents ATM cells without waiting to reassemble the whole AAL5 frame. All known implementation of PDU mode behave as such.
 
2) Considering the above point, it seems that out of the currently defined values for FRAG:
 
"Frg (Fragmentation) Bits

       This field is used to support the fragmentation functionality
       described later in this section.
     - 11 Single Segment Message (Beginning and End of Message)
     - 10 Beginning of Message
     - 00 Continuation of Message
     - 01 End of Message "
 
The Beginning of Message (10) and the continuation of message (00) are not needed for the egress
processing. And therefore a single bit could be used to keep the transparency of the AAL5 EOM (End of Message).
This field could be called UU-bit and be copied from the header of the last cell of the fragment to the PW header.
 
I would like to propose changing the PDU mode in Martini draft to simplify the processing, reduce latency and buffering requirements at the egress PE.
 
Yours,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc.
Phone: (613) 271-4018
Fax:   (613) 271-6468
 
------_=_NextPart_001_01C2DF6A.D0C6C490-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "tom k. johnson" Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Fri, 28 Feb 2003 19:29:47 -0500 Lines: 106 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt Thread-Index: AcLfJuFrdilH4g0XSO2x6Gwi+GGndwATbA4A To: X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h210b3p07245 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O A little background on the draft... A TDM design team was formed just prior to the Atlanta meeting. The team was comprised of Sasha Vainshtein Yaakov Stein Max Riegel Prayson Pate Tim Frost Shahram Davari At the Atlanta meeting a compromise was proposed between the Vainshtein and Anavi camps. However, after the Atlanta meeting the compromise fell apart . Since then, the TDM design team has attempted to find a unified solution that is optimized for packet switched networks, provides significant flexibility to trade-off latency for overhead, and offers a reasonable path for interworking PWE-TDM to AAL1. There was a lot of back and forth during the creation of this draft between the various contributors, and I believe that most of the team agrees with most (although not all) aspects of the draft. I'm sure the interested parties will be happy to point out the aspects of the draft that they do not agree with :-) Although there is still work to be done, I believe this document represents a reasonable starting point for TDM emulation and I would like to request that this draft be adopted as a WG item. Thanks! -Tom > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, February 28, 2003 7:26 AM > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : TDM Circuit Emulation over Packet (CEP-TDM) > Author(s) : T. Johnson > Filename : draft-johnson-pwe3-tdm-00.txt > Pages : 17 > Date : 2003-2-27 > > This draft proposes a TDM emulation protocol for consideration by the > PWE3 Working Group. The protocol defines methods for > transporting DS3, > E3, DS1, E1, and NxDS0 circuits over packet switched networks. It is > based on ATM Circuit Emulation, but optimized for variable length > packet networks. The intent is to provide a relatively simple but > flexible method for transporting TDM signals over packet switched > networks that also provides a path for interworking with ATM Circuit > Emulation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-johnson-pwe3-tdm-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-johnson-pwe3-tdm-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-johnson-pwe3-tdm-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. >