From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: arch-draft references Date: Fri, 01 Aug 2003 18:45:30 +0100 Organization: Cisco Systems, Inc. Lines: 142 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Aug 01 19:46:52 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "pwe3@ietf.org" 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 One last thing that we needed to do in order to get the draft IESG ready was to divide the references into normative and informational. I have done this (see below). All of the RFCs in the Normative reference section are standards track, but we need to carefully check the non-RFCs to see if they really should be normative, because they will gate this draft. I have also cleared up a couple of minor reference nits: deleted a reference that was not called up in the text, use of a name when our convention is to use RFCnumber as the reference, and incorrectly (in the text only) using 1881 when we meant 1883. Comments please. Thanks Stewart Normative References Internet-drafts are works in progress available from [FRAG] Malis and Townsley, "PWE3 Fragmentation and Reassembly", , work in progress, June 2003. [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, et. al. , work in progress, June 2003. [PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information Base Using SMIv2", , work in progress, June 2003. [PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and OBJECT-IDENTITIES for Pseudo-Wires Management" , work in progress, June 2003. [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Management Information Base Using SMIv2", , work in progress, October 2002. [RFC791] RFC-791: DARPA Internet Program, Protocol Specification, ISI, September 1981. [RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6), S. Deering, et al, December 1995 [RFC1889] RFC-1889: RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne et. al. [RFC1902] RFC-1902: Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2), Case et al, January 1996. [RFC2119] RFC-2119, BCP-14: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. [RFC2401] RFC-2401: Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. [RFC2474] RFC-2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, K. Nichols, et. al. [RFC2558] K. Tesink, "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC2558, March 1999. [RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP". W. Townsley, et. al. [RFC2784] RFC-2784: Generic Routing Encapsulation (GRE). D. Farinacci et al. [RFC2890] RFC-2890: Key and Sequence Number Extensions to GRE. G. Dommety. [RFC3031] RFC3031: Multiprotocol Label Switching Architecture, E. Rosen, January 2001. [RFC3032] RFC3032: MPLS Label Stack Encoding, E. Rosen, January 2001. [TEMIB] Srinivasan et al, "Traffic Engineering Management Information Base Using SMIv2", , work in progress, June 2003. Informative References Internet-drafts are works in progress available from [DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T), European Telecommunications Standards Institute (ETSI) [LDPMIB] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)", , work in progress, June 2003. [LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management Information Base Using SMIv2", , work in progress, June 2003. [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, J Lau et al. , work in progress, June 2002. [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. [RFC1958] RFC-1958: Architectural Principles of the Internet, B. Carpenter et al. [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul. [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based ATM Networks, G. Armitage. [RFC2338] RFC-2338: Virtual Router Redundancy Protocol, S. Knight, M. Shand et. al. [RFC3022] RFC-3022: Traditional IP Network Address Translator (Traditional NAT). P Srisuresh et al. [RFC3448] RFC3448: TCP Friendly Rate Control (TFRC): Protocol Specification, M. Handley et al. January 2003. [XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", (draft-ietf-pwe3-requirements-06.txt), X Xiao et al. work in progress, June 2002. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: D Siva Kumar Subject: Pseudowire Date: Mon, 4 Aug 2003 22:33:42 +0530 (IST) Lines: 12 Sender: pwe3-admin@ietf.org References: <3F2AA73A.9090203@cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Aug 04 19:19:10 2003 Return-path: To: Stewart Bryant In-Reply-To: <3F2AA73A.9090203@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 Hi, I have a doubt regarding service specific pseudowire. Suppose I built a pseudowire for emulating ethernet (say point to point pseudowire), then which entity in the PW architecture prevents to send framerelay packet over that pseudowire. Infact, my question reduces to "what is the need of different types of pseudowires". thanks in advance. Siva. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Dave Danenberg" Subject: CEM interoperability testing Date: Mon, 4 Aug 2003 13:25:27 -0400 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Mon Aug 04 19:26:01 2003 Return-path: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [PWE3] TDM/SONET & RTP thread-index: AcMcidHrqzuL8UOTQqKlUqab3wuS5A+H/yEQ To: "Andrew G. Malis" , Content-Transfer-Encoding: quoted-printable 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 Andy, I was wondering if Vivace (or anyone else out there) is interested in = CEM interoperability testing. Our OC3/12/48 SONET over Packet chips came back from fab and are working = fine in our validation lab (passing billions of emulated frames error = free).=20 Our evaluation board does OC48 SONET emulation over OC48 POS. Is this = suitable for your testing? Although we're going out of business, we have = a few evaluation boards available before our doors close. -Dave From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: Re: Pseudowire Date: Mon, 04 Aug 2003 19:00:45 +0100 Organization: Cisco Systems, Inc. Lines: 26 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" X-From: pwe3-admin@ietf.org Mon Aug 04 20:02:04 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: D Siva Kumar 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 D Siva Kumar wrote: > Hi, > I have a doubt regarding service specific pseudowire. > > Suppose I built a pseudowire for emulating ethernet (say point to > point pseudowire), then which entity in the PW architecture prevents > to send framerelay packet over that pseudowire. The control plane. > Infact, my question > reduces to "what is the need of different types of pseudowires". > Different services have different properties that need to be emulated, and need different PW types to transmit those properties over the PSN. > thanks in advance. > > Siva. > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-arch-05.txt Date: Mon, 04 Aug 2003 15:00:05 -0400 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 X-From: pwe3-admin@ietf.org Mon Aug 04 21:01:03 2003 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: , 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-05.txt Pages : 46 Date : 2003-8-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-05.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-05.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-05.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:45 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Tue, 05 Aug 2003 09:46:54 -0400 Organization: Alcatel Networks Corporaton Lines: 72 Sender: pwe3-admin@ietf.org References: <200307281748.h6SHm0MK004642@rtp-core-1.cisco.com> <4.3.2.7.2.20030731072108.02566ce0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Tue Aug 05 15:48:06 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ali Sajassi 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 Ali, Ali Sajassi wrote: > > At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote: > >Eric, > >draft-sajassil2vpn-interworking-01.txt has a wider scope than mine since > >it goes > >into some of the details of the interworking. In terms of the > >encapsulation, Ali > >proposes to use the PID field similar to the one used in GRE encapsulation. > > The draft discusses two approaches: > a) using multiple PWs > b) using multi-protocol PW > > and discusses the pros/cons of each. It also clearly states an example > where the user can just get away with just two PWs for multi-protocol > support (one for IP and another for non-IP based on Ethernet/bridged encap) > by configuring IP traffic as routed and all other non-IP traffic as bridged > encap. > > At this point, I think the multiple PWs scheme is sufficient - one for IP > and the other for non-IP traffic which is bridged encapsulated. And we > don't need to define a new multi-protocol PW unless it is shown otherwise. MA> I have issues with the 1-N VC-to-PW which I described in my earlier emails. Furthermore, I do not expect all my customers to go and change their encapsulations in their many sites to bridged type unless absolutely required. > >The reason why this is not sufficient is because many protocols are carried in > >RFC 2427 and 2684 by appending the organization unique identifier (OUI) to the > >payload. This is certainly the case of the IEEE 802.1 MAC types and private > >organization protocols. When Andy and I looked into the best way to structure > >the PID, we wanted to make sure we continue to support these and to limit the > >number of combinations possible to represent a single protocol. > > Are you trying to re-invent FRF8.1 !!! > If you look at the draft closely, it says that for full ATM-FR > interworking, standard FR8.1 is recommended by extending one PW to another > side. And for the sub-set one can use the two-PW scheme. > Also if one wanted to use multi-protocol PW, then GRE-based PID is > sufficient since if you take a look at the FRF8.1, the LLC/SNAP field for > the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is fixed and thus you > don't need to send them over the PW each time. MA> In fact, we made sure that most protocols required only a single word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC Types and Private Protocols) add a SNAP field and thus a 2-word multiprotocol header. > >What I would like to propose to Ali is to separate out the encapsulation and > >signaling from his draft such that we progress the work here in PWE3 (assuming > >the charter is modified). The other interworking aspects in his draft can be > >progressed in the l2vpn WG. > > As I mentioned, at this point I think the use of multiple PWs is sufficient > and if it is shown that a new multi-protocol PW is needed, then still I > think GRE-based is both sufficient and efficient since we don't want to add > a fixed LLC/SNAP header to each packet knowing that 99% of them don't > require it !!! MA> Where do you see LLC/SNAP in my draft?? > -Ali > > >Thanks for the interesting exchange. > > > >Mustapha. > >----------- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Tue, 05 Aug 2003 09:53:32 -0400 Organization: Alcatel Networks Corporaton Lines: 43 Sender: pwe3-admin@ietf.org References: <200307171955.h6HJteAi011650@rtp-core-2.cisco.com> <4.3.2.7.2.20030730133806.0256d440@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Tue Aug 05 15:54:01 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ali Sajassi 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 Ali, Ali Sajassi wrote: > > > > >There was good support to start service interworking in the L2VPN WG > >meeting yesterday. If this happens, clearly the encpasulation and > >signaling parts are part of the PWE3. > > If I remember correctly, there was a good support to take care of L2VPN > scenarios with disparate interfaces and this doesn't necessarily mean > service interworking. MA> You can give it any name you like, I have an issue with some of my customers and I am looking for a way to resolve it. > >In my presentation, I mentioned three options: > >a. extend FR or Ethernet to the remote PE. This is a valid solution > >and should be supported. The problem is there are more and more > >Ethernet/MPLS PE products out there which do not implement anything > >about FRoMPLS, let alone FR-Ethernet interworking. > >b. split the FR VC into multiple parallel PWs (1-to-N). I guess the > >implementation complexity and troublshooting complications of this > >solutions are obvious. > >c. The PID translation between FR, PW, and Ethernet. In my view this > >is the most straighforward solution. It does not change the > >forwarding paradigm because it is still based on the label. It only > >tranlates a PID in the paylod between FR and PW or FR and Ethernet. > > All these scenarios plus more have been described in > draft-sajassi-l2vpn-interworking and as I said before it is not as simple > as just getting PID assignment for different protocol types coming over > disparate interfaces !!! You need to pay attention to the dependency > between L3 protocol and the underlying L2 transport and its ramification. MA> I agree we need to consider these. Though, the dependency of the L3 protocol on the type of L2 interface is an orthogonal issue to the encapsulation one. You need to address the former no matter how you perform the encapsulation. By the way, draft-sajassi-l2vpn-interworking provides a good coverage of the issues. Well done. > -Ali From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Tue, 05 Aug 2003 10:02:54 -0400 Organization: Alcatel Networks Corporaton Lines: 87 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> <3F151009.B738C6EA@alcatel.com> <3F1533AE.3080608@level3.net> <4.3.2.7.2.20030730130915.0246ad98@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Tue Aug 05 16:04:03 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ali Sajassi 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 Ali, Ali Sajassi wrote: > > Mustapha, > > As I mentioned during the meeting and as mentioned in my draft, there is a > L3 dependancy on L2 interfaces and therefore supporting multiple protocols > between two heterogeneous ACs is not as simple as just coming up with PID > assignment. In your example of FR and Ethernet interfaces having IP and > IS-IS on top of them, the IP requires ARP mediation and IS-IS simply > doesn't work in your example - take a look at arp-mediation draft. > > -Ali MA> Thanks for pointing this out. I saw this and I also looked into the referenced document, draft-ietf-isis-igp-p2p-over-lan-02.txt. I am very interested in this topic. > At 08:05 AM 7/16/2003 -0400, Mustapha Aissaoui wrote: > >Luca, > >a MPLS label cannot indicate that both IP and IS-IS/CLNP are being > >carried in the PW. You would need either to extend FR (or Ethernet) > >to the remote PE or create multiple PWs for each payload in the > >terminated FR VC. > >The first solution is valid but the issue is that you typically do > >not expect all remote PE's (which have only GigE and MPLS > >interfaces) to understand FRoMPLS and RFC 2427. The multiple PWs per > >FR VC is not practical. So, the translation of the FR and Ethernet > >PIDs to the PW PID allows a suitable solution. > > > >Mustapha. > >--------------- > >Luca Martini wrote: > > > > > > and what does this add that cannot be indicated by an MPLS label ? > > > > > > Luca > > > > > > Mustapha Aissaoui wrote: > > > > George, > > > > I just send an updated slide set to Danny for my presentation this > > > > afternoon of draft-aissaoui-extended-pid. I added an example > > > > application where the translation of PID between FR, PW, and > > > > Ethernet is very useful. The main point is that in many of the > > > > installed base of L2 VPN, FR and ATM VCs carry more than one user > > > > payload (e.g., IP and IS-IS/CLNP). In those cases only, a > > > > translation of PID is useful if one one wants to have dissimilar L2 > > > > access over a PW (e.g., FR-MPLS-Ethernet). > > > > > > > > I hope Danny will upload it soon so that everone will have a chance > > > > to see it before the meeting this afternoon. > > > > > > > > Mustapha. > > > > ---------- > > > > George Swallow wrote: > > > > > > > >>>5.4.4. MPLS Payload Identifier > > > >>> > > > >>> > > > >>> If technical considerations result in a PW control word that may > > > >>> alias an IP packet, the control word SHOULD be preceded by an MPLS > > > >>> payload type identifier. > > > >>> > > > >> > > > >>What problem does this solve that just adding four bytes to your > > > >>header (in the putative case) doesn't solve? > > > >> > > > >>...George > > > >> > > > >>======================================================================== > > > >>George Swallow Cisco Systems (978) 936-1398 > > > >> 1414 Massachusetts Avenue > > > >> Boxborough, MA 01719 > > > > > > > > > > > > _______________________________________________ > > > > 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:45 2006 From: Danny McPherson Subject: Fwd: MIB review guidelines ptr added to: http://www.ietf.org/IESG/wgch airs.html Date: Tue, 5 Aug 2003 14:11:04 -0600 Lines: 42 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Aug 05 22:12:08 2003 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.552) 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 FYI... Begin forwarded message: > From: "Wijnen, Bert (Bert)" > Date: Tue Aug 5, 2003 8:14:38 AM America/Denver > Subject: MIB review guidelines ptr added to: > http://www.ietf.org/IESG/wgch airs.html > > Just so all WG chairs know, the iesg-secretariat has added a ptr > to the Mib-Review-Guidelines (those used by MIB doctors to review > MIB documents when asked by IESG or ADs) to the wgchairs web > page at: http://www.ietf.org/IESG/wgchairs.html > > If you want to go to them rigth away, the current MIB-Review-Guidelines > are in document: > > www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines- > 01.txt > > If you (WG chairs) or your WG members or MIB document editors/authors > have any issues, concerns, comments on thise review guidelines, pls > holler and let us know about it (mibs@ops.ietf.org is the best > mailing list for it, but if you send it to me I will handle). > > Whenever a MIB document comes to the IESG, the responsible AD normally > asks > me (OPS NM AD) to get a MIB Doctor review done (often before we issue > an IETF Last Call). So that is where this comes into play. > > Of course, if WG chairs review MIB documents against those guidelines > themselves first (or make their WG members or doc editors/authors do > so), > then that will make the approval process go faster/smoother. > > Hope this helps > Bert Wijnen > co-AD OPS (NM) Area > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Serbest, Yetik" Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Tue, 5 Aug 2003 10:35:00 -0500 Lines: 90 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Aug 06 11:01:11 2003 Return-path: To: "'Mustapha Aissaoui'" , Ali Sajassi 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 Why are your customers so adamant on not changing their encapsulations? Is it because their CPE does not support bridged encapsulations (like old FRADs)? -----Original Message----- From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] Sent: Tuesday, August 05, 2003 8:47 AM To: Ali Sajassi Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 Ali, Ali Sajassi wrote: > > At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote: > >Eric, > >draft-sajassil2vpn-interworking-01.txt has a wider scope than mine > >since it goes into some of the details of the interworking. In terms > >of the encapsulation, Ali > >proposes to use the PID field similar to the one used in GRE encapsulation. > > The draft discusses two approaches: > a) using multiple PWs > b) using multi-protocol PW > > and discusses the pros/cons of each. It also clearly states an example > where the user can just get away with just two PWs for multi-protocol > support (one for IP and another for non-IP based on Ethernet/bridged > encap) by configuring IP traffic as routed and all other non-IP > traffic as bridged encap. > > At this point, I think the multiple PWs scheme is sufficient - one for > IP and the other for non-IP traffic which is bridged encapsulated. And > we don't need to define a new multi-protocol PW unless it is shown > otherwise. MA> I have issues with the 1-N VC-to-PW which I described in my earlier emails. Furthermore, I do not expect all my customers to go and change their encapsulations in their many sites to bridged type unless absolutely required. > >The reason why this is not sufficient is because many protocols are > >carried in RFC 2427 and 2684 by appending the organization unique > >identifier (OUI) to the payload. This is certainly the case of the > >IEEE 802.1 MAC types and private organization protocols. When Andy > >and I looked into the best way to structure the PID, we wanted to > >make sure we continue to support these and to limit the number of > >combinations possible to represent a single protocol. > > Are you trying to re-invent FRF8.1 !!! > If you look at the draft closely, it says that for full ATM-FR > interworking, standard FR8.1 is recommended by extending one PW to > another side. And for the sub-set one can use the two-PW scheme. Also > if one wanted to use multi-protocol PW, then GRE-based PID is > sufficient since if you take a look at the FRF8.1, the LLC/SNAP field > for the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is fixed and > thus you don't need to send them over the PW each time. MA> In fact, we made sure that most protocols required only a single word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC Types and Private Protocols) add a SNAP field and thus a 2-word multiprotocol header. > >What I would like to propose to Ali is to separate out the > >encapsulation and signaling from his draft such that we progress the > >work here in PWE3 (assuming the charter is modified). The other > >interworking aspects in his draft can be progressed in the l2vpn WG. > > As I mentioned, at this point I think the use of multiple PWs is > sufficient and if it is shown that a new multi-protocol PW is needed, > then still I think GRE-based is both sufficient and efficient since we > don't want to add a fixed LLC/SNAP header to each packet knowing that > 99% of them don't require it !!! MA> Where do you see LLC/SNAP in my draft?? > -Ali > > >Thanks for the interesting exchange. > > > >Mustapha. > >----------- _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: PWE3 WG Meeting IETF-57, Wed 16th July 2003 - minutes Date: Wed, 06 Aug 2003 11:38:43 +0100 Organization: Cisco Systems, Inc. Lines: 457 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Aug 06 12:40:10 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: minutes@ietf.org, "pwe3@ietf.org" 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 PWE3 WG Meeting IETF-57, Wed 16th July 2003 =========================================== Chairs: Stewart Bryant and Danny McPherson Minutes take by: Matthew Bocci "Danny McPherson" WG Document Status ------------------ There has been good progress on Requirements and Architecture drafts. Intend to send both to IESG next week. After this, most services stuff can proceed. The intention is to wrap up a lot of the stuff in 3 or 4 months. There are some issues with Frame Relay which will hold it up a bit. Authors should clean up docs to deal with ID nits before progressing them. "Thomas Narten" PWE3 move to Internet Area -------------------------- Thomas is Internet Area co-AD. There is a plan to transition PWE3 to the Internet Area. PPVPN has been split into L2 and L3 VPN. We should bring PWE3 into the same area (L2TPv3 extensions is here too). Reason: It is arguable which area, but this is all related to tunneling. Transport originally took it because of congestion control issues. Transition will occur when architecture and requirements are done. "Thomas Nadeau" tnadeau@cisco.com http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-01.txt ----------------------------------------------------------------- Rahul Aggarwal Juniper Juniper, presented VCCV update. This stands for Virtual Circuit Connection Verification. Capabilities: Inband MPLS VCCV, Router alert label. Changes in v1: Inband MPLS VCCV: Message indicated in data flow by using first nibble of PW control header: 0001 LS 16 bits specify protocol no. Router alert used to indicate an OAM flow Changes for L2TPv3: VCCV verifies session forwarding state at egress PE. Encodes LSP ping header. Message types are listed. 2 Reply modes: Contains L2 circuit ID OAM capability must be signaled before a PE may send OAM messages. The presenter lists the cases for MPLS, L2TPv3 as PSN. VCCV control channel indicated by receiving PE. Should L2 circuit ID be in LSP PING spec, OAM capability advertisement: where should this be defined? The presenter request that this be made a WG document Sasha Vainshtein: What should happen with PWs that by default do not use CW? Rahul Aggarwal: still possible to use router alert label. If you want Luca Martini: supports this, but more belongs here. Might belong somewhere else. Rahul Aggarwal: why? Several issues related to PWs. Capability advertisement, open to what WG wants. Luca: Could limit it in this draft George Swallow: If you think your objects belong in MPLS, send them over MPLS Mustapha Aissaoui (Alcatel): What about MPLS payload ID? George Swallow: We define IP control channel associated with PWE3 circuit. and put IP in code point. Mustapha Aissaoui: OK, but we are using MPLS PID in Arch document, not CW. Must get terminology right. It is PW PID, not control word. Rahul Aggarwal: OK, get the same picture. Rough consensus was tested and there was majority support to accept the document as a WG draft. This support to be further tested by asking the list. "Mustapha Aissaoui" http://www.ietf.org/internet-drafts/draft-aissaoui-extended-pid-00.txt ----------------------------------------------------------------------- Presenter describes MPLS PID in architecture doc. Allows multiple user plane protocols in same PW. PW PID can be used for control plane to ID control channel. Allows different control planes, (LSP PING, Y.1711, etc). Also resolves OAM packets sharing path of user packets in case of ECMP. Allows interworking of different link layers over MPLS network. This is not an alternative to current paradigm. Does not require PID. Shows example application. GigE link through MPLS to FR VC Could extend FR to remote PE across MPLS. Issues: remote PE would have to understand FR over MPLS Could terminate FR VC on PE, and create multiple PWs, one for each payload type. 3rd option, to do PID translation between FR, PW, and Ethernet. This is addressed here. Most straightforward option is to use PW PID. But, Used value of 0001 for first nibble, and removed alert bit. Relationship between CW and PID: precedes PW CW in architecture Proposal is to reverse this to use the control word to consistently solve IP aliasing issue. No major other issues. Would like to keep current order of PID and CW as in architecture draft. Would like to progress this in PWE3. Yakov Stein: Understand, and it is a good idea, but looks like service interworking. Trying to not use this word. Mustapha Aissaoui: Had thought about this issue. Key point is that we have an issue to solve. I believe this is part of PWE3 because it allows migration of existing installed base. Luca Martini: why do you need PW ID, when you could use a simple label? Mustapha Aissaoui: that is the second option above. You must assign a label for each protocol type. Issue is that for each FR VC, you must have multiple PWs Luca Martini: must still do the lookup for forwarding. This makes hardware complex. Mustapha Aissaoui: translating PID is straightforward. You do this if you support FR over ATM. George Swallow: It's not the right hand side that does translation. Don't want to force other side to know what protocol is. Luca's point is that you can do this from label context. Mustapha Aisasoui: not sufficient Danny McPherson: take to mailing list as this is a new charter item. Ali Sajassi: not as simple as a PW ID. There is a dependency of L3 over L2 medium. Need to be careful. My draft suggests IP PW and then all non IP to used bridged encap. Need to look at bigger picture. Sasha Vainshtein: draft-sharc-arp-mediation describes a solution "Dave Allan" http://www.ietf.org/internet-drafts/draft-allan-mpls-a-bit-00.txt ----------------------------------------------------------------- This was presented in MPLS yesterday. It has implications for PWE3 and MPLS. MPLS aspects will be discussed on list. Recast today to illustrate thought process that lead to solution, and make clear why we got here. Motivation: MPLS reserve label functions don't fate share with associated LSPs/PWs in presence of ECMP. Directions in proactive network supervision complicate fault detection. Faults can be simultaneously detected by multiple uncoordinated means. Fault correlation is an issue. Need to increase locality of detection. One way is for probes to examine OAM flows. MPLS router alert has limitations. Use of label stacking for demarcation has limitations: useful for security reasons, push testing as close to CE as possible, ability to do OAM on a portion of an LSP. In Dave's opinion, there is a progressive divergence of PWs and LSPs. Driving commonality has utility. Multi-hop or spliced LSPs may require more commonality. PID perceived as a point of commonality between PWs and MPLS. Allows control and OAM flows to be muxed with PWs/LSPs. A bit proposal is about migrating reserved label functions to PID. Diagram shows the position of the A-bit. This is a Data Plane change: issues with b/w compatibility. E.g. what if payload aliases with an RA. In summary: ECMP breaks reserve labels. Reserved labels do not exists for PWs. PID+A George Swallow: no problem with ECMP. Should not use ECMP if you need ordering. That's what you get. Dave Allan: What about problem statements George Swallow: Happy to use TTL Rahul Aggarwal: Not clear what problem we are trying to solve. ECMP works just fine. Reserved labels in MPLS are used for specific purposes. Leave this alone. Dave Allan: ECMP implementations are sensitive to where reserved label is in stack. Rahul Aggarwal: use inband VCCV Dave Allan: in absence of control word, depends on implementation Rahul Aggarwal: borderline case George Swallow: do you want to put 4 bytes into header? Danny McPherson: Take to list Overview of Y.17iw Dave Allan http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt --------------------------------------------------------------------- Put in as information on ITU work on OAM interworking. May be of utility. Scope of Y.17iw. Interworking of I.610 and Y.1711 in network interworking and service interworking scenarios. Approach is not to try and interwork OAM protocols , but instead to use 'trigger state'. Summarizes actions if PW breaks in ATM over MPLS. Applicability: directly applicable to encapsulations for ATM over M PLS here, where Y.1711 and ATM OAM is properly supported. Also shows applicability to service interworking i.e. ATM and MPLS peers. Similar or OAM interworking in FRF.8 Work in progress. Proposed for consent at July SG13 meeting. "Sasha Vainshtein" http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt ------------------------------------------------------------------- Presents some of the discussion. First presented at IETF-52. Evolved in mean time to cover additional functionality and remove restrictions. Aligned with WG charter, requirements, architecture, TDM PW requirements, RFC 2736, and SONET emulation draft. Summary of updates: Requested to adopt as a WG draft as the basis for further WG work posted in June 03. 4 successful interop tests. Few technical issues remain. No conceptual objections to unstructured services: draft-stein-pwe3-stpp-00. Specific technical issues: non ECMP compliant control word, because it is aligned with SONET. Technically possible to use control word : sufficient flags (4 flags needed), sufficient sequence number space, use fragmentation bits for splitting basic structures of trunk specific Nx64 Second issue: Usage of RTP header. Minor issues: default packet latency of unstructured E1, Frame alignment for unstructured services, ?. Danny McPherson: presentation in a few minutes will affect this, so hold off for progression discussion. "Yaakov Stein" http://www.ietf.org/internet-drafts/draft-stein-pwe3-stpp-00.txt ---------------------------------------------------------------- Simple TDM Pseudo-Wire Protocol Draft-anavi first presented at 50th IETF. Several compromises reached and rejected. Multiple main modes for special cases. These are there for good reason. Also, various special mechanisms for clock recovery etc. Simple interworking with existing AAL1/2 networks. Claimed draft-Vainshtein has evolved into a long and complex draft. Single main mode with plethora of sub-modes. STPP was supposed to be a 'dumb' draft. Draft is only 11 pages, readable by non-TDMers. Designed to cover common TDM cases. Simply encapsulate arbitrary length TDM packets. No special payload treatment, and highest possible b/w efficiency. Proposal: accept STPP for most common (simplest) TDM cases: broad support, easy to implement. Accept TDMoIP and CESoPSN for special cases. Sasha Vainshtein: You listed four issues. Packet loss concealment is the only one that has been addressed I a draft. Yaakov Stein: No. Loss avoidance has been covered as well. "Danny McPherson" "Stewart Bryant" Discussion: Getting Traction on TDM ------------------------------------ Put together as a result of lots of consideration by chairs. TDM is the long pole test. Every encap except TDM has pretty firm. TDM Unstructured TDM consensus is plausible. However, structured consensus is difficult and as far away as ever. 2 problems: commercial interests, and not enough TDM experts in IETF Chairs cannot allow TDM work to continue to defocus group 4 options: draft-Vainshtein goes to WG, and draft-anavi becomes informational. Or draft-anavi goes to WG, and draft-vainshtein becomes informational. But, not clear consensus which way to go. Could remove structured work, in which case this would cease and we would pick one of the unstructured approaches from the draft. Structured approached become informational. Alternatively, drop TDM altogether. Draft-stein-pwe3-stpp-00.txt is the only current draft. Short. May need RTP support. Could take draft Vainshtein unstructured as alternate starting point. Decision: Chairs pick a neutral editor to pick best of both. Split structured and unstructured work. Editor to take it forward. Yakov Stein: other possibility is to make one common draft that we can agree on. No issues with STPP, issue is wording, so perhaps we could consider a short time frame of one month to do this. Tim Fross: unstructured draft is fine whichever. Structured drafts will have to be rewritten, so as a refinement to chairs approach, rewrite draft-stein and draft-anavi with just unstructured and then have WG run off. Tim Fross: unstructured draft is fine whichever. Structured drafts will have to be rewritten. I support the chairs suggestion of progressing the structured versions of draft-vainshtein and draft-anavi as informational. Yakov Stein: lack of support for either draft is not the problem. Agrees we should remove unstructured portions out, clean up. Stewart: About time we stopped the beauty contest. Time to stop it. Concerned about RTP should it be dropped off? Yakov Stein: no problem with RTP as an option for whoever wants it. Danny McPherson: Sasha & Yakov to get back to chairs on this and come up with unstructured draft. Need to see something by Sept 1st. Sasha Vainshtein: Agree with proposal for split to structured and unstructured and will produce something in around one month. Stewart Bryant: The chairs will look for some one to edit unstructured draft after September, if we need to. Sasha Vainshtein: tight timetable is reasonable. Outcome: 1) Yaakov Stein and Sasha Vainshtein agreed to produce a joint unstructured draft by 1st September 2) WG Chairs will hold off seeking neutral editor unless this effort fails 3) Yaakov Stein and Sasha Vainstein invited to re-present their structured work as individual drafts. Luca Martini draft-ietf-pwe3-control-protocol-03.txt ---------------------------------------- Rewritten ATM Oam procedures. Added status TLV section. Updated diagrams. More work? Add clarification to generalized FEC? Could do in PPVPN. Would like to go for last call after next revisions. draft-ietf-pwe3-ethernet-encap-03.txt Stable for a long time and would like to go for last call. draft-ietf-pwe3-iana-allocation-01.txt Cleaned up some allocation conflicts, and added PW status TLV bit allocations. Should I rewrite the status TLV? Sahsa V: assuming unstructured TDM will be done soon, can we have PW types for this included? Stewart: assume this is a convenient method for talking to IANA? Luca Martini: Yes. Will put allocations in. Danny: good, we have progress for some things to last call. draft-ietf-pwe3-atm-encap-02.txt This is a major revision. Consolidated applicability statements and control word. Updated OAM. Aligned control word with architecture draft. Other list of updates. Should be ready to go for last call. Stewart: does this align with ITU Recommendation? Luca: yes. No major technical change. "Himanshu Shah" draft-shah-pwe3-control-protocol-extension-01.txt ------------------------------------------------- Extension to control protocol for dynamic parameter signaling. Draft proposes mechanism for 2 PEs to exchange attributes without tearing down the PW. E.g. IP address for ARP mediation, and IP+MAC for IPLS. Claims simple and easy and easy to implement. PEs learn each others capability for exchanging dynamically. Dynamic signaling: two methods to signal updates to PW attributes without withdrawing the FEC. Both methods work, but draft recommends LDP notification message. Would like feedback from WG. Shows example of PW status signaling., but other attributes can be exchanged e.g. IP address TLV, IP+MAC address TLV, etc. Conclusion: need generic mechanism to extend signaling in backward compatible fashion to include capability signaling. Requests draft adopted as WG item. Sasha Vainshtein: this mechanism would be very helpful in solving congestion detection problem. Would like to support this draft. Also resolves issue of ARP mediation, where you cannot Luca Martini: Status indication is already in control draft. Other TLVs are all useful and should be defined. Question is where? Doesn't necessarily fit in control draft You are proposing list of parameters for PW. Most useful for VPLS. H.Shah: not limited to VPLS Luca Martini: we can do the agreeable parts if there is another interest on the mailing list. Hamid Ould-Brahim: additions are just a particular provisioning model. Signaling capability is an important aspect. Luca Martini: that's why we have L2VPN WG. Danny: take to the list. Ali Sajassi: good to have this mechanism, but TLVs are not right for PWE3. Stewart: continue on list, and decide which parts to take in PWE3 "Ghassem Koleyni" Update on activities in ITU-T SG13 regarding interworking topics ---------------------------------------------------------------- Update on what is happening on Q5 of SG13. Shows the general network interworking model. Two Recommendations will be published: cell mode and frame mode. Cell mode has two modes: N-to-one and one-to-one. Aligned with IETF and ATM forum. Thanks all authors. Frame mode document (AAL5 PDU mode and SDU mode) expected to go for consent at July SG13 meeting. Other topics: FR-MPLS network interworking, TDM-MPLS network interworking, voice services over MPLS, and general service interworking where networks either side of MPLS core are dissimilar. Have started to work on requirements for ATM-MPLS-FR. OAM aspects are jointly handled by Q5 and Q3. Andy Malis: suggest SG13 should follow SG17 work on X.84 on FR interworking. Andy Malis: Work here in FR interworking has been kept aligned with SG17 work. Ghassem Koleyni: need as much synergy as possible if multiple parties work on the same draft. Stewart: would like to receive contribution drafts on how to tackle congestion. MEETING CLOSES From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: PWE3 and Congestion Date: Wed, 06 Aug 2003 13:09:49 +0100 Organization: Cisco Systems, Inc. Lines: 24 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Aug 06 14:11:07 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "pwe3@ietf.org" 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 One of the PWE3 work areas that has gained scant attention is congestion. The particular concern of IESG is that PW traffic that transits the Internet should not behave badly WRT TCP traffic. There is some text in the arch draft, but this is really only a place holder for more considered work. One solution that has been mooted is to require a migration of PWE3 to DCCP, however I would imagine that the WG would prefer to find a solution that allows us to maintain our current investment in encapsulation technologies. At the last IETF I picked up an action to make the PWE3 WG aware that this was an area that needed greater attention and to encourage a design team to form to work on this. If anyone is interested in working an a congestion solution for PWE3, please contact Danny and myself. Better still if anyone has any technical proposals, then please can they submit them to the WG. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 06 Aug 2003 09:09:53 -0400 Organization: Alcatel Networks Corporaton Lines: 104 Sender: pwe3-admin@ietf.org References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5F66@trimail2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Aug 06 15:11:02 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Serbest, Yetik" 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 Yetik, the word "adamant" is maybe strong. I heard a couple of issues: CPE/CLE capabilities is one of them indeed. The other one is related to the change of configuration required on many of the existing sites. In any case, whether a bridge encapsulation is used or not is orthogonal to the the way a FR VC is interworked with a point-to-point Ethernet interface. The main issue is how to carry multiple user payloads across FR-VC to PW to Ethernet interface. Regards, Mustapha. ----------- "Serbest, Yetik" wrote > Why are your customers so adamant on not changing their encapsulations? Is > it because their CPE does not support bridged encapsulations (like old > FRADs)? > > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Tuesday, August 05, 2003 8:47 AM > To: Ali Sajassi > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > Ali, > > Ali Sajassi wrote: > > > > At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote: > > >Eric, > > >draft-sajassil2vpn-interworking-01.txt has a wider scope than mine > > >since it goes into some of the details of the interworking. In terms > > >of the encapsulation, Ali > > >proposes to use the PID field similar to the one used in GRE > encapsulation. > > > > The draft discusses two approaches: > > a) using multiple PWs > > b) using multi-protocol PW > > > > and discusses the pros/cons of each. It also clearly states an example > > where the user can just get away with just two PWs for multi-protocol > > support (one for IP and another for non-IP based on Ethernet/bridged > > encap) by configuring IP traffic as routed and all other non-IP > > traffic as bridged encap. > > > > At this point, I think the multiple PWs scheme is sufficient - one for > > IP and the other for non-IP traffic which is bridged encapsulated. And > > we don't need to define a new multi-protocol PW unless it is shown > > otherwise. > > MA> I have issues with the 1-N VC-to-PW which I described in my > earlier emails. Furthermore, I do not expect all my customers to go and > change their encapsulations in their many sites to bridged type unless > absolutely required. > > > >The reason why this is not sufficient is because many protocols are > > >carried in RFC 2427 and 2684 by appending the organization unique > > >identifier (OUI) to the payload. This is certainly the case of the > > >IEEE 802.1 MAC types and private organization protocols. When Andy > > >and I looked into the best way to structure the PID, we wanted to > > >make sure we continue to support these and to limit the number of > > >combinations possible to represent a single protocol. > > > > Are you trying to re-invent FRF8.1 !!! > > If you look at the draft closely, it says that for full ATM-FR > > interworking, standard FR8.1 is recommended by extending one PW to > > another side. And for the sub-set one can use the two-PW scheme. Also > > if one wanted to use multi-protocol PW, then GRE-based PID is > > sufficient since if you take a look at the FRF8.1, the LLC/SNAP field > > for the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is fixed and > > thus you don't need to send them over the PW each time. > > MA> In fact, we made sure that most protocols required only a single > word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, ESIS, and > CLNP. Only those protocols which require a OUI (e.g., MAC Types and Private > Protocols) add a SNAP field and thus a 2-word multiprotocol header. > > > >What I would like to propose to Ali is to separate out the > > >encapsulation and signaling from his draft such that we progress the > > >work here in PWE3 (assuming the charter is modified). The other > > >interworking aspects in his draft can be progressed in the l2vpn WG. > > > > As I mentioned, at this point I think the use of multiple PWs is > > sufficient and if it is shown that a new multi-protocol PW is needed, > > then still I think GRE-based is both sufficient and efficient since we > > don't want to add a fixed LLC/SNAP header to each packet knowing that > > 99% of them don't require it !!! > > MA> Where do you see LLC/SNAP in my draft?? > > > -Ali > > > > >Thanks for the interesting exchange. > > > > > >Mustapha. > > >----------- > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Serbest, Yetik" Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 6 Aug 2003 08:56:19 -0500 Lines: 126 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Aug 06 15:57:09 2003 Return-path: To: "'Mustapha Aissaoui'" , "Serbest, Yetik" 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 You raised that issue as a reason. What is the degree of configuration change you accept? To make OSPF work properly you have to configure the Ethernet interface as point-point. For IS-IS, extended PID does not work. Are you going to ask your customers to use OSPF? Ali's proposal is architecturally more sound to me. In addition, I really don't think the amount of work to be done by a PE is that different in both cases, i.e., extended PID vs. multiple VCs. Thanks, yetik -----Original Message----- From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] Sent: Wednesday, August 06, 2003 8:10 AM To: Serbest, Yetik Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 Yetik, the word "adamant" is maybe strong. I heard a couple of issues: CPE/CLE capabilities is one of them indeed. The other one is related to the change of configuration required on many of the existing sites. In any case, whether a bridge encapsulation is used or not is orthogonal to the the way a FR VC is interworked with a point-to-point Ethernet interface. The main issue is how to carry multiple user payloads across FR-VC to PW to Ethernet interface. Regards, Mustapha. ----------- "Serbest, Yetik" wrote > Why are your customers so adamant on not changing their > encapsulations? Is it because their CPE does not support bridged > encapsulations (like old FRADs)? > > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Tuesday, August 05, 2003 8:47 AM > To: Ali Sajassi > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > Ali, > > Ali Sajassi wrote: > > > > At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote: > > >Eric, > > >draft-sajassil2vpn-interworking-01.txt has a wider scope than mine > > >since it goes into some of the details of the interworking. In > > >terms of the encapsulation, Ali proposes to use the PID field > > >similar to the one used in GRE > encapsulation. > > > > The draft discusses two approaches: > > a) using multiple PWs > > b) using multi-protocol PW > > > > and discusses the pros/cons of each. It also clearly states an > > example where the user can just get away with just two PWs for > > multi-protocol support (one for IP and another for non-IP based on > > Ethernet/bridged > > encap) by configuring IP traffic as routed and all other non-IP > > traffic as bridged encap. > > > > At this point, I think the multiple PWs scheme is sufficient - one > > for IP and the other for non-IP traffic which is bridged > > encapsulated. And we don't need to define a new multi-protocol PW > > unless it is shown otherwise. > > MA> I have issues with the 1-N VC-to-PW which I described in my > earlier emails. Furthermore, I do not expect all my customers to go > and change their encapsulations in their many sites to bridged type > unless absolutely required. > > > >The reason why this is not sufficient is because many protocols are > > >carried in RFC 2427 and 2684 by appending the organization unique > > >identifier (OUI) to the payload. This is certainly the case of the > > >IEEE 802.1 MAC types and private organization protocols. When Andy > > >and I looked into the best way to structure the PID, we wanted to > > >make sure we continue to support these and to limit the number of > > >combinations possible to represent a single protocol. > > > > Are you trying to re-invent FRF8.1 !!! > > If you look at the draft closely, it says that for full ATM-FR > > interworking, standard FR8.1 is recommended by extending one PW to > > another side. And for the sub-set one can use the two-PW scheme. > > Also if one wanted to use multi-protocol PW, then GRE-based PID is > > sufficient since if you take a look at the FRF8.1, the LLC/SNAP > > field for the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is > > fixed and thus you don't need to send them over the PW each time. > > MA> In fact, we made sure that most protocols required only a single > word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, > ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC > Types and Private > Protocols) add a SNAP field and thus a 2-word multiprotocol header. > > > >What I would like to propose to Ali is to separate out the > > >encapsulation and signaling from his draft such that we progress > > >the work here in PWE3 (assuming the charter is modified). The other > > >interworking aspects in his draft can be progressed in the l2vpn > > >WG. > > > > As I mentioned, at this point I think the use of multiple PWs is > > sufficient and if it is shown that a new multi-protocol PW is > > needed, then still I think GRE-based is both sufficient and > > efficient since we don't want to add a fixed LLC/SNAP header to each > > packet knowing that 99% of them don't require it !!! > > MA> Where do you see LLC/SNAP in my draft?? > > > -Ali > > > > >Thanks for the interesting exchange. > > > > > >Mustapha. > > >----------- > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 06 Aug 2003 10:20:47 -0400 Organization: Alcatel Networks Corporaton Lines: 146 Sender: pwe3-admin@ietf.org References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5F6A@trimail2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Aug 06 16:22:07 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Serbest, Yetik" 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 Yetik, the IS-IS example I have shown in my presentation in Vienna was not for an enterprise type network. It was for an ISP buying PoP connectivity through another service provider. There is a way to make IS-IS work without a bridged encapsulation. It is described in Section 9.3.1.1 of draft-lee-ppvpn-hybrid-vpls-01.txt. Again, whether you perform a PID translation or multiple PWs is orthogonal to how IS-IS is carried. Even if you use bridge encapsulation for IS-IS, you are dealing with a FR VC carrying multiple payloads (IP routed and IS-IS bridged). Regards, Mustapha. ----------- "Serbest, Yetik" wrote: > You raised that issue as a reason. What is the degree of configuration > change you accept? To make OSPF work properly you have to configure the > Ethernet interface as point-point. For IS-IS, extended PID does not work. > Are you going to ask your customers to use OSPF? Ali's proposal is > architecturally more sound to me. In addition, I really don't think the > amount of work to be done by a PE is that different in both cases, i.e., > extended PID vs. multiple VCs. > > Thanks, > yetik > > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, August 06, 2003 8:10 AM > To: Serbest, Yetik > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > Yetik, > the word "adamant" is maybe strong. I heard a couple of issues: CPE/CLE > capabilities is one of them indeed. The other one is related to the change > of configuration required on many of the existing sites. > > In any case, whether a bridge encapsulation is used or not is orthogonal to > the the way a FR VC is interworked with a point-to-point Ethernet interface. > The main issue is how to carry multiple user payloads across FR-VC to PW to > Ethernet interface. > > Regards, > Mustapha. > ----------- > "Serbest, Yetik" wrote > > > Why are your customers so adamant on not changing their > > encapsulations? Is it because their CPE does not support bridged > > encapsulations (like old FRADs)? > > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Tuesday, August 05, 2003 8:47 AM > > To: Ali Sajassi > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > > > Ali, > > > > Ali Sajassi wrote: > > > > > > At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote: > > > >Eric, > > > >draft-sajassil2vpn-interworking-01.txt has a wider scope than mine > > > >since it goes into some of the details of the interworking. In > > > >terms of the encapsulation, Ali proposes to use the PID field > > > >similar to the one used in GRE > > encapsulation. > > > > > > The draft discusses two approaches: > > > a) using multiple PWs > > > b) using multi-protocol PW > > > > > > and discusses the pros/cons of each. It also clearly states an > > > example where the user can just get away with just two PWs for > > > multi-protocol support (one for IP and another for non-IP based on > > > Ethernet/bridged > > > encap) by configuring IP traffic as routed and all other non-IP > > > traffic as bridged encap. > > > > > > At this point, I think the multiple PWs scheme is sufficient - one > > > for IP and the other for non-IP traffic which is bridged > > > encapsulated. And we don't need to define a new multi-protocol PW > > > unless it is shown otherwise. > > > > MA> I have issues with the 1-N VC-to-PW which I described in my > > earlier emails. Furthermore, I do not expect all my customers to go > > and change their encapsulations in their many sites to bridged type > > unless absolutely required. > > > > > >The reason why this is not sufficient is because many protocols are > > > >carried in RFC 2427 and 2684 by appending the organization unique > > > >identifier (OUI) to the payload. This is certainly the case of the > > > >IEEE 802.1 MAC types and private organization protocols. When Andy > > > >and I looked into the best way to structure the PID, we wanted to > > > >make sure we continue to support these and to limit the number of > > > >combinations possible to represent a single protocol. > > > > > > Are you trying to re-invent FRF8.1 !!! > > > If you look at the draft closely, it says that for full ATM-FR > > > interworking, standard FR8.1 is recommended by extending one PW to > > > another side. And for the sub-set one can use the two-PW scheme. > > > Also if one wanted to use multi-protocol PW, then GRE-based PID is > > > sufficient since if you take a look at the FRF8.1, the LLC/SNAP > > > field for the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is > > > fixed and thus you don't need to send them over the PW each time. > > > > MA> In fact, we made sure that most protocols required only a single > > word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, > > ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC > > Types and Private > > Protocols) add a SNAP field and thus a 2-word multiprotocol header. > > > > > >What I would like to propose to Ali is to separate out the > > > >encapsulation and signaling from his draft such that we progress > > > >the work here in PWE3 (assuming the charter is modified). The other > > > >interworking aspects in his draft can be progressed in the l2vpn > > > >WG. > > > > > > As I mentioned, at this point I think the use of multiple PWs is > > > sufficient and if it is shown that a new multi-protocol PW is > > > needed, then still I think GRE-based is both sufficient and > > > efficient since we don't want to add a fixed LLC/SNAP header to each > > > packet knowing that 99% of them don't require it !!! > > > > MA> Where do you see LLC/SNAP in my draft?? > > > > > -Ali > > > > > > >Thanks for the interesting exchange. > > > > > > > >Mustapha. > > > >----------- > > > > _______________________________________________ > > 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:45 2006 From: Ali Sajassi Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 06 Aug 2003 14:57:42 -0700 Lines: 84 Sender: pwe3-admin@ietf.org References: <200307281748.h6SHm0MK004642@rtp-core-1.cisco.com> <4.3.2.7.2.20030731072108.02566ce0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Aug 07 00:09:10 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mustapha Aissaoui , Ali Sajassi In-Reply-To: <3F2FB54E.3B8C85FD@alcatel.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 > > The draft discusses two approaches: > > a) using multiple PWs > > b) using multi-protocol PW > > > > and discusses the pros/cons of each. It also clearly states an example > > where the user can just get away with just two PWs for multi-protocol > > support (one for IP and another for non-IP based on Ethernet/bridged encap) > > by configuring IP traffic as routed and all other non-IP traffic as bridged > > encap. > > > > At this point, I think the multiple PWs scheme is sufficient - one for IP > > and the other for non-IP traffic which is bridged encapsulated. And we > > don't need to define a new multi-protocol PW unless it is shown otherwise. > >MA> I have issues with the 1-N VC-to-PW which I described in my >earlier emails. Furthermore, I do not expect all my customers to go >and change their encapsulations in their many sites to bridged type >unless absolutely required. If the issue is with notification of far-end AC and/or the reflection of AC status into PWs and vise versa, then this can be done in a number of ways (either through the use of control plane or data plane). And when talking about interworking of different protocols over the disparate ACs, then it is important to note that it is not simply just the question of encapsulation and PID. Furthermore, your customers probably will be willing to change the config in some of their sites than risking their protocols not working at all :-) > > > >The reason why this is not sufficient is because many protocols are > carried in > > >RFC 2427 and 2684 by appending the organization unique identifier > (OUI) to the > > >payload. This is certainly the case of the IEEE 802.1 MAC types and > private > > >organization protocols. When Andy and I looked into the best way to > structure > > >the PID, we wanted to make sure we continue to support these and to > limit the > > >number of combinations possible to represent a single protocol. > > > > Are you trying to re-invent FRF8.1 !!! > > If you look at the draft closely, it says that for full ATM-FR > > interworking, standard FR8.1 is recommended by extending one PW to another > > side. And for the sub-set one can use the two-PW scheme. > > Also if one wanted to use multi-protocol PW, then GRE-based PID is > > sufficient since if you take a look at the FRF8.1, the LLC/SNAP field for > > the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is fixed and thus you > > don't need to send them over the PW each time. > >MA> In fact, we made sure that most protocols required only a single >word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, >ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC >Types and Private Protocols) add a SNAP field and thus a 2-word >multiprotocol header. I would encourage you to go over different scenarios for disparate ACs and try to see: a) what are all different protocols that can be carried over them b) what are the dependencies of these protocol to underlying L2 media c) how can you interwork these different protocols d) what is the common denominator approach among them Once you do that, you can see that there are more issues than just defining a PID. So in short, before requiring a Multi-protocol PW, the need for such PW needs to be clearly justified in the context of the applicable scenarios. At this point, I think the existing PWs plus the addition of IP PW should be enough unless it is shown otherwise. > > > As I mentioned, at this point I think the use of multiple PWs is sufficient > > and if it is shown that a new multi-protocol PW is needed, then still I > > think GRE-based is both sufficient and efficient since we don't want to add > > a fixed LLC/SNAP header to each packet knowing that 99% of them don't > > require it !!! > >MA> Where do you see LLC/SNAP in my draft?? I guess it was your colleague Jeremy who at one point proposing that :-) -Ali > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Ali Sajassi Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Thu, 07 Aug 2003 11:11:30 -0700 Lines: 46 Sender: pwe3-admin@ietf.org References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5F66@trimail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Aug 07 20:13:08 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mustapha Aissaoui , "Serbest, Yetik" In-Reply-To: <3F30FE21.FCB9494D@alcatel.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 At 09:09 AM 8/6/2003 -0400, Mustapha Aissaoui wrote: >Yetik, >the word "adamant" is maybe strong. I heard a couple of issues: CPE/CLE >capabilities is one of them indeed. The other one is related to the change of >configuration required on many of the existing sites. The point is that, there are scenarios that you have to do configuration changes anyway such as CEs running OSPF. So if you have to do config changes at the CEs, you may want to do it such that you get the biggest bang for the buck and support all the different protocols running at the CE. >In any case, whether a bridge encapsulation is used or not is orthogonal >to the >the way a FR VC is interworked with a point-to-point Ethernet interface. The >main issue is how to carry multiple user payloads across FR-VC to PW to >Ethernet >interface. They are related because if you do bridged encapsulation, then with a single EoPW you can carry all theL3 protocols over it and you don't need to have different PWs for different L3 protocol and worry about the dependence of these protocols on underlying L2 media. For certain scenarios, you can assign a dedicated PW to IP traffic and another one to all other which means you will have two but not more than that :-) At 10:20 AM 8/6/2003 -0400, Mustapha Aissaoui wrote: >Yetik, >the IS-IS example I have shown in my presentation in Vienna was not for an >enterprise type network. It was for an ISP buying PoP connectivity through >another service provider. There is a way to make IS-IS work without a bridged >encapsulation. It is described in Section 9.3.1.1 of >draft-lee-ppvpn-hybrid-vpls-01.txt. You can see from this section that how messy it is getting. Now the PE not only needs to do ARP mediation but also it needs to do snooping of different messages and intercept/generate different IS-IS messages. I guess, one can claim that IS-IS hello messages can also be snooped, intercepted, and modified to please the endpoints but at what price and complexity. And just remember, you have to do this for every protocol that has procedural dependency on L2 interfaces if you don't want to touch the CE. If one wants to go to that extend, then he is probably better off with just peering with the CE and use a hybrid of L3VPN and L2VPN as described in the last section of my draft. -Ali From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Serbest, Yetik" Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Fri, 8 Aug 2003 08:44:57 -0500 Lines: 164 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Aug 08 15:46:09 2003 Return-path: To: "'Mustapha Aissaoui'" , "Serbest, Yetik" 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 As far as I can tell, what you point me to can not work for ISIS, right? Because ATM/FR side does not include MAC address in its Hello PDU. So, there is no way to proxy ARP. Am I missing something? Thanks, Yetik -----Original Message----- From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] Sent: Wednesday, August 06, 2003 9:21 AM To: Serbest, Yetik Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 Yetik, the IS-IS example I have shown in my presentation in Vienna was not for an enterprise type network. It was for an ISP buying PoP connectivity through another service provider. There is a way to make IS-IS work without a bridged encapsulation. It is described in Section 9.3.1.1 of draft-lee-ppvpn-hybrid-vpls-01.txt. Again, whether you perform a PID translation or multiple PWs is orthogonal to how IS-IS is carried. Even if you use bridge encapsulation for IS-IS, you are dealing with a FR VC carrying multiple payloads (IP routed and IS-IS bridged). Regards, Mustapha. ----------- "Serbest, Yetik" wrote: > You raised that issue as a reason. What is the degree of configuration > change you accept? To make OSPF work properly you have to configure > the Ethernet interface as point-point. For IS-IS, extended PID does > not work. Are you going to ask your customers to use OSPF? Ali's > proposal is architecturally more sound to me. In addition, I really > don't think the amount of work to be done by a PE is that different in > both cases, i.e., extended PID vs. multiple VCs. > > Thanks, > yetik > > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, August 06, 2003 8:10 AM > To: Serbest, Yetik > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > Yetik, > the word "adamant" is maybe strong. I heard a couple of issues: > CPE/CLE capabilities is one of them indeed. The other one is related > to the change of configuration required on many of the existing sites. > > In any case, whether a bridge encapsulation is used or not is > orthogonal to the the way a FR VC is interworked with a point-to-point > Ethernet interface. The main issue is how to carry multiple user > payloads across FR-VC to PW to Ethernet interface. > > Regards, > Mustapha. > ----------- > "Serbest, Yetik" wrote > > > Why are your customers so adamant on not changing their > > encapsulations? Is it because their CPE does not support bridged > > encapsulations (like old FRADs)? > > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Tuesday, August 05, 2003 8:47 AM > > To: Ali Sajassi > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > > > Ali, > > > > Ali Sajassi wrote: > > > > > > At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote: > > > >Eric, > > > >draft-sajassil2vpn-interworking-01.txt has a wider scope than > > > >mine since it goes into some of the details of the interworking. > > > >In terms of the encapsulation, Ali proposes to use the PID field > > > >similar to the one used in GRE > > encapsulation. > > > > > > The draft discusses two approaches: > > > a) using multiple PWs > > > b) using multi-protocol PW > > > > > > and discusses the pros/cons of each. It also clearly states an > > > example where the user can just get away with just two PWs for > > > multi-protocol support (one for IP and another for non-IP based on > > > Ethernet/bridged > > > encap) by configuring IP traffic as routed and all other non-IP > > > traffic as bridged encap. > > > > > > At this point, I think the multiple PWs scheme is sufficient - one > > > for IP and the other for non-IP traffic which is bridged > > > encapsulated. And we don't need to define a new multi-protocol PW > > > unless it is shown otherwise. > > > > MA> I have issues with the 1-N VC-to-PW which I described in my > > earlier emails. Furthermore, I do not expect all my customers to go > > and change their encapsulations in their many sites to bridged type > > unless absolutely required. > > > > > >The reason why this is not sufficient is because many protocols > > > >are carried in RFC 2427 and 2684 by appending the organization > > > >unique identifier (OUI) to the payload. This is certainly the > > > >case of the IEEE 802.1 MAC types and private organization > > > >protocols. When Andy and I looked into the best way to structure > > > >the PID, we wanted to make sure we continue to support these and > > > >to limit the number of combinations possible to represent a > > > >single protocol. > > > > > > Are you trying to re-invent FRF8.1 !!! > > > If you look at the draft closely, it says that for full ATM-FR > > > interworking, standard FR8.1 is recommended by extending one PW to > > > another side. And for the sub-set one can use the two-PW scheme. > > > Also if one wanted to use multi-protocol PW, then GRE-based PID is > > > sufficient since if you take a look at the FRF8.1, the LLC/SNAP > > > field for the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is > > > fixed and thus you don't need to send them over the PW each time. > > > > MA> In fact, we made sure that most protocols required only a single > > word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, > > ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC > > Types and Private > > Protocols) add a SNAP field and thus a 2-word multiprotocol header. > > > > > >What I would like to propose to Ali is to separate out the > > > >encapsulation and signaling from his draft such that we progress > > > >the work here in PWE3 (assuming the charter is modified). The > > > >other interworking aspects in his draft can be progressed in the > > > >l2vpn WG. > > > > > > As I mentioned, at this point I think the use of multiple PWs is > > > sufficient and if it is shown that a new multi-protocol PW is > > > needed, then still I think GRE-based is both sufficient and > > > efficient since we don't want to add a fixed LLC/SNAP header to > > > each packet knowing that 99% of them don't require it !!! > > > > MA> Where do you see LLC/SNAP in my draft?? > > > > > -Ali > > > > > > >Thanks for the interesting exchange. > > > > > > > >Mustapha. > > > >----------- > > > > _______________________________________________ > > 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:45 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Fri, 08 Aug 2003 14:11:02 -0400 Organization: Alcatel Networks Corporaton Lines: 98 Sender: pwe3-admin@ietf.org References: <200307281748.h6SHm0MK004642@rtp-core-1.cisco.com> <4.3.2.7.2.20030731072108.02566ce0@airborne.cisco.com> <4.3.2.7.2.20030806115829.020a9d48@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Aug 08 20:12:08 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ali Sajassi 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 ALi, Ali Sajassi wrote: > > > > The draft discusses two approaches: > > > a) using multiple PWs > > > b) using multi-protocol PW > > > > > > and discusses the pros/cons of each. It also clearly states an example > > > where the user can just get away with just two PWs for multi-protocol > > > support (one for IP and another for non-IP based on Ethernet/bridged encap) > > > by configuring IP traffic as routed and all other non-IP traffic as bridged > > > encap. > > > > > > At this point, I think the multiple PWs scheme is sufficient - one for IP > > > and the other for non-IP traffic which is bridged encapsulated. And we > > > don't need to define a new multi-protocol PW unless it is shown otherwise. > > > >MA> I have issues with the 1-N VC-to-PW which I described in my > >earlier emails. Furthermore, I do not expect all my customers to go > >and change their encapsulations in their many sites to bridged type > >unless absolutely required. > > If the issue is with notification of far-end AC and/or the reflection of AC > status into PWs and vise versa, then this can be done in a number of ways > (either through the use of control plane or data plane). And when talking > about interworking of different protocols over the disparate ACs, then it > is important to note that it is not simply just the question of > encapsulation and PID. Furthermore, your customers probably will be willing > to change the config in some of their sites than risking their protocols > not working at all :-) MA> I mentioned a number of issues with the 1-to-N VC-to-PWs. Let me repeat them here for the sake of progressing the discussion: a. OAM of a single VC which paylod is split over multiple PWs has not been proven to work. b. Reflecting the status of the entire VC based on the status of individual PWs is not obvious to me. What do you do when your bridged-encap PW is down while your routed-encap PW is still up. What is the status of the FR VC? c. Transparency of the L2 service is lost. Basically this solution messes-up with the user payload. It splits user packets arbitrarily based on received FR-PID and they are received in the far-end in an arbitrary order because of the delay differential across multiple independent PWs. Unless you are thinking of building something as sophisticated as Inverser Multiplexing over ATM (IMA) or multilink Frame Relay with a per-VC sequence number mechanism that spans multiple PWs. > > > >The reason why this is not sufficient is because many protocols are > > carried in > > > >RFC 2427 and 2684 by appending the organization unique identifier > > (OUI) to the > > > >payload. This is certainly the case of the IEEE 802.1 MAC types and > > private > > > >organization protocols. When Andy and I looked into the best way to > > structure > > > >the PID, we wanted to make sure we continue to support these and to > > limit the > > > >number of combinations possible to represent a single protocol. > > > > > > Are you trying to re-invent FRF8.1 !!! > > > If you look at the draft closely, it says that for full ATM-FR > > > interworking, standard FR8.1 is recommended by extending one PW to another > > > side. And for the sub-set one can use the two-PW scheme. > > > Also if one wanted to use multi-protocol PW, then GRE-based PID is > > > sufficient since if you take a look at the FRF8.1, the LLC/SNAP field for > > > the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is fixed and thus you > > > don't need to send them over the PW each time. > > > >MA> In fact, we made sure that most protocols required only a single > >word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, > >ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC > >Types and Private Protocols) add a SNAP field and thus a 2-word > >multiprotocol header. > > I would encourage you to go over different scenarios for disparate ACs and > try to see: > a) what are all different protocols that can be carried over them > b) what are the dependencies of these protocol to underlying L2 media > c) how can you interwork these different protocols > d) what is the common denominator approach among them > Once you do that, you can see that there are more issues than just defining > a PID. > So in short, before requiring a Multi-protocol PW, the need for such PW > needs to be clearly justified in the context of the applicable scenarios. > At this point, I think the existing PWs plus the addition of IP PW should > be enough unless it is shown otherwise. MA> Going over different scenarios for disparate ACs is not a theoretical exercise to me. Each customer is a case of its own. In some cases, my customer does not know much about what his customers carry over the FR VC today (remember this FR service is a L2 transparent service). This is why the L2 dependency issues have to be resolved customer by customer. I do not think is something that can realistically be standardized. However, the PID translation and the signaling of the PW can be. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: David Watkinson Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Fri, 08 Aug 2003 14:32:42 -0400 Organization: Alcatel Canada Lines: 52 Sender: pwe3-admin@ietf.org References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5F77@trimail2> Reply-To: david.watkinson@alcatel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Mustapha Aissaoui'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Aug 08 20:33:03 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Serbest, Yetik" 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 Yetik, The issue here is how to encapsulate ISIS to carry it on PW's. Assume that the customer of the provider has a mixture of ATM routed encapsulation, FR routed encapsulation and PPP AC's running IP and ISIS only. I'll deal with adding bridged encapsulation and ethernet AC's later. There are several options: #1 - over ATM using draft-ietf-pwe3-atm-encap and service interworking FR and PPP to ATM #2 - over IP using draft-ietf-isis-wg-over-ip for the ISIS traffic. This may have to be interworked by the PE if the CE router can not support it. #3 - over Ethernet by stripping the ATM,FR,PPP and adding an 18-byte MAC header. There isn't likely going to be valid MAC addresses to use with these AC's so fake MAC addresses may be needed. #4 - over PW PID by stripping the ATM,FR,PPP and adding a 4-byte PW PID. Solution #2 is not likely to take off as this draft is not implemented by many vendors. Solution #4 seems to be the best for efficient operation. The use of a secondary PW for carrying the IP traffic is an independant decision and only makes sense when coupled with choice #3 in order to reduce bandwidth utilitization. It seems to me that the management overhead and additional signalling of dealing with an additional PW per ISIS adjacency is very expensive compared to combining them using one of the four solutions above. When adding bridged encapsulation or ethernet AC's (e.g. an ethernet AC to a FR AC), the ISIS link can be configured as point-to-point or broadcast. This configuration needs to be consistent across both CE's. When it is point-to-point (i.e. only one CE device on the ethernet end), the procedures in draft-ietf-isis-igp-p2p-over-lan will apply. Any of the four solutions above apply in this case, although Solution #3 will no longer need fake MAC addresses. When it is broadcast, there can be multiple CE routers on the ethernet AC. The preferred route in this particular case is to change the FR AC to bridged encapsulation and use ethernet encapsulation through the pseudowire. This will allow the FR attached CE to properly participate when presented with packets with the three multicast MAC addresses AllISs, AllL1ISs, and AllL2ISs. If the FR AC is not changed to bridged encapsulation, the ethernet attached PE will need to assume that all ISIS packets received across the pseudowire should be prepended with the AllISs destination MAC or dig into the packet to determine the MAC to use based on the packet type. Dave. ----------------------- "Serbest, Yetik" wrote: > As far as I can tell, what you point me to can not work for ISIS, right? > Because ATM/FR side does not include MAC address in its Hello PDU. So, there > is no way to proxy ARP. Am I missing something? From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Serbest, Yetik" Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Fri, 8 Aug 2003 14:23:37 -0500 Lines: 77 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Mustapha Aissaoui'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Aug 08 22:24:20 2003 Return-path: To: "'david.watkinson@alcatel.com'" , "Serbest, Yetik" 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 David, The problem raised was that your customer does not want to change the encapsulation. Hence, you say "If the FR AC is not changed to bridged encapsulation, the Ethernet attached PE will need to assume that all ISIS packets received across the pseudowire should be prepended with the AllISs destination MAC or dig into the packet to determine the MAC to use based on the packet type". Then I would recommend you ask your customer to read this, and I am pretty sure they would volunteer to change their configuration. The bottom-line is that in scenarios with disparate attachment circuits (one side Ethernet and the other is ATM/FR), bridged interworking is a simple and clean approach. Thanks, yetik -----Original Message----- From: David Watkinson [mailto:david.watkinson@alcatel.com] Sent: Friday, August 08, 2003 1:33 PM To: Serbest, Yetik Cc: 'Mustapha Aissaoui'; pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 Yetik, The issue here is how to encapsulate ISIS to carry it on PW's. Assume that the customer of the provider has a mixture of ATM routed encapsulation, FR routed encapsulation and PPP AC's running IP and ISIS only. I'll deal with adding bridged encapsulation and ethernet AC's later. There are several options: #1 - over ATM using draft-ietf-pwe3-atm-encap and service interworking FR and PPP to ATM #2 - over IP using draft-ietf-isis-wg-over-ip for the ISIS traffic. This may have to be interworked by the PE if the CE router can not support it. #3 - over Ethernet by stripping the ATM,FR,PPP and adding an 18-byte MAC header. There isn't likely going to be valid MAC addresses to use with these AC's so fake MAC addresses may be needed. #4 - over PW PID by stripping the ATM,FR,PPP and adding a 4-byte PW PID. Solution #2 is not likely to take off as this draft is not implemented by many vendors. Solution #4 seems to be the best for efficient operation. The use of a secondary PW for carrying the IP traffic is an independant decision and only makes sense when coupled with choice #3 in order to reduce bandwidth utilitization. It seems to me that the management overhead and additional signalling of dealing with an additional PW per ISIS adjacency is very expensive compared to combining them using one of the four solutions above. When adding bridged encapsulation or ethernet AC's (e.g. an ethernet AC to a FR AC), the ISIS link can be configured as point-to-point or broadcast. This configuration needs to be consistent across both CE's. When it is point-to-point (i.e. only one CE device on the ethernet end), the procedures in draft-ietf-isis-igp-p2p-over-lan will apply. Any of the four solutions above apply in this case, although Solution #3 will no longer need fake MAC addresses. When it is broadcast, there can be multiple CE routers on the ethernet AC. The preferred route in this particular case is to change the FR AC to bridged encapsulation and use ethernet encapsulation through the pseudowire. This will allow the FR attached CE to properly participate when presented with packets with the three multicast MAC addresses AllISs, AllL1ISs, and AllL2ISs. If the FR AC is not changed to bridged encapsulation, the ethernet attached PE will need to assume that all ISIS packets received across the pseudowire should be prepended with the AllISs destination MAC or dig into the packet to determine the MAC to use based on the packet type. Dave. ----------------------- "Serbest, Yetik" wrote: > As far as I can tell, what you point me to can not work for ISIS, > right? Because ATM/FR side does not include MAC address in its Hello > PDU. So, there is no way to proxy ARP. Am I missing something? From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Michael H. Behringer" Subject: Re: draft-fang-ppvpn-security-framework-01.txt Date: Fri, 08 Aug 2003 21:10:28 +0200 Lines: 65 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: l3vpn@ietf.org, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Aug 08 23:47:06 2003 Return-path: X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: stbryant@cisco.com, Ron Bonica , luyuanfang@att.com In-Reply-To: <3F27F99D.90007@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 At 19:00 30/07/2003, Stewart Bryant wrote: >[...] >2. Security Reference Model > > Also outside the scope are all aspects of network security which are > independent of whether a network is a PPVPN network or a > conventional network (for example, attacks from the Internet to a > server of a given PPVPN user will not be considered here, unless the > way to provision the PPVPN network could make a difference to the > security of this server). > >SB> This is the first time you use the term server, and I not sure I >SB> understand what you mean. Presumably you refer to the equipment >SB> that interfaces the VPN to the VPN core (and hence Internet). In >SB> which case it is not just the provisioning mechanism that needs >SB> to be considered. No, I mean literally a "server", like a web server for example. What I'm trying to say is: - A server can be attacked from the Internet. This is independent of whether this enterprise... -- has a private network with an Internet gateway, or -- has a PPVPN service. For attack forms where this statement is NOT true, it's the job of the draft to highlight this. Where this IS true it's outside the scope. I'll change the above sentence, I hope that makes it clearer. >[...] >6.4. CE Authentication > > It is not possible for an outsider to install a CE and pretend to > belong to a specific PPVPN, to which this CE does not belong in > reality. > >SB> I think that you need to restate this, to state that authentication >SB> makes this impossible (well actually just difficult). Not clear what you mean. The requirement is "authentication", and if this is present, the consequence is that "it is not possible ...". Same structure as in all other sections?!?? Please clarify... >6.5. Integrity > > Data in transit must be cryptographically secured such that it > cannot be altered. > >6.6. Anti-Replay > > Data in transit must be cryptographically secured such that it > cannot be recorded and replayed later. > >SB> You may wish to expand the last two sections a little so that the >SB> title is not integral to reading the sentence. Hmmm, I like it short and crisp ;-) But I'll reword it :-) Thanks for your comments! Michael [rest deleted here] From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Ali Sajassi Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Mon, 11 Aug 2003 13:07:55 -0700 Lines: 97 Sender: pwe3-admin@ietf.org References: <200307281748.h6SHm0MK004642@rtp-core-1.cisco.com> <4.3.2.7.2.20030731072108.02566ce0@airborne.cisco.com> <4.3.2.7.2.20030806115829.020a9d48@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Aug 11 22:12:12 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mustapha Aissaoui , Ali Sajassi In-Reply-To: <3F33E7B6.45B2F411@alcatel.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 At 02:11 PM 8/8/2003 -0400, Mustapha Aissaoui wrote: >ALi, > > > If the issue is with notification of far-end AC and/or the reflection of AC > > status into PWs and vise versa, then this can be done in a number of ways > > (either through the use of control plane or data plane). And when talking > > about interworking of different protocols over the disparate ACs, then it > > is important to note that it is not simply just the question of > > encapsulation and PID. Furthermore, your customers probably will be willing > > to change the config in some of their sites than risking their protocols > > not working at all :-) > >MA> I mentioned a number of issues with the 1-to-N VC-to-PWs. Let me >repeat them here for the sake of progressing the discussion: >a. OAM of a single VC which paylod is split over multiple PWs has >not been proven to work. >b. Reflecting the status of the entire VC based on the status of >individual PWs is not obvious to me. What do you do when your >bridged-encap PW is down while your routed-encap PW is still up. >What is the status of the FR VC? There are two cases to consider: a) when a PW fails and you need to notify the corresponding AC(s) b) when one AC fails, and you need to notify the other AC Considering the scenarios that we have been discussing (ATM/FR to Ethernet), there is currently no LMI for Ethernet end of it. So if a PW fails, the ATM/FR end of it needs to get notified only. And if an ATM/FR VC fails, there is no LMI to convey the failure to the Ethernet side of it. However, if we assume that one day we will have a LMI for Ethernet, then we can use the TLV defined in the draft-shah-control-protocol-extension to convey the status of one AC to another side for case (b) above. And for case (a) above, the status is reported to the AC upon failure of any one of the N PWs (typically only 2 PWs). In other words, as soon as one of the PWs associated with that AC has failed, an alarm is indicated to that AC and there is no need to do anything else with the traffic on the other PWs - this is consistent with existing FR and ATM procedure where alarms get generated independently from the DLCI/VC customer traffic. >c. Transparency of the L2 service is lost. Basically this solution >messes-up with the user payload. It splits user packets arbitrarily >based on received FR-PID and they are received in the far-end in an >arbitrary order because of the delay differential across multiple >independent PWs. Unless you are thinking of building something as >sophisticated as Inverser Multiplexing over ATM (IMA) or multilink >Frame Relay with a per-VC sequence number mechanism that spans >multiple PWs. > Lets not confuse different traffic flow in here. The IP flow is independent from Apple Talk or IPX flows and each flow in delivered in order and each flow will experience consistent delay because all the packets in each flow take exactly the same path through the network. And that is different from different flows taking different path. BTW, if you are concern about transparency of L2 protocols, then you should be concern about interception of the protocol messages and injection of new messages that you were referring to previously !!! > > > > I would encourage you to go over different scenarios for disparate ACs and > > try to see: > > a) what are all different protocols that can be carried over them > > b) what are the dependencies of these protocol to underlying L2 media > > c) how can you interwork these different protocols > > d) what is the common denominator approach among them > > Once you do that, you can see that there are more issues than just defining > > a PID. > > So in short, before requiring a Multi-protocol PW, the need for such PW > > needs to be clearly justified in the context of the applicable scenarios. > > At this point, I think the existing PWs plus the addition of IP PW should > > be enough unless it is shown otherwise. > >MA> Going over different scenarios for disparate ACs is not a >theoretical exercise to me. Each customer is a case of its own. In >some cases, my customer does not know much about what his customers >carry over the FR VC today (remember this FR service is a L2 >transparent service). This is why the L2 dependency issues have to >be resolved customer by customer. I do not think is something that >can realistically be standardized. However, the PID translation and >the signaling of the PW can be. This is interesting !!! You are saying that your customer doesn't know what his customer is carrying over FR but you are trying to come up with the PID assignment for those protocols irrespective of how those protocols can be handled between different disparate interfaces (e.g., between Ethernet broadcast interface and PtP ATM/FR interface). What I am saying is that you cannot just simply go and do the same PID assignment as we have in FR-ATM service interworking and assume that everything will work just dandy. There is a dependency in here and you need to factor that in first. Let me put it in a different way for you, for every protocol that you want to assign a PID for, you need to see what type of dependency it has on broadcast v.s. PtP media and how to handle this dependency or else you will have many unhappy customers :-) I will be on vacation this week and if this stuff is still not clear, then we can talk more next week if needed. -Ali From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Tue, 12 Aug 2003 11:02:30 -0400 Organization: Alcatel Networks Corporaton Lines: 64 Sender: pwe3-admin@ietf.org References: <200307281748.h6SHm0MK004642@rtp-core-1.cisco.com> <4.3.2.7.2.20030731072108.02566ce0@airborne.cisco.com> <4.3.2.7.2.20030806115829.020a9d48@airborne.cisco.com> <4.3.2.7.2.20030808210325.01e4f830@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Tue Aug 12 17:03:08 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ali Sajassi 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 Ali, Ali Sajassi wrote: [snip] > > > I would encourage you to go over different scenarios for disparate ACs and > > > try to see: > > > a) what are all different protocols that can be carried over them > > > b) what are the dependencies of these protocol to underlying L2 media > > > c) how can you interwork these different protocols > > > d) what is the common denominator approach among them > > > Once you do that, you can see that there are more issues than just defining > > > a PID. > > > So in short, before requiring a Multi-protocol PW, the need for such PW > > > needs to be clearly justified in the context of the applicable scenarios. > > > At this point, I think the existing PWs plus the addition of IP PW should > > > be enough unless it is shown otherwise. > > > >MA> Going over different scenarios for disparate ACs is not a > >theoretical exercise to me. Each customer is a case of its own. In > >some cases, my customer does not know much about what his customers > >carry over the FR VC today (remember this FR service is a L2 > >transparent service). This is why the L2 dependency issues have to > >be resolved customer by customer. I do not think is something that > >can realistically be standardized. However, the PID translation and > >the signaling of the PW can be. > > This is interesting !!! You are saying that your customer doesn't know what > his customer is carrying over FR but you are trying to come up with the PID > assignment for those protocols irrespective of how those protocols can be > handled between different disparate interfaces (e.g., between Ethernet > broadcast interface and PtP ATM/FR interface). MA> it is interesting, indeed. You seem to like extrapolating from what I say. The point here is that each customer is a special case and there is work to be done with their customers to make sure that their current service is not affected when this type of interworking is introduced. This includes the resolution of the L3 dependency on L2 media issues and the identification of the end-user protocols. Whether you identify them using a label as in your 1-to-N VC-to-PWs or a PID is orthogonal to the L3/L2 dependency. >What I am saying is that you > cannot just simply go and do the same PID assignment as we have in FR-ATM > service interworking and assume that everything will work just dandy. There > is a dependency in here and you need to factor that in first. Let me put it > in a different way for you, for every protocol that you want to assign a > PID for, you need to see what type of dependency it has on broadcast v.s. > PtP media and how to handle this dependency or else you will have many > unhappy customers :-) MA> So, what is the point you are trying to make? You have been repeating this over and over again. I have been trying to explain that the L3 dependency on Layer 2 media is an orthogonal issue to the way the multiple payloads are carried over MPLS. Whether you choose Option 1 (extend FR or Ethernet to the remote PE), Option 2 (1-to-N VC-to-PWs), or Option 3 (PID translation), you have to resolve these issues. > I will be on vacation this week and if this stuff is still not clear, then > we can talk more next week if needed. > > -Ali From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: Typo in draft-ietf-pwe3-iana-allocation-01.txt ? Date: Tue, 12 Aug 2003 11:34:06 -0400 Organization: Cisco Systems Lines: 20 Sender: pwe3-admin@ietf.org Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Luca Martini'" , "Mark Townsley" X-From: pwe3-admin@ietf.org Tue Aug 12 17:35:12 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, Given the text in section 3, it appears that the table below is incorrect. The last item should be 0x09 (it collides with the 3rd item prior to it): The interface parameter ID is assigned as follows: Parameter ID Length Description 0x01 4 Interface MTU in octets. 0x02 4 Maximum Number of concatenated ATM cells. 0x03 up to 82 Optional Interface Description string. 0x04 4 CEP [8] Payload Bytes. 0x05 2 CEP options. 0x06 2 Requested VLAN ID 0x07 4 CEP/TDM bit-rate 0x08 2 Frame-Relay DLCI Length 0x06 2 Fragmentation indicator From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "W. Mark Townsley" Subject: Re: Typo in draft-ietf-pwe3-iana-allocation-01.txt ? Date: Tue, 12 Aug 2003 17:37:43 +0200 Lines: 30 Sender: pwe3-admin@ietf.org References: <03eb01c360e7$2dc59060$6501a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Tue Aug 12 17:39:07 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en To: tnadeau@cisco.com In-Reply-To: <03eb01c360e7$2dc59060$6501a8c0@amer.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 Yes, it's a known typo and will be corrected with the next revision. Thanks, - Mark Thomas D. Nadeau wrote: > Hi, > > Given the text in section 3, it appears that > the table below is incorrect. The last item > should be 0x09 (it collides with the 3rd item > prior to it): > > The interface parameter ID is assigned as follows: > Parameter ID Length Description > > 0x01 4 Interface MTU in octets. > 0x02 4 Maximum Number of concatenated ATM cells. > 0x03 up to 82 Optional Interface Description string. > 0x04 4 CEP [8] Payload Bytes. > 0x05 2 CEP options. > 0x06 2 Requested VLAN ID > 0x07 4 CEP/TDM bit-rate > 0x08 2 Frame-Relay DLCI Length > 0x06 2 Fragmentation indicator > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: Request Interface Parameter ID for VCCV Date: Tue, 12 Aug 2003 12:01:23 -0400 Organization: Cisco Systems Lines: 12 Sender: pwe3-admin@ietf.org References: <3F168AB5.7070201@level3.net> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'George Swallow'" X-From: pwe3-admin@ietf.org Tue Aug 12 18:03:37 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F168AB5.7070201@level3.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 Given the following statement in draft-ietf-pwe3-control-protocol-03.txt: Parameter ID values 1 through 9 are defined in this document. Parameter ID values 10 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC2434. We would like to propose that value 10 be allocated for VCCV. --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Marichetty, Venkatesan" Subject: Ethernet Encapsulation Date: Thu, 14 Aug 2003 17:19:05 -0400 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Thu Aug 14 23:20:07 2003 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 Hi, I have the following questions in the draft-ietf-pwe3-ethernet-encap-03.txt. It will be useful if somebody can answer them. 1. In section 3.1.2 it's been stated that in tagged mode every frame must have a "service-delimiting" VLAN tag. Consider the scenario, when PE receives a frame from CE which already has a VLAN tag (placed by CE) which is not a "service-delimiting" tag. In this situation, is PE supposed to add a "service-delimiting" VLAN tag on top of the CE VLAN tag? 2. How to identify a "service-delimiting" VLAN tag? Is it expected that the user will configure at PE, for ex, list of tags as "service-delimiting" tags and based on the encapsulation mode determine whether to strip it (raw) or keep it (tagged)? thanks Mari From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Paul Knight" Subject: RE: draft-fang-ppvpn-security-framework-01.txt Date: Mon, 18 Aug 2003 11:57:39 -0400 Lines: 250 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C365A1.73614380" Cc: l3vpn@ietf.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Aug 20 03:09:09 2003 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 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_01C365A1.73614380 Content-Type: text/plain Hi Stewart, Thanks for your comments. Responses to some parts of your questions, regarding section 4: > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, July 30, 2003 1:00 PM > To: Ron Bonita; luyuanfang@att.com > Cc: l3vpn@ietf.org; pwe3@ietf.org > Subject: draft-fang-ppvpn-security-framework-01.txt > [...] > > > 4.1. Cryptographic techniques > > Packet lengths are typically increased when the packets are > encrypted, increasing the network traffic load and adding to the > likelihood of packet fragmentation with its increased overhead. > > SB> Do you want to talk about MTU here? It's difficult to do justice to the MTU issues without bloating the document, but I'm thinking of expanding the existing parenthetical mention of compression to include it: (This packet length increase can often be mitigated to some extent by data compression techniques, but at the expense of additional computational burden. It could also be mitigated by decreasing the path MTU perceived by the user VPN sites, so that encrypted packets will not require fragmentation. However, MTU discovery is not reliably active in end systems in current IPv4 networks, so this may be of little benefit in avoiding packet fragmentation. Also, causing a reduction of the MTU within the user's sites violates a common PPVPN goal of minimizing changes to the user's network.) > > > 4.1.3. Cryptographic techniques in Layer 2 PPVPNs > > Layer 2 PPVPNs will generally not be able to use IPsec to provide > encryption throughout the entire network. They may be able to use > IPsec for PE-PE traffic where it is encapsulated in IP packets, > > SB> Does this mean that we need an MPLSsec work item? We've essentially got it in draft-ietf-l3vpn-ipsec-2547-01.txt, which is the approach which this refers to. I don't plan to include the reference in the draft, however. > > > 4.3. Access Control techniques > > SB> Should you you call out the use of internal only addresses for > SB> the VPN infrastructure? This is called up later - perhaps a > SB> forward reference? - I'll include a reference, and expand the description of internal-only addresses in 4.4. It's definitely a frequently-used part of isolated infrastructure which we hadn't mentioned. Reference reads: Enforcement of access control by isolated infrastructure addresses is discussed in another section of this document. > > > 4.4. Use of Isolated Infrastructure > > One way to protect the infrastructure used for support of > VPNs is to > separate the resources for support of VPNs from the resources used > for other purposes (such as support of Internet services). In some > cases this may make use of a physically separate equipment for VPN > services, or even a physically separate network. > > For example, PE-based L3 VPNs may be run on a separate > backbone not > connected to the Internet, or may make use of separate > edge routers > from those used to support Internet service. > > SB> This is where local (to the provider) addresses help. Added: Private IP addresses (local to the provider and non-routable over the Internet) may be used to provide additional separation. [...] Regards, Paul ------_=_NextPart_001_01C365A1.73614380 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-fang-ppvpn-security-framework-01.txt

Hi Stewart,

Thanks for your comments.

Responses to some parts of your questions, regarding = section 4:

> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com] =
> Sent: Wednesday, July 30, 2003 1:00 PM
> To: Ron Bonita; luyuanfang@att.com
> Cc: l3vpn@ietf.org; pwe3@ietf.org
> Subject: = draft-fang-ppvpn-security-framework-01.txt
>
[...]
>
>
> 4.1.    Cryptographic = techniques
>
>     Packet lengths are = typically increased when the packets are
>     encrypted, increasing = the network traffic load and adding to the
>     likelihood of packet = fragmentation with its increased overhead.
>
> SB> Do you want to talk about MTU = here?
It's difficult to do justice to the MTU issues = without bloating the document, but I'm thinking of expanding the = existing parenthetical mention of compression to include it:

(This packet length increase can often be mitigated = to some extent by data compression techniques, but at the expense of = additional computational burden. It could also be mitigated by = decreasing the path MTU perceived by the user VPN sites, so that = encrypted packets will not require fragmentation. However, MTU = discovery is not reliably active in end systems in current IPv4 = networks, so this may be of little benefit in avoiding packet = fragmentation. Also, causing a reduction of the MTU within the user's = sites violates a common PPVPN goal of minimizing changes to the user's = network.)

>
>
> 4.1.3.  Cryptographic techniques in Layer = 2 PPVPNs
>
>     Layer 2 PPVPNs will = generally not be able to use IPsec to provide
>     encryption throughout = the entire network.  They may be able to use
>     IPsec for PE-PE traffic = where it is encapsulated in IP packets,
>
> SB> Does this mean that we need an MPLSsec = work item?

We've essentially got it in = draft-ietf-l3vpn-ipsec-2547-01.txt, which is the approach which this = refers to. I don't plan to include the reference in the draft, = however.

>
>
> 4.3.    Access Control = techniques
>
> SB> Should you you call out the use of = internal only addresses for
> SB> the VPN infrastructure? This is called = up later - perhaps a
> SB> forward reference?

- I'll include a reference, and expand the = description of internal-only addresses in 4.4.  It's definitely a = frequently-used part of isolated infrastructure which we hadn't = mentioned.

Reference reads:
 Enforcement of access control by isolated = infrastructure addresses is discussed in another section of this = document.
>
>
> 4.4.    Use of Isolated = Infrastructure
>
>     One way to protect the = infrastructure used for support of
> VPNs is to
>     separate the resources = for support of VPNs from the resources used
>     for other purposes = (such as support of Internet services). In some
>     cases this may make use = of a physically separate equipment for VPN
>     services, or even a = physically separate network.
>
>     For example, PE-based = L3 VPNs may be run on a separate
> backbone not
>     connected to the = Internet, or may make use of separate
> edge routers
>     from those used to = support Internet service.
>
> SB> This is where local (to the provider) = addresses help.

Added:
 Private IP addresses (local to the provider = and non-routable over the Internet) may be used to provide additional = separation.

[...]

Regards,
Paul

------_=_NextPart_001_01C365A1.73614380-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: =?iso-8859-1?q?manomugdha=20biswas?= Subject: pwe3 Date: Mon, 25 Aug 2003 13:23:47 +0100 (BST) Lines: 18 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Mon Aug 25 14:25:19 2003 Return-path: To: pwe3@ietf.org Content-Transfer-Encoding: 8bit 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 are the necessary steps to setup a PW (Pseudowire)?? Are the following steps below right way to do it ?? 1. Establish LDP session (using Hellow packet) 2. Establish LSP in bi-directional mode (using Path Message). Manomugdha ===== Manomugdha Biswas ________________________________________________________________________ Yahoo! India Promos: Win TVs, Bikes, DVD players & more! Go to http://in.promos.yahoo.com From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: gwright@nortelnetworks.com Subject: Thank you! Date: Mon, 25 Aug 2003 18:35:00 +0200 Lines: 9 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0188B9B0" X-From: pwe3-admin@ietf.org Mon Aug 25 20:12:44 2003 Return-path: To: X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) 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.70 points, 5 required; * 0.9 -- From: does not include a real name * 3.9 -- Forged mail pretending to be from MS Outlook * 0.5 -- Message has X-MSMail-Priority, but no X-MimeOLE * 0.4 -- Spam tool pattern in MIME boundary Status: O This is a multipart message in MIME format --_NextPart_000_0188B9B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0188B9B0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: =?iso-8859-1?q?manomugdha=20biswas?= Subject: pwe3 Date: Wed, 27 Aug 2003 05:41:44 +0100 (BST) Lines: 19 Sender: pwe3-admin@ietf.org References: <20030825122347.1077.qmail@web8007.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Wed Aug 27 18:52:08 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <20030825122347.1077.qmail@web8007.mail.in.yahoo.com> Content-Transfer-Encoding: 8bit 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 are the necessary steps to setup a PW (Pseudowire)?? Are the following steps below right way to do it ?? 1. Establish LDP session (using Hellow packet) 2. Establish LSP in bi-directional mode (using Path Message). Manomugdha ===== Manomugdha Biswas ________________________________________________________________________ Yahoo! India Promos: Win TVs, Bikes, DVD players & more! Go to http://in.promos.yahoo.com From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: =?iso-8859-1?q?manomugdha=20biswas?= Subject: pw establishment Date: Thu, 28 Aug 2003 11:54:28 +0100 (BST) Lines: 30 Sender: pwe3-admin@ietf.org References: <20030827044144.52568.qmail@web8006.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: luca@level3.net X-From: pwe3-admin@ietf.org Thu Aug 28 18:34:58 2003 Return-path: To: manomugdha biswas , pwe3@ietf.org In-Reply-To: <20030827044144.52568.qmail@web8006.mail.in.yahoo.com> Content-Transfer-Encoding: 8bit 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 have two questions? i) How the ATM connection (VCC and VPC) are distinguished? If I want to make a VPC then what things I have to do and if I want to make a VCC then what I have to do? It will be great help if you please clarify the above. II) what are the necessary steps to setup a PW (Pseudowire)?? Are the following steps below right way to do it ?? 1. Establish LDP session (using Hellow packet) 2. Establish LSP in bi-directional mode (using RSVP Path Message). Manomugdha ===== Manomugdha Biswas ________________________________________________________________________ Yahoo! India Promos: Win TVs, Bikes, DVD players & more! Go to http://in.promos.yahoo.com From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: =?iso-8859-1?q?manomugdha=20biswas?= Subject: Re: pwe3 Date: Thu, 28 Aug 2003 11:43:26 +0100 (BST) Lines: 34 Sender: pwe3-admin@ietf.org References: <20030827044144.52568.qmail@web8006.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Thu Aug 28 18:55:24 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <20030827044144.52568.qmail@web8006.mail.in.yahoo.com> Content-Transfer-Encoding: 8bit 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 --- manomugdha biswas wrote: > Hi, > what are the necessary steps to setup a PW > (Pseudowire)?? > > Are the following steps below right way to do it ?? > > 1. Establish LDP session (using Hellow packet) > 2. Establish LSP in bi-directional mode (using Path > Message). > > Manomugdha > > > ===== > Manomugdha Biswas > > ________________________________________________________________________ > Yahoo! India Promos: Win TVs, Bikes, DVD players & > more! > Go to http://in.promos.yahoo.com > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 ===== Manomugdha Biswas ________________________________________________________________________ Yahoo! India Promos: Win TVs, Bikes, DVD players & more! Go to http://in.promos.yahoo.com From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: pw establishment Date: Thu, 28 Aug 2003 16:23:57 -0400 Lines: 64 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: luca@level3.net X-From: pwe3-admin@ietf.org Fri Aug 29 05:25:22 2003 Return-path: To: "'manomugdha biswas'" , 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 Manomugdha, Most of your questions should be answered by draft-ietf-pwe3-control-protocol-03.txt. See further comments in-line Peter > -----Original Message----- > From: manomugdha biswas [mailto:manomugdhab@yahoo.co.in] > Sent: Thursday, August 28, 2003 6:54 AM > To: manomugdha biswas; pwe3@ietf.org > Cc: luca@level3.net > Subject: [PWE3] pw establishment > > > Hi All, > I have two questions? > > i) How the ATM connection (VCC and VPC) are > distinguished? The LDP Mapping message that is used to set up the PW contains a "PW type". For ATM encapsulation, this type field specifies whether it is a VCC or VPC. See draft-ietf-pwe3-iana-allocation-01.txt. > If I want to make a VPC then what things I have to > do and if I want to make a VCC then what I have to do? Somehow the two PEs need to find out that they need to set up a PW to carry one or more VPCs or VCCs. How this happens is outside the scope of PWE3. In general it would happen through provisioning by the operator or through the reception of signaling messages from adjacent ATM switches. Once the PEs know about the PW that needs to be set up and the VPCs and/or VCCs that are mapped onto that PW, establishment of the PW is straightforward. It is described in draft-ietf-pwe3-control-protocol-03.txt. > > It will be great help if you please clarify the above. > > II) what are the necessary steps to setup a PW > (Pseudowire)?? > > Are the following steps below right way to do it ?? > > 1. Establish LDP session (using Hellow packet) > 2. Establish LSP in bi-directional mode (using RSVP > Path > Message). No, the current proposal is to use targeted LDP to set up two LSPs that together form one PW. > > Manomugdha > > > > ===== > Manomugdha Biswas > > ______________________________________________________________ > __________ > Yahoo! India Promos: Win TVs, Bikes, DVD players & more! > Go to http://in.promos.yahoo.com > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: =?iso-8859-1?q?manomugdha=20biswas?= Subject: RE: pw establishment Date: Fri, 29 Aug 2003 15:35:51 +0100 (BST) Lines: 148 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: luca@level3.net X-From: pwe3-admin@ietf.org Fri Aug 29 17:49:48 2003 Return-path: To: "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org In-Reply-To: Content-Transfer-Encoding: 8bit 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, I need some clarification on the following lines: No, the current proposal is to use targeted LDP to set up two LSPs that together form one PW. For example: I want to simulate the following topology: Ethernet --------- MPLS --------- ----------| PE |-----------| PE | | Ingress| PW | Igress | | Router | | Router | --------- --------- I want to send an ethernet packet through PE which then encapsulates the packet and sends it through PSN (here it is MPLS). In this case what are the necessary steps to setup the PW? Please tell me the steps with the necessary message types (targeted) to be used. In draft "draft-ietf-pwe3-control-protocol-03.txt" section 5. LDP The PW label bindings are distributed using the LDP downstream unsolicited mode described in [1]. The PEs will establish an LDP session using the Extended Discovery mechanism described in [1, section 2.4.2 and 2.5]. This para says that PEs will establish an LDP session using Targeted Hello Message. Now what next we need to do to setup PW? Is it another round of PDU exchange (Label Request and Label Mapping)? Thanks, Manomugdha --- "Busschbach, Peter B (Peter)" wrote: > Manomugdha, > > Most of your questions should be answered by > draft-ietf-pwe3-control-protocol-03.txt. > > See further comments in-line > > Peter > > > -----Original Message----- > > From: manomugdha biswas > [mailto:manomugdhab@yahoo.co.in] > > Sent: Thursday, August 28, 2003 6:54 AM > > To: manomugdha biswas; pwe3@ietf.org > > Cc: luca@level3.net > > Subject: [PWE3] pw establishment > > > > > > Hi All, > > I have two questions? > > > > i) How the ATM connection (VCC and VPC) are > > distinguished? > > The LDP Mapping message that is used to set up the > PW contains a "PW type". For ATM encapsulation, this > type field specifies whether it is a VCC or VPC. See > draft-ietf-pwe3-iana-allocation-01.txt. > > > If I want to make a VPC then what things I have > to > > do and if I want to make a VCC then what I have to > do? > > Somehow the two PEs need to find out that they need > to set up a PW to carry one or more VPCs or VCCs. > How this happens is outside the scope of PWE3. In > general it would happen through provisioning by the > operator or through the reception of signaling > messages from adjacent ATM switches. > > Once the PEs know about the PW that needs to be set > up and the VPCs and/or VCCs that are mapped onto > that PW, establishment of the PW is straightforward. > It is described in > draft-ietf-pwe3-control-protocol-03.txt. > > > > > It will be great help if you please clarify the > above. > > > > II) what are the necessary steps to setup a PW > > (Pseudowire)?? > > > > Are the following steps below right way to do it > ?? > > > > 1. Establish LDP session (using Hellow packet) > > 2. Establish LSP in bi-directional mode (using > RSVP > > Path > > Message). > > No, the current proposal is to use targeted LDP to > set up two LSPs that together form one PW. > > > > > Manomugdha > > > > > > > > ===== > > Manomugdha Biswas > > > > > ______________________________________________________________ > > __________ > > Yahoo! India Promos: Win TVs, Bikes, DVD players & > more! > > Go to http://in.promos.yahoo.com > > > > _______________________________________________ > > 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 ===== Manomugdha Biswas ________________________________________________________________________ Yahoo! India Promos: Win TVs, Bikes, DVD players & more! Go to http://in.promos.yahoo.com