From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Chris Metz Subject: Re: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Tue, 01 Jul 2003 10:27:14 -0700 Lines: 408 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20030629085324.05067ed8@mail1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Tue Jul 01 21:09:09 2003 Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Raj Sarkar In-Reply-To: <3F00B316.88FE4F5A@net.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 Hey Raj- Comments inline, thanks ... At 03:00 PM 6/30/2003 -0700, Raj Sarkar wrote: >Hi Chris, > >I read the document, Interesting... > >I have a few questions so I thought i will ask you: > ><1> In Section <1> Page 6 - you have mentioned that we need to have >just a single session between the CE and the PE. What do you mean by a >single session here? If the CE and PE are running PNNI then just a single PNNI adjacency (i.e RCC, signaling channel, etc.) is what is meant by a "control plane session". >What i understand from the draft document is that if we have three >physical links from the CE to the PE - each running PNNI , it will >appear as 3 distinct PNNI links to the destination CE . Right? Well it would be three PNNI links from the CE to the PE. Question I have is do operators typically have 3 distinct PNNI links connecting two adjacent ATM switches? Maybe if each link is associated with a particular traffic class. And then it is up to PNNI on the CE to direct the signaling message onto the appropriate link based on the requested traffic class of the signaled connection. >So , one instance of PWE3 Signalling will control these 3 instances of >SAAL/PNNI signalling. Inside the PSN, all these distinct links are lost. PNNI topology and signaling awareness is terminated on the PE. PWE3 signaling can accept and interwork inbound PNNI signaling from any inbound CE-PE link. >Actually , i am interested to know how do you tunnel the distinct >control traffic across the PSN if you have 3 distinct physical links >each running PNNI across the PSN. PNNI topology data is terminated on the PE. The contents of PNNI signaling messages associated with a connection setup/maintanance/teardown are received at the PE, packaged up in a TLV and carried in a PWE3 signaling message to the remote PE. Which remote PE depends upon several factors including type of PNNI signaling message, reachability to the destination ATM prefix and so on. For example if it is a connection setup, then we do a longest prefix match of the called party address and entries in the ATM VRF to resolve the remote PE address. ><2> Do you think it is wise to make BGP more complex by extending >support for ATM prefixes (BGP is complex anyway). BGP is not simple, you got that right :-) >Don't you think it is >becoming the "workaround" protocol for any problem we have in the IP >world. Not necessarily ... it is a routing protocol designed to propagate multi-protocol address family prefixes in a scalable and controllable manner. And it does not need to in any way touch the core elements. So I would argue that this is just the application that MP-BGP was designed for. Again it is being used to distribute address prefixes to multiple parties (PEs). We are not suggesting its use as a signaling protocol for this type of L2VPN .... >Why not use IP based addressing scheme here instead of extending >the BGP support for ATM prefixes? [ Assuming that we have an one-to-one >mapping between IP and ATM addresses and the Customer has the >flexibility of changing its ATM addresses..]. Then the PE needs to >convert the ATM prefixes to appropriate IP address and vice versa [Need >to think about this ??] . That would be preferable but in the real world I don't know of many customers who would renumber their ATM networks. You will need a routing protocol (like MP-BGP) to distribute these prefixes and place them in the appropriate VRF. ><3> Now, tell me what happens when one of the nodes in the PSN fails and >only some of the pseudo-wires travel across that node. PSN node or link failures are handled by IP and/or MPLS recovery and reroute mechanisms. There is a slew of different (and emerging) mechanisms that can identify and reroute around failed links or nodes in 10s of milliseconds (i.e. MPLS FRR) and in some situations keep traffic flowing (i..e. graceful restart, non-stop forwarding). So the intent is that hiccups inside the PSN should be transparent to end-to-end switched ATM connection function. >Actually, what >if the control traffic does not flow through a node , but a different >node? In this case the source and dst CE will still be connected while >the switched VCs may still get affected.. Actually once you explain <1> >, <3> will be clear as well. > ><4> I saw that you have talked about the model i was proposing in Page 5 >Introduction Section.1 . You talked that this approach has 2 drawbacks: > >(i) A set of PWs and associated PN tunnels must be configured prior in a >partial or full mesh. This is not a drawback per se. But it could be if you have a large number of PW and PSN tunnels to configure. Should be fine for manageable number and that is up to the operator to decide. The other issue that I have heard from carriers is that you need to over-provision these PW and PSN tunnels which can be viewed as being resource inefficient. >(ii) QOS - per VC QOS. But, nowhere we have addressed this in this >draft. So QOS is still a concern or follow the approach as specified in >Section 7.1 Right section 7 discusses several approaches. >By the way, just out of curiosity did you read the recent >paper on IP QOS in IEEE Communication Magazine - "Scalability and >Quality of Service : A Trade-off?" by Michael Welzl and Max Muhlhauser. >Then, you will understand why i am saying that do we actually need to >keep per flow state in the core , in this case is the PSN network. This is probably not the appropriate forum to review IEEE papers but yes I did that article. His argument for scalability using the analogy of aggregation via many students-several tutors-one professor versus fined grained service ala many students-one professor was clever. However I don't agree with the observation that the quality of service was impacted via aggregation. To the student, a useful insight/tip is just that ... should not matter that the professor or the tutor dispensed it. Just like an ATM end-point should not care if per-VC state is maintained in the core or not. PS- I tutored undergrads in college, my feelings are hurt :-( >So, in conclusion, for the small CLECs or small business networks using >ATM access, we can still use the VP Tunnel overlay approach, since (ii) >is anyway not solved. Yes if the network is small then keep it simple. Thanks ... >Thanks, >Raj Sarkar > >Chris Metz wrote: > > > > Hey Raj- > > The overlay models you describe come with the advantages (i.e. simplicity, > > transparency) and the burdens of any classic overlay approach. The burdens > > may be O(N^2) connection provisioning/managment scale and lack of > > per-connection QoS precision if we are using port or VP mode tunnels. > > > > An alternative approach to solving this problem based on control plane > > interworking mechanisms is explored in: > > > > http://ietf.org/internet-drafts/draft-metz-switched-atm-l2vpn-00.txt > > > > In this solution ATM signaling/routing is terminated on the PE and > > "interworked" into PSN signaling and routing for carriage across the PSN. > > So MP-BGP propagates ATM prefixes (just like VPNv4 prefixes in 2547) > > between PEs and PNNI/AINI signaling drives concurrent PWE3 signaling in > > real-time with the latter bearing the contents of a switched VPC or VCC. > > > > Why this approach over an overlay approach? Several reasons: > > > > - providers already run (or plan to run) 2547-based services in their > > networks (i.e. IP VPN). Supporting switched ATM connectivity becomes just > > another service managed on PE using familiar protocol machinery and > > operations. > > > > - providers can run a uniform set of PSN routing/signaling protocols. No > > need to extend PNNI adjacencies or create an overlay across the PSN which > > means you still have multiple networks to manage > > > > - PE needs awareness of per-connection attributions for that extra > > precision in making appropriate connection-to-PW mapping decisions, marking > > EXP/DSCP bits, performing CAC or maybe even driving PSN resource > allocations. > > > > - need to work over non-MPLS networks (what if provider is IP-only?) > > > > - need to support service interworking between switched ATM end-points and > > end-points attached to PE via static or non-ATM links. > > > > - need to re-use leverage existing IETF PWE3 signaling/encaps (i.e. LDP, > > L2TPv3) and attendant mechanisms (i.e. LSP ping, VCCV, L2VPN IW) for > > management and troubleshooting of switched ATM connectivity across the PSN > > cloud. > > > > Cheers ... > > > > At 11:16 AM 6/27/2003 -0700, Raj Sarkar wrote: > > >Hi Mustapha/Mathew, > > > > > >I saw the document and the explicit model of network interworking > > >between ATM and MPLS. But the model suggested will work with any > > >overlay network - ATM, Ethernet, FR as long as we use the concept of > > >PN Tunnels. It is much easier for the administrator to just configure a > > >a logical port on the CE and then tunnel the PNNI signalling across > > >the overlay networks with the help of a PN Tunnel ( whatever it may be > > >an LSP, L2TP Tunnel, IP VPN et al). On the PE, you just need to map > > >the cells/PDUs coming on VPI X to PN Tunnel Y and again on the egress > > >PE from PN Tunnel Y to VPI X. To Logical ports A and Logical ports B, > > >it will be as if they are immediate neighbors and talking to each other. > > > > > >Regarding TE as i said it does not matter what the internal guarantees > > >for the VCs are. Anyway , the administrator will ensure that while > > >configuring the tunnel , he/she has enough bw associated with that > > >tunnel.Also, anyway in an ATM Network, when you tunnel VCs through a VP, > > >all the internal guarantees of the VCs are lost. > > > > > >We don't essentially require a one-to-one mapping from a VC to a > > >pseudo-wire as you need thousands of pseudo wires which may be an > > >administrative nightmare , especially if the VCs are signalled. > > > > > >This model is much easier for a Service Provider to understand - > > >especially for those who have access and core ATM Networks and if they > > >are running PNNI/AINI et al. They can simply replace the core with > > >MPLS/IP and use the PNNI Tunneling thro PN Tunnels model to create > > >virtual ATM networks. > > > > > >But i agree to the part that service interworking may not necessarily be > > >a part of this draft but PROBABLY can be a part of the addendum. It will > > >be a good workaround till the specs (both ATM Forum and IETF) are > > >finalized. > > > > > >Thanks, > > >Raj Sarkar > > > > > >Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > > Raj, > > > > > > > > Please see some comments below. > > > > > > > > Best regards, > > > > > > > > Matthew > > > > > > > > ----------------------------------------- > > > > Matthew Bocci > > > > Office of the CTO > > > > Alcatel Fixed Networks Division > > > > ----------------------------------------- > > > > > > > > |---------+---------------------------> > > > > | | Raj Sarkar | > > > > | | > > > | | com> | > > > > | | Sent by: | > > > > | | pwe3-admin@ietf.| > > > > | | org | > > > > | | | > > > > | | | > > > > | | 26/06/2003 23:59| > > > > | | | > > > > |---------+---------------------------> > > > > > > > > >-------------------------------------------------------------------------------------------------------------------------------| > > > > | > > > | > > > > | To: pwe3@ietf.org > > > | > > > > | cc: > > > | > > > > | Subject: [PWE3] Virtual ATM Networks over > > > > IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) | > > > > > > > > >-------------------------------------------------------------------------------------------------------------------------------| > > > > > > > > Hi All, > > > > > > > > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt > which is > > > > still a working document > > > > of the pwe3 group. > > > > > > > > ------- -------- > > > > -------- -------- > > > > | | | > > > > | | | | > > > > | > > > > ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O > > > > ( ATM b > > > > lport A VPC Terminatio to PN > Tunnel > > > > to VPC Term lport B > > > > | | > > > > | | | | > > > > | > > > > ------- -------- > > > > -------- ------- > > > > > > > > For simplicity i am assuming that the PN Tunnel is an MPLS LSP which > > > > traverses over an MPLS > > > > core network. > > > > > > > > Now i want ATM Network a to talk to ATM Network b even without it being > > > > aware that the > > > > cells are travelling over an Non - ATM Network. Hypothetically, if > we have > > > > two logical ports > > > > as in the diagram with signalling channels on them, for the ATM > Network it > > > > would be like > > > > > > > > lport A -----(logical link) ------- > lport B > > > > > > > > Hence, we can ideally tunnel signalling as well over the MPLS LSP. > Why is > > > > this not a part of the > > > > working draft? > > > > > > > > Matthew> What you describe is the port trunking service, which has been > > > > discussed at length on this list in the past, but I think it was > decided to > > > > separate the encapsulations from the services that you could > implement with > > > > them. You can implement this service using encapsulations described > in the > > > > draft, depending on whether the logical link in the above diagram > is the > > > > PSN tunnel, or the Pseudo-Wire. However, there are a number of > issues with > > > > this service that make it harder to implement than might at first > appear. > > > > The first issue is that ATM traffic contracts are defined on a per-ATM > > > > connection basis, not per-port. This makes it more difficult to apply > > > > traffic management to pseudo-wires to support ATM QoS without > > > > over-provisioning. There were also issues raised with regard to OAM and > > > > fault management. > > > > > > > > It actually makes the signalling interworking with MPLS much simpler in > > > > case of an ATM-MPLS > > > > -ATM netowrk. The administrator just needs to create two logical > ports on > > > > the CE. Now the PE > > > > adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. > Now, > > > > following the draft > > > > recommendations the ATM cells are transported over the MPLS Network > as well > > > > as the signalling packets. This will be much simpler if we want to > create > > > > ATM Networks over MPLS. > > > > > > > > Matthew> Are you descibing tunnelling VPCs across the network (one > VPI per > > > > logical port)? If so, this can be done with either the one to one > or the N > > > > to one modes. > > > > As you correctly point out, tunnelling PNNI through the PSN is one > of the > > > > simplest ways of interworking with the ATM control plane. This can be > > > > implemented without using a port trunking service and instead simply > > > > mapping the PNNI routing control channel and signalling channels to > > > > pseudo-wires, to transport the ATM control plane traffic. The ATM > Forum has > > > > been working on an approach based on this for awhile now. > > > > > > > > Also, when TE comes into the picture, we should remember that > whenever we > > > > use VP Tunnels > > > > in actual ATM Network , the individual VC guarantees are lost > anyway. For > > > > efficiency, the > > > > PE can add an LSP with different diffserv codepoints. So, the CE > can create > > > > CBR Logical ports, > > > > VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF > > > > Queue or AF Queue > > > > in the PE Router. > > > > > > > > Matthew> Put this a different way, if you use VPCs in an ATM > network, the > > > > traffic contract is on the VPC. You must provision that VPC so that > any QoS > > > > guarantees made to ATM VCs on it are supported. > > > > > > > > Hence, using the following approach we can do PNNI Tunelling across the > > > > MPLS Network and > > > > create virtual ATM Networks. > > > > > > > > Thanks, > > > > Raj Sarkar > > > > > > > > (See attached file: raj_sarkar.vcf) > > > > _______________________________________________ > > 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: "Ron Cohen" Subject: Draft-ietf-pwe3-sonet-02.txt Date: Wed, 2 Jul 2003 12:56:40 +0200 Lines: 30 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Jul 02 11:57:37 2003 Return-path: To: "PWE3 \(IETF\)" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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, An updated SONET emulation draft was submitted in time. You can download the draft from the URL below prior to the IETF draft submission announcement ftp://ftp.netvision.net.il/home/r/roncohen/draft-ietf-pwe3-sonet-02.txt No major change. Changes include: 1. Add back CEP operation section (informational) 2. Update MPLS section to match PWE3 architecture draft 3. Complement L2TP encapsulation 3. Add section on Signaling 4. Various editorials and clarifications Comments appreciated Ron Ron Cohen CTO Lycium Networks Desk: +972 9 7619004 Mobile: +972 55 245104 Fax: +972 9 7619022 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: Draft Agenda for PWE3 WG at the 57 IETF Date: Wed, 02 Jul 2003 11:29:18 +0100 Organization: Cisco Systems, Inc. Lines: 76 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 Cc: Danny McPherson X-From: pwe3-admin@ietf.org Wed Jul 02 12:29:31 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 Here is the draft agenda for the PWE3 meeting in Vienna. Please could the authors: 1) Check that I have called up the correct draft 2) Provide me with a one sentence synopses of their slot 3) Provide Danny and I with the slides by 13th July so that we can make them available on the web site before the meeting. If there is anyone/any topic that I have missed please let me know. Stewart Pseudo Wire Emulation Edge to Edge (pwe3) Wednesday, July 16 1530-1730 ============================= CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: 1530-1535 Administrivia "Stewart Bryant" Agenda Bashing Minutes Blue Sheets 1535-1545 "Danny McPherson" WG Document Status 1545-1555 "Thomas Narten" PWE3 move to Internet Area 1555-1605 "Thomas Nadeau" http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-00.txt 1605-1615 "Mustapha Aissaoui" http://www.ietf.org/internet-drafts/draft-aissaoui-extended-pid-00.txt 1615-1630 "Dave Allan" http://www.ietf.org/internet-drafts/draft-allan-mpls-a-bit-00.txt http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt 1630-1640 "Sasha Vainshtein" http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt 1640-1650 "Yaakov Stein" http://www.ietf.org/internet-drafts/draft-stein-pwe3-stpp-00.txt 1650-1705 "Danny McPherson" "Stewart Bryant" Discussion: Getting Traction on TDM 1705-1715 "Himanshu Shah" http://www.ietf.org/internet-drafts/ draft-shah-pwe3-control-protocol-extension-00.txt 1715-1725 "Ghassem Koleyni" SG13 Report 1725-1730 Wrap-up From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-sonet-02.txt Date: Wed, 02 Jul 2003 06:56:37 -0400 Lines: 84 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 02 12:56:35 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 : SONET/SDH Circuit Emulation over Packet (CEP) Author(s) : A. Malis et al. Filename : draft-ietf-pwe3-sonet-02.txt Pages : 48 Date : 2003-7-1 The generic requirements and architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3- ARCH]. Additional requirements for emulation of SONET/SDH and lower-rate TDM circuits has been defined in [PWE3-TDM-REQ]. This draft provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over a packet-switched network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-sonet-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-sonet-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-requirements-06.txt Date: Wed, 02 Jul 2003 06:56:32 -0400 Lines: 87 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 Wed Jul 02 12:56:37 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 : Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) Author(s) : X. Xiao et al. Filename : draft-ietf-pwe3-requirements-06.txt Pages : 19 Date : 2003-7-1 This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e. 'synchronous bit streams at rates defined by ITU G.702') are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requirements-06.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-requirements-06.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-requirements-06.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: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-atm-encap-02.txt Date: Wed, 02 Jul 2003 06:56:27 -0400 Lines: 82 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 02 12:56:55 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 : Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks Author(s) : L. Martini et al. Filename : draft-ietf-pwe3-atm-encap-02.txt Pages : 36 Date : 2003-7-1 A framework for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [3]. This draft provides encapsulation formats and guidelines for transporting a variety of ATM services over a PSN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-atm-encap-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-atm-encap-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-atm-encap-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Wed, 2 Jul 2003 07:47:44 -0500 Lines: 542 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20030701092729.059358d8@mail1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Wed Jul 02 14:49:18 2003 Return-path: To: "Chris Metz" , "Raj Sarkar" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4.3.2.7.2.20030701092729.059358d8@mail1.cisco.com> X-MIME-Autoconverted: from 8bit to quoted-printable by uswgne22.uswest.com id h62CllCt029182 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 It is absolutely possible to have multiple PNNI links between adjacent nodes. Each of the link could be running at different link rates. This would provide both bandwidth as well as redundancy between adjacent nodes. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Chri= s > Metz > Sent: Tuesday, July 01, 2003 12:27 PM > To: Raj Sarkar > Cc: pwe3@ietf.org; pwe3-admin@ietf.org > Subject: Re: [PWE3] Virtual ATM Networks over > IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) > > > Hey Raj- > Comments inline, thanks ... > > At 03:00 PM 6/30/2003 -0700, Raj Sarkar wrote: > >Hi Chris, > > > >I read the document, Interesting... > > > >I have a few questions so I thought i will ask you: > > > ><1> In Section <1> Page 6 - you have mentioned that we need to have > >just a single session between the CE and the PE. What do you mean by a > >single session here? > > If the CE and PE are running PNNI then just a single PNNI adjacency (i.= e > RCC, signaling channel, etc.) is what is meant by a "control > plane session". > > > >What i understand from the draft document is that if we have three > >physical links from the CE to the PE - each running PNNI , it will > >appear as 3 distinct PNNI links to the destination CE . Right? > > Well it would be three PNNI links from the CE to the PE. Question > I have is > do operators typically have 3 distinct PNNI links connecting two adjace= nt > ATM switches? Maybe if each link is associated with a particular traffi= c > class. And then it is up to PNNI on the CE to direct the > signaling message > onto the appropriate link based on the requested traffic class of the > signaled connection. > > > >So , one instance of PWE3 Signalling will control these 3 instances of > >SAAL/PNNI signalling. Inside the PSN, all these distinct links are los= t. > > PNNI topology and signaling awareness is terminated on the PE. PWE3 > signaling can accept and interwork inbound PNNI signaling from > any inbound > CE-PE link. > > > > >Actually , i am interested to know how do you tunnel the distinct > >control traffic across the PSN if you have 3 distinct physical links > >each running PNNI across the PSN. > > PNNI topology data is terminated on the PE. The contents of PNNI > signaling > messages associated with a connection setup/maintanance/teardown are > received at the PE, packaged up in a TLV and carried in a PWE3 signalin= g > message to the remote PE. Which remote PE depends upon several factors > including type of PNNI signaling message, reachability to the destinati= on > ATM prefix and so on. For example if it is a connection setup, > then we do a > longest prefix match of the called party address and entries in > the ATM VRF > to resolve the remote PE address. > > > > ><2> Do you think it is wise to make BGP more complex by extending > >support for ATM prefixes (BGP is complex anyway). > > BGP is not simple, you got that right :-) > > >Don't you think it is > >becoming the "workaround" protocol for any problem we have in the IP > >world. > > Not necessarily ... it is a routing protocol designed to propagate > multi-protocol address family prefixes in a scalable and controllable > manner. And it does not need to in any way touch the core elements. So = I > would argue that this is just the application that MP-BGP was > designed for. > Again it is being used to distribute address prefixes to multiple parti= es > (PEs). We are not suggesting its use as a signaling protocol for > this type > of L2VPN .... > > > >Why not use IP based addressing scheme here instead of extending > >the BGP support for ATM prefixes? [ Assuming that we have an one-to-on= e > >mapping between IP and ATM addresses and the Customer has the > >flexibility of changing its ATM addresses..]. Then the PE needs to > >convert the ATM prefixes to appropriate IP address and vice versa [Nee= d > >to think about this ??] . > > That would be preferable but in the real world I don't know of many > customers who would renumber their ATM networks. You will need a routin= g > protocol (like MP-BGP) to distribute these prefixes and place > them in the > appropriate VRF. > > > > ><3> Now, tell me what happens when one of the nodes in the PSN fails a= nd > >only some of the pseudo-wires travel across that node. > > PSN node or link failures are handled by IP and/or MPLS recovery and > reroute mechanisms. There is a slew of different (and emerging) > mechanisms > that can identify and reroute around failed links or nodes in 10s of > milliseconds (i.e. MPLS FRR) and in some situations keep traffic flowin= g > (i..e. graceful restart, non-stop forwarding). So the intent is that > hiccups inside the PSN should be transparent to end-to-end switched ATM > connection function. > > > >Actually, what > >if the control traffic does not flow through a node , but a different > >node? In this case the source and dst CE will still be connected while > >the switched VCs may still get affected.. Actually once you explain <1= > > >, <3> will be clear as well. > > > ><4> I saw that you have talked about the model i was proposing in Page= 5 > >Introduction Section.1 . You talked that this approach has 2 drawbacks= : > > > >(i) A set of PWs and associated PN tunnels must be configured prior in= a > >partial or full mesh. > > This is not a drawback per se. But it could be if you have a large numb= er > of PW and PSN tunnels to configure. Should be fine for manageable numbe= r > and that is up to the operator to decide. > > The other issue that I have heard from carriers is that you need to > over-provision these PW and PSN tunnels which can be viewed as being > resource inefficient. > > > >(ii) QOS - per VC QOS. But, nowhere we have addressed this in this > >draft. So QOS is still a concern or follow the approach as specified i= n > >Section 7.1 > > Right section 7 discusses several approaches. > > > >By the way, just out of curiosity did you read the recent > >paper on IP QOS in IEEE Communication Magazine - "Scalability and > >Quality of Service : A Trade-off?" by Michael Welzl and Max Muhlhauser. > >Then, you will understand why i am saying that do we actually need to > >keep per flow state in the core , in this case is the PSN network. > > This is probably not the appropriate forum to review IEEE papers > but yes I > did that article. His argument for scalability using the analogy of > aggregation via many students-several tutors-one professor versus fined > grained service ala many students-one professor was clever. > However I don't > agree with the observation that the quality of service was impacted via > aggregation. To the student, a useful insight/tip is just that ... shou= ld > not matter that the professor or the tutor dispensed it. Just like an A= TM > end-point should not care if per-VC state is maintained in the > core or not. > > PS- I tutored undergrads in college, my feelings are hurt :-( > > > >So, in conclusion, for the small CLECs or small business networks usin= g > >ATM access, we can still use the VP Tunnel overlay approach, since (ii= ) > >is anyway not solved. > > Yes if the network is small then keep it simple. > > Thanks ... > > > >Thanks, > >Raj Sarkar > > > >Chris Metz wrote: > > > > > > Hey Raj- > > > The overlay models you describe come with the advantages > (i.e. simplicity, > > > transparency) and the burdens of any classic overlay > approach. The burdens > > > may be O(N^2) connection provisioning/managment scale and lack of > > > per-connection QoS precision if we are using port or VP mode tunnel= s. > > > > > > An alternative approach to solving this problem based on control pl= ane > > > interworking mechanisms is explored in: > > > > > > http://ietf.org/internet-drafts/draft-metz-switched-atm-l2vpn-00.tx= t > > > > > > In this solution ATM signaling/routing is terminated on the PE and > > > "interworked" into PSN signaling and routing for carriage > across the PSN. > > > So MP-BGP propagates ATM prefixes (just like VPNv4 prefixes in 2547= ) > > > between PEs and PNNI/AINI signaling drives concurrent PWE3 > signaling in > > > real-time with the latter bearing the contents of a switched > VPC or VCC. > > > > > > Why this approach over an overlay approach? Several reasons: > > > > > > - providers already run (or plan to run) 2547-based services in the= ir > > > networks (i.e. IP VPN). Supporting switched ATM connectivity > becomes just > > > another service managed on PE using familiar protocol machinery and > > > operations. > > > > > > - providers can run a uniform set of PSN routing/signaling > protocols. No > > > need to extend PNNI adjacencies or create an overlay across > the PSN which > > > means you still have multiple networks to manage > > > > > > - PE needs awareness of per-connection attributions for that extra > > > precision in making appropriate connection-to-PW mapping > decisions, marking > > > EXP/DSCP bits, performing CAC or maybe even driving PSN resource > > allocations. > > > > > > - need to work over non-MPLS networks (what if provider is IP-only?= ) > > > > > > - need to support service interworking between switched ATM > end-points and > > > end-points attached to PE via static or non-ATM links. > > > > > > - need to re-use leverage existing IETF PWE3 signaling/encaps > (i.e. LDP, > > > L2TPv3) and attendant mechanisms (i.e. LSP ping, VCCV, L2VPN IW) fo= r > > > management and troubleshooting of switched ATM connectivity > across the PSN > > > cloud. > > > > > > Cheers ... > > > > > > At 11:16 AM 6/27/2003 -0700, Raj Sarkar wrote: > > > >Hi Mustapha/Mathew, > > > > > > > >I saw the document and the explicit model of network interworking > > > >between ATM and MPLS. But the model suggested will work with any > > > >overlay network - ATM, Ethernet, FR as long as we use the concept = of > > > >PN Tunnels. It is much easier for the administrator to just > configure a > > > >a logical port on the CE and then tunnel the PNNI signalling acros= s > > > >the overlay networks with the help of a PN Tunnel ( whatever > it may be > > > >an LSP, L2TP Tunnel, IP VPN et al). On the PE, you just need to ma= p > > > >the cells/PDUs coming on VPI X to PN Tunnel Y and again on the egr= ess > > > >PE from PN Tunnel Y to VPI X. To Logical ports A and Logical ports= B, > > > >it will be as if they are immediate neighbors and talking to > each other. > > > > > > > >Regarding TE as i said it does not matter what the internal > guarantees > > > >for the VCs are. Anyway , the administrator will ensure that while > > > >configuring the tunnel , he/she has enough bw associated with that > > > >tunnel.Also, anyway in an ATM Network, when you tunnel VCs > through a VP, > > > >all the internal guarantees of the VCs are lost. > > > > > > > >We don't essentially require a one-to-one mapping from a VC to a > > > >pseudo-wire as you need thousands of pseudo wires which may be an > > > >administrative nightmare , especially if the VCs are signalled. > > > > > > > >This model is much easier for a Service Provider to understand - > > > >especially for those who have access and core ATM Networks > and if they > > > >are running PNNI/AINI et al. They can simply replace the core with > > > >MPLS/IP and use the PNNI Tunneling thro PN Tunnels model to create > > > >virtual ATM networks. > > > > > > > >But i agree to the part that service interworking may not > necessarily be > > > >a part of this draft but PROBABLY can be a part of the > addendum. It will > > > >be a good workaround till the specs (both ATM Forum and IETF) are > > > >finalized. > > > > > > > >Thanks, > > > >Raj Sarkar > > > > > > > >Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > > > > Raj, > > > > > > > > > > Please see some comments below. > > > > > > > > > > Best regards, > > > > > > > > > > Matthew > > > > > > > > > > ----------------------------------------- > > > > > Matthew Bocci > > > > > Office of the CTO > > > > > Alcatel Fixed Networks Division > > > > > ----------------------------------------- > > > > > > > > > > |---------+---------------------------> > > > > > | | Raj Sarkar | > > > > > | | > > > > | | com> | > > > > > | | Sent by: | > > > > > | | pwe3-admin@ietf.| > > > > > | | org | > > > > > | | | > > > > > | | | > > > > > | | 26/06/2003 23:59| > > > > > | | | > > > > > |---------+---------------------------> > > > > > > > > > > > > >----------------------------------------------------------------- > --------------------------------------------------------------| > > > > > | > > > > | > > > > > | To: pwe3@ietf.org > > > > | > > > > > | cc: > > > > | > > > > > | Subject: [PWE3] Virtual ATM Networks over > > > > > > IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) > | > > > > > > > > > > > > >----------------------------------------------------------------- > --------------------------------------------------------------| > > > > > > > > > > Hi All, > > > > > > > > > > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt > > which is > > > > > still a working document > > > > > of the pwe3 group. > > > > > > > > > > ------- -------- > > > > > -------- -------- > > > > > | | | > > > > > | | | > | > > > > > | > > > > > ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O > > > > > ( ATM b > > > > > lport A VPC > Terminatio to PN > > Tunnel > > > > > to VPC Term lport B > > > > > | | > > > > > | | | > | > > > > > | > > > > > ------- -------- > > > > > -------- ------- > > > > > > > > > > For simplicity i am assuming that the PN Tunnel is an > MPLS LSP which > > > > > traverses over an MPLS > > > > > core network. > > > > > > > > > > Now i want ATM Network a to talk to ATM Network b even > without it being > > > > > aware that the > > > > > cells are travelling over an Non - ATM Network. > Hypothetically, if > > we have > > > > > two logical ports > > > > > as in the diagram with signalling channels on them, for the AT= M > > Network it > > > > > would be like > > > > > > > > > > lport A -----(logical link) ------= - > > lport B > > > > > > > > > > Hence, we can ideally tunnel signalling as well over the > MPLS LSP. > > Why is > > > > > this not a part of the > > > > > working draft? > > > > > > > > > > Matthew> What you describe is the port trunking service, > which has been > > > > > discussed at length on this list in the past, but I think it wa= s > > decided to > > > > > separate the encapsulations from the services that you could > > implement with > > > > > them. You can implement this service using encapsulations > described > > in the > > > > > draft, depending on whether the logical link in the above diagr= am > > is the > > > > > PSN tunnel, or the Pseudo-Wire. However, there are a number of > > issues with > > > > > this service that make it harder to implement than might at fir= st > > appear. > > > > > The first issue is that ATM traffic contracts are defined > on a per-ATM > > > > > connection basis, not per-port. This makes it more > difficult to apply > > > > > traffic management to pseudo-wires to support ATM QoS without > > > > > over-provisioning. There were also issues raised with > regard to OAM and > > > > > fault management. > > > > > > > > > > It actually makes the signalling interworking with MPLS > much simpler in > > > > > case of an ATM-MPLS > > > > > -ATM netowrk. The administrator just needs to create two logica= l > > ports on > > > > > the CE. Now the PE > > > > > adds a LSP which maps the logical ports (VP Tunnels) VPI > to an LSP. > > Now, > > > > > following the draft > > > > > recommendations the ATM cells are transported over the > MPLS Network > > as well > > > > > as the signalling packets. This will be much simpler if > we want to > > create > > > > > ATM Networks over MPLS. > > > > > > > > > > Matthew> Are you descibing tunnelling VPCs across the > network (one > > VPI per > > > > > logical port)? If so, this can be done with either the one to o= ne > > or the N > > > > > to one modes. > > > > > As you correctly point out, tunnelling PNNI through the > PSN is one > > of the > > > > > simplest ways of interworking with the ATM control plane. > This can be > > > > > implemented without using a port trunking service and > instead simply > > > > > mapping the PNNI routing control channel and signalling > channels to > > > > > pseudo-wires, to transport the ATM control plane traffic. The A= TM > > Forum has > > > > > been working on an approach based on this for awhile now. > > > > > > > > > > Also, when TE comes into the picture, we should remember that > > whenever we > > > > > use VP Tunnels > > > > > in actual ATM Network , the individual VC guarantees are lost > > anyway. For > > > > > efficiency, the > > > > > PE can add an LSP with different diffserv codepoints. So, the C= E > > can create > > > > > CBR Logical ports, > > > > > VBR Logical ports with CBR,VBR Traffic respectively and > map it to an EF > > > > > Queue or AF Queue > > > > > in the PE Router. > > > > > > > > > > Matthew> Put this a different way, if you use VPCs in an ATM > > network, the > > > > > traffic contract is on the VPC. You must provision that > VPC so that > > any QoS > > > > > guarantees made to ATM VCs on it are supported. > > > > > > > > > > Hence, using the following approach we can do PNNI > Tunelling across the > > > > > MPLS Network and > > > > > create virtual ATM Networks. > > > > > > > > > > Thanks, > > > > > Raj Sarkar > > > > > > > > > > (See attached file: raj_sarkar.vcf) > > > > > > _______________________________________________ > > > 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: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-ethernet-encap-03.txt Date: Wed, 02 Jul 2003 16:33:14 -0400 Lines: 84 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 02 22:34:59 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 : Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks Author(s) : L. Martini et al. Filename : draft-ietf-pwe3-ethernet-encap-03.txt Pages : 19 Date : 2003-7-2 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an IP or MPLS network. This enables service providers to offer 'emulated' ethernet services over existing IP or MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a 'point-to-point ethernet' service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-ethernet-encap-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-ethernet-encap-03.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: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-control-protocol-03.txt Date: Wed, 02 Jul 2003 16:33:18 -0400 Lines: 85 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 02 22:35:09 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 : Pseudowire Setup and Maintenance using LDP Author(s) : L. Martini, N. El-Aawar, E. Rosen Filename : draft-ietf-pwe3-control-protocol-03.txt Pages : 29 Date : 2003-7-2 Layer 2 services (such as Frame Relay, ATM, ethernet) can be 'emulated' over an IP and/or MPLS backbone by encapsulating the layer 2 PDUs and then transmitting them over 'pseudowires'. It is also possible to use pseudowires to provide SONET circuit emulation over an IP and/or MPLS network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to LDP. Procedures for encapsulating layer 2 PDUs are specified in a set of companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-03.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-control-protocol-03.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-control-protocol-03.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: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Wed, 02 Jul 2003 17:16:47 -0400 Organization: Alcatel Networks Corporaton Lines: 183 Sender: pwe3-admin@ietf.org References: <3EFC89E5.13A06B7@net.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Matthew.Bocci@alcatel.co.uk, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 02 23:22:09 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Raj Sarkar 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 Raj, see comments inline. Mustapha. ------------ Raj Sarkar wrote: > Hi Mustapha/Mathew, > > I saw the document and the explicit model of network interworking > between ATM and MPLS. But the model suggested will work with any > overlay network - ATM, Ethernet, FR as long as we use the concept of > PN Tunnels. It is much easier for the administrator to just configure a > a logical port on the CE and then tunnel the PNNI signalling across > the overlay networks with the help of a PN Tunnel ( whatever it may be > an LSP, L2TP Tunnel, IP VPN et al). On the PE, you just need to map > the cells/PDUs coming on VPI X to PN Tunnel Y and again on the egress > PE from PN Tunnel Y to VPI X. To Logical ports A and Logical ports B, > it will be as if they are immediate neighbors and talking to each other. MA> this solution works for service providers who sell a VP service on the UNI to their customers. As you explain, there is nothing special that needs to be done at the except for the encapsulation/decapsulation of cells into/from MPLS packets and the transparent tranport of OAM and control plane messages. > > Regarding TE as i said it does not matter what the internal guarantees > for the VCs are. Anyway , the administrator will ensure that while > configuring the tunnel , he/she has enough bw associated with that > tunnel.Also, anyway in an ATM Network, when you tunnel VCs through a VP, > all the internal guarantees of the VCs are lost. > > We don't essentially require a one-to-one mapping from a VC to a > pseudo-wire as you need thousands of pseudo wires which may be an > administrative nightmare , especially if the VCs are signalled. MA>The ATM Forum extended PNNI specification is intended to service providers who sell a VC service to their customers: a. either a SVC service CE-to-CE, b. or a SPVC service to connect the endpoints on PE (network side of the UNI) to which customer equipment are attached. > > > This model is much easier for a Service Provider to understand - > especially for those who have access and core ATM Networks and if they > are running PNNI/AINI et al. They can simply replace the core with > MPLS/IP and use the PNNI Tunneling thro PN Tunnels model to create > virtual ATM networks. > > But i agree to the part that service interworking may not necessarily be > a part of this draft but PROBABLY can be a part of the addendum. It will > be a good workaround till the specs (both ATM Forum and IETF) are > finalized. > > Thanks, > Raj Sarkar > > Matthew.Bocci@alcatel.co.uk wrote: > > > > Raj, > > > > Please see some comments below. > > > > Best regards, > > > > Matthew > > > > ----------------------------------------- > > Matthew Bocci > > Office of the CTO > > Alcatel Fixed Networks Division > > ----------------------------------------- > > > > |---------+---------------------------> > > | | Raj Sarkar | > > | | > | | com> | > > | | Sent by: | > > | | pwe3-admin@ietf.| > > | | org | > > | | | > > | | | > > | | 26/06/2003 23:59| > > | | | > > |---------+---------------------------> > > >-------------------------------------------------------------------------------------------------------------------------------| > > | | > > | To: pwe3@ietf.org | > > | cc: | > > | Subject: [PWE3] Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) | > > >-------------------------------------------------------------------------------------------------------------------------------| > > > > Hi All, > > > > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is > > still a working document > > of the pwe3 group. > > > > ------- -------- > > -------- -------- > > | | | > > | | | | > > | > > ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O > > ( ATM b > > lport A VPC Terminatio to PN Tunnel > > to VPC Term lport B > > | | > > | | | | > > | > > ------- -------- > > -------- ------- > > > > For simplicity i am assuming that the PN Tunnel is an MPLS LSP which > > traverses over an MPLS > > core network. > > > > Now i want ATM Network a to talk to ATM Network b even without it being > > aware that the > > cells are travelling over an Non - ATM Network. Hypothetically, if we have > > two logical ports > > as in the diagram with signalling channels on them, for the ATM Network it > > would be like > > > > lport A -----(logical link) ------- lport B > > > > Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is > > this not a part of the > > working draft? > > > > Matthew> What you describe is the port trunking service, which has been > > discussed at length on this list in the past, but I think it was decided to > > separate the encapsulations from the services that you could implement with > > them. You can implement this service using encapsulations described in the > > draft, depending on whether the logical link in the above diagram is the > > PSN tunnel, or the Pseudo-Wire. However, there are a number of issues with > > this service that make it harder to implement than might at first appear. > > The first issue is that ATM traffic contracts are defined on a per-ATM > > connection basis, not per-port. This makes it more difficult to apply > > traffic management to pseudo-wires to support ATM QoS without > > over-provisioning. There were also issues raised with regard to OAM and > > fault management. > > > > It actually makes the signalling interworking with MPLS much simpler in > > case of an ATM-MPLS > > -ATM netowrk. The administrator just needs to create two logical ports on > > the CE. Now the PE > > adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, > > following the draft > > recommendations the ATM cells are transported over the MPLS Network as well > > as the signalling packets. This will be much simpler if we want to create > > ATM Networks over MPLS. > > > > Matthew> Are you descibing tunnelling VPCs across the network (one VPI per > > logical port)? If so, this can be done with either the one to one or the N > > to one modes. > > As you correctly point out, tunnelling PNNI through the PSN is one of the > > simplest ways of interworking with the ATM control plane. This can be > > implemented without using a port trunking service and instead simply > > mapping the PNNI routing control channel and signalling channels to > > pseudo-wires, to transport the ATM control plane traffic. The ATM Forum has > > been working on an approach based on this for awhile now. > > > > Also, when TE comes into the picture, we should remember that whenever we > > use VP Tunnels > > in actual ATM Network , the individual VC guarantees are lost anyway. For > > efficiency, the > > PE can add an LSP with different diffserv codepoints. So, the CE can create > > CBR Logical ports, > > VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF > > Queue or AF Queue > > in the PE Router. > > > > Matthew> Put this a different way, if you use VPCs in an ATM network, the > > traffic contract is on the VPC. You must provision that VPC so that any QoS > > guarantees made to ATM VCs on it are supported. > > > > Hence, using the following approach we can do PNNI Tunelling across the > > MPLS Network and > > create virtual ATM Networks. > > > > Thanks, > > Raj Sarkar > > > > (See attached file: raj_sarkar.vcf) From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdm-requirements-01.txt Date: Wed, 02 Jul 2003 18:09:40 -0400 Lines: 86 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jul 03 00:09:46 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 : Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN) Author(s) : M. Riegel Filename : draft-ietf-pwe3-tdm-requirements-01.txt Pages : 25 Date : 2003-7-2 This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital signals of the PDH as well as the SONET/SDH hierarchy over packet-switched networks. It is based on the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH]. It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-tdm-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-tdm-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-frame-relay-01.txt Date: Thu, 03 Jul 2003 11:31:54 -0400 Lines: 86 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jul 03 17:32:13 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 : Frame Relay over Pseudo-Wires Author(s) : C. Kawa et al. Filename : draft-ietf-pwe3-frame-relay-01.txt Pages : 28 Date : 2003-7-3 This document defines frame relay pseudo-wire emulation edge-to-edge. A frame relay pseudo-wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over IP and MPLS packet switched network (PSN). Two mapping modes are defined: One-to-one mapping mode characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs is defined for MPLS PSN. The other mode is known as port mode or many-to-one mapping mode and is defined for MPLS PSN and IP PSN with L2TPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-frame-relay-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-frame-relay-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: Status signaling in draft-ietf-pwe3-control-protocol-03.txt Date: Thu, 3 Jul 2003 15:22:16 -0400 Lines: 230 Sender: pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Thu Jul 03 21:23:06 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 Comments on section 5.3 Status Signaling added to the new revised version of the control draft. It looks to me some of the issues that were raised before in the mailing list were ignored...Here are some items observed on the added text: a) There is no mechanism (implicit/explicit) by which a PE will find out what is the capability/intent of the remote PE (whether it supports status TLV or not). b) There is no mechanism by which a PE can find out initially what is the status of PW during PW setup phase. Upon receiving a label mapping, the PE assumes the PW is up and starts accepting and sending traffic that will end up being discarded if the remote end is down. And that happens even if both PEs support status signaling. One may wonder what is then the value of status signaling if it can't stop a remote PE from sending traffic. c) Ambiguity for the encoding for both the basic LDP notification and status TLV (see below). d) The proposal seems not backward compatible with existing PW behavior and that needs to be explicitly captured in the draft. And there is no mechanism that enforces the rule requiring both PEs to support status signaling in order for the proposal to work. See other comments below (on the added text) "5.3. Signaling of Pseudo Wire Status 5.3.1. Use of Label Mappings. The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the CE-facing interface state. The PW label should not be withdrawn unless the user administratively configures the CE-facing interface down (or the PW configuration is deleted entirely). A simple label withdraw method MAY also be supported as an alternative. In any case if the Label mapping is not available the PW MUST be considered in the down state." Hamid> The question is what is the behavior of the remote end that doesn't support status signaling? For the *PW* to be in down state the *two* sides of the PW should not forward customer traffic. Even if we assume that there is a rule that says "A notification message MUST always be sent after the label mapping message" which in the text there is none. That does not prevent the above problem from happening, and the provider will perform billing/accounting for traffic that will end up being discarded at the remote PE. And if this rule is applied this proposal forces all PWs to send notification messages to all PEs that do not support status signaling. If another rule indicates that a PE should not accept initially traffic until positive notification is received, then the problem that can happen is a deadlock situation. ..... more on the text: "The format of the Notification Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW FEC TLV or Generalized ID FEC Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" Hamid> If we reconstruct the complete message for PWid FEC, we obtain the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW tlv |C| PW type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x0???) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (No parameters are carried as suggested). Basic LDP the notification message looks like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Status (0x0300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >From that I conclude that: a) A PE cannot distinguish between PE Status signaling and basic LDP status signaling. This is ambiguity (even in parsing the message). I do not expect this is acceptable. b) All LDP notification messages must carry PW Status information. I do not expect this is acceptable either. In the text as well: "As mentioned above the Group ID field can be used to send a status notification for all PWs associated with a particular group ID. This procedure is OPTIONAL, and if it is implemented the LDP Notification message should be as follows: the PW information length field is set to 0, the PW ID field is not present, and the interface parameters field is not present. For the purpose of this document this is called the "wild card PW status notification procedure", and all PEs implementing this design are REQUIRED to accept such a notification message, but are not required to send it." Hamid> If PW information length field is 0 then the GROUP ID field doesn't exist either. If the proposal implies that when PW length field is 0 it means there are fields that are present such as GROUP_ID and status field then the length field is no longer a length field but a type field where 0x00 value is reversed. I am not in favor of overloading the length field to represent a type field. It is better to keep the length field to represent just length field...(doing that will avoid later on reserving other length field values to mean something else). Hamid. > -----Original Message----- > From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, July 02, 2003 4:33 PM > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-control-protocol-03.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Pseudo Wire Emulation Edge > to Edge Working Group of the IETF. > > Title : Pseudowire Setup and Maintenance using LDP > Author(s) : L. Martini, N. El-Aawar, E. Rosen > Filename : draft-ietf-pwe3-control-protocol-03.txt > Pages : 29 > Date : 2003-7-2 > > Layer 2 services (such as Frame Relay, ATM, ethernet) can be > 'emulated' over an IP and/or MPLS backbone by encapsulating the layer > 2 PDUs and then transmitting them over 'pseudowires'. It is also > possible to use pseudowires to provide SONET circuit emulation over > an IP and/or MPLS network. This document specifies a protocol for > establishing and maintaining the pseudowires, using extensions to > LDP. Procedures for encapsulating layer 2 PDUs are specified in a > set of companion documents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-pr otocol-03.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-control-protocol-03.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-control-protocol-03.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. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: Comments draft-ietf-pwe3-frame-relay-01.txt Date: Sun, 6 Jul 2003 12:48:22 +0200 Lines: 98 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Sun Jul 06 11:59:04 2003 Return-path: To: "'claude.kawa@polymtl.ca'" 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 Claude and all, Please see below several comments on the latest revision of the FRoPW draft. Some of these are purely editorial nits, while some other look to me like substantial omissions. 1. The Intro section defines the difference between one-to-one and many-to-one modes like following: Two mapping modes are defined between FR VCs and FR PWs: The first one is called "one-to-one" mapping. because there is a one-to-one correspondence between a FR VC and a pair of unidirectional PWs. The second mapping is called "many-to-one" mapping or "port mode" because multiple FR VCs assigned to a port are mapped to one pair of PWs. I think that "unidirectional PWs" are not defined anywhere in the PWE3 architecture. And somehow "unidirectional" is missing in the definition of the "many-to-one" mode while the "pair" remains. Pairs of PWs are also mentioned in the Reference Model section... but Section 7.2 changes the language and discusses a pair of (unidirectional) VC LSPs per a FR VC. And section 9 explicitly refers to "a PW, i.e. a pair of VC LSPs"... 2. The PWE3 framework and PWE3 Protocol Layers drafts referenced in the document has been merged into a common PWE3 architecure document. 3. Requirement to "detect detectable" transmission errors looks somewhat vague. (I believe that nobody expects the FRoPW to detect undetectable transmission errors:-) 4. The draft mentions padding at the end of the FRoPW packet "when a pseudo-wire traverses a link that requires a minimum layer 2 frame length". Since the PWE3 functionality resides exclusively in the edge devices which are, at most, aware, of the types of links they terminate, the text is misguiding. a) Section 7.4.1.1 seems to define padding as part of the ingress PE functionality. It states that "If the link layer protocol does not have a minimum length requirement then Length_field is set to zero and no padding is required." Would this logic really be implemented, the egress PE would be unable to recover the actual length of a short FR frame if the PW crosses an Ethernet link somewhere in the PSN core while the ingress PE uses, say, POS for its connection to the PSN. b) The definition of padding characters in Section 7.3. states that "any 8-bit character with a decimal value from 0 to 255 may be used as a padding character" as if 8-bit characters with other decimal values exist... IMO, padding is the function of the appropriate link anywhere in the network, and not of the PW IWF. The ingress PE must set the length field to sizeof (payload + FRoPW header) if this size is less then 64 bytes, otherwise the length field must be set to 0. The egress PE then always can recover the length of the payload. And, of course, padding is irrelevant with and IP PSN. 5. There are two "B" bits in the FRoPW control word (one carrying the BECN bit of the encapsulated FR frame, and one belonging to the fragmentation mechanism). 6. The draft says that D and F bits of the FRoPW header are "copied" to DE and FECN bits of the recovered FR frame and then explains that a cleared bit can become set as the result of this "copying". 7. The following text seems superfluous: Re-ordering FRoPW packets is an implementation option but requires that the sender numbers FRoPW packets. (Does anybody expect the egress PE to reorder unnumbered packets?:-) 8. Section 7.5 says that a FRoPW packet received with errors must be silently discarded. It is not clear to which errors this section refers: a) Frames with L2 errors are (usually) discareded regardless of being or not being FRoPW packets (indeed, I am not sure one can identifiy such frames as belonging to any specific PW) b) No FRopW specific errors are defined in the draft c) In particular, it is not clear how to treat a packet with L2 size exceeding by far 64 bytes (after skipping the label stack) and non-zero Length field. 9. The draft does not specify whether the DE indications in the FR frames may be somehow reflected in the Diffserv markings of the PSN headers. (The WG Charter explicitly provides for such an activity.) 10.With full respect to Steve Vogelsang, his name appears twice in the list of the draft co-authors (but only once in the authors' addresses list:-). Hopefully these comments will be useful. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: Agenda for PWE3 WG at the 57 IETF Date: Mon, 07 Jul 2003 10:37:03 +0100 Organization: Cisco Systems, Inc. Lines: 67 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 Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Jul 07 11:37:59 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: agenda@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 Pseudo Wire Emulation Edge to Edge (pwe3) Wednesday, July 16 1530-1730 ============================= CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: 1530-1535 Administrivia "Stewart Bryant" Agenda Bashing Minutes Blue Sheets 1535-1545 "Danny McPherson" WG Document Status 1545-1555 "Thomas Narten" PWE3 move to Internet Area 1555-1605 "Thomas Nadeau" Discuss issues brought up on the mailing list since the last meeting, as well as discuss diffs between version 00 and 01. Specifically, additions to support L2TPv3. http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-01.txt 1605-1615 "Mustapha Aissaoui" http://www.ietf.org/internet-drafts/draft-aissaoui-extended-pid-00.txt 1615-1630 "Dave Allan" http://www.ietf.org/internet-drafts/draft-allan-mpls-a-bit-00.txt http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt 1630-1640 "Sasha Vainshtein" Technical issues with draft-vainshtein-cesopsn-06.txt raised during the discussion on the WG list" http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt 1640-1650 "Yaakov Stein" http://www.ietf.org/internet-drafts/draft-stein-pwe3-stpp-00.txt 1650-1705 "Danny McPherson" "Stewart Bryant" Discussion: Getting Traction on TDM 1705-1715 "Himanshu Shah" http://www.ietf.org/internet-drafts/ draft-shah-pwe3-control-protocol-extension-01.txt 1715-1725 "Ghassem Koleyni" Update on activities in ITU-T SG13 regarding interworking topics 1725-1730 Wrap-up From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Philippe.Dollo@alcatel.fr Subject: (no subject) Date: Fri, 11 Jul 2003 17:51:24 +0200 Lines: 21 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Fri Jul 11 17:51:44 2003 Return-path: To: pwe3@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on FRMAIL26/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/11/2003 17:51:25 X-Virus-Scanned: by amavisd-new 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'm a newcomer to this discussion, and I would like to know whether there have already been some discussions addressing the synchronization issue, in an asynchronous scenario as it is described in section 4.3.3 of draft-ietf-pwe3-tdm-requirements-01? My concern is related to the required processing to implement when providing 2Mbit/s E1 interface circuit emulation service. Is there some means such as ATM AAL1 SRTS foreseen to answer to this issue? Thanks in advance, Regards, Philippe. Philippe DOL LO ALCATEL FND/E10 BU/R&D/HWCC tel: +33 2 96 04 75 02 fax: +33 2 96 04 72 22 email: Philippe.Dollo@alcatel.fr From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: (no subject) Date: Fri, 11 Jul 2003 22:31:55 +0200 Lines: 62 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jul 11 21:36:18 2003 Return-path: To: "'Philippe.Dollo@alcatel.fr'" 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 Philippe, I suggest you to take a look at draft-vainshtein-cesopsn-06.txt. This draft proposes usage of the standard RTP header as part of the CES encapsulation layer, and - regarding your question - defines two modes of generating timestams in this header: - Absolute (default) - when the i/f line clock is used for the timestamping - Differential - when a common synchronizationsource is accesssible at the two PEs terminating a TDM PW and is used for timestaming. This mode provides for at least the same functionality (and in the same scenarios)as SRTS in AAL1-based ATM CES. Hopefully this helps. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Philippe.Dollo@alcatel.fr [mailto:Philippe.Dollo@alcatel.fr] > Sent: Friday, July 11, 2003 5:51 PM > To: pwe3@ietf.org > Subject: [PWE3] (no subject) > > > Hi, > I'm a newcomer to this discussion, and I would like to know whether > there have already been some discussions addressing the > synchronization > issue, in an asynchronous scenario as it is described in > section 4.3.3 of > draft-ietf-pwe3-tdm-requirements-01? > My concern is related to the required processing to implement when > providing > 2Mbit/s E1 interface circuit emulation service. > Is there some means such as ATM AAL1 SRTS foreseen to answer > to this issue? > > Thanks in advance, > Regards, > > Philippe. > > Philippe DOL LO > ALCATEL > FND/E10 BU/R&D/HWCC > tel: +33 2 96 04 75 02 > fax: +33 2 96 04 72 22 > email: Philippe.Dollo@alcatel.fr > > > > > _______________________________________________ > 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: PWE3 @ IETF 57 Date: Fri, 11 Jul 2003 16:09:25 -0600 Lines: 10 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Sat Jul 12 00:10:21 2003 Return-path: User-Agent: Microsoft-Entourage/10.1.1.2418 To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Folks, The final PWE3 agenda is posted on the IETF web site. Likewise, http://pwe3.tcb.net has the agenda and presentations we've received thus far. For those of you who have yet to submit your materials, please do so by Monday or you may lose your slot. Thanks, -danny (& Stewart) From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: (no subject) Date: Sun, 13 Jul 2003 10:09:29 +0300 Lines: 27 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 Sun Jul 13 09:10:17 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] (no subject) Thread-Index: AcNHxHZ66Af/68pvQ8KuZN7bWCELKABSEMOg To: , 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 > I'm a newcomer to this discussion, and I would like to know whether > there have already been some discussions addressing the=20 > synchronization issue, in an asynchronous scenario as it is described = in=20 > section 4.3.3 of draft-ietf-pwe3-tdm-requirements-01? > My concern is related to the required processing to implement when > providing 2Mbit/s E1 interface circuit emulation service. > Is there some means such as ATM AAL1 SRTS foreseen to answer=20 > to this issue? Your question needs to be answered in two parts. In the usual case there is no common clock, available to both ingress = and egress. In this case some adaptive clock recovery must be performed. There are numerous algorithms for this purpose, and they CAN conform to internationally recognized jitter and wander = constraints. If a common clock is somehow available to both ingress and egress (e.g. from GPS or from the physical layer of a single-hop optical link) then RTP (for CESoPSN) or SRTS (for TDMoIP) may be used. RTP provides a layer-4 timestamp, while the SRTS provides a layer-2 residual timestamp. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: RTP-based clock recovery (was: no subject) Date: Mon, 14 Jul 2003 11:39:48 +0200 Lines: 68 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Philippe.Dollo@alcatel.fr, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jul 14 10:45:18 2003 Return-path: To: "'Yaakov Stein'" 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 Yaakov and all, Please see acoupleofcomments inline. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Sunday, July 13, 2003 9:09 AM > To: Philippe.Dollo@alcatel.fr; pwe3@ietf.org > Subject: RE: [PWE3] (no subject) > > > > > I'm a newcomer to this discussion, and I would like to know whether > > there have already been some discussions addressing the > > synchronization issue, in an asynchronous scenario as it > is described in > > section 4.3.3 of draft-ietf-pwe3-tdm-requirements-01? > > My concern is related to the required processing to implement when > > providing 2Mbit/s E1 interface circuit emulation service. > > Is there some means such as ATM AAL1 SRTS foreseen to answer > > to this issue? > > Your question needs to be answered in two parts. > > In the usual case there is no common clock, available to both > ingress and egress. > In this case some adaptive clock recovery must be performed. > There are numerous algorithms for this purpose, > and they CAN conform to internationally recognized jitter and > wander constraints. > This is a very interesting statement. It seems to be commonly recognized that adaptive clock recovery methods cope well with the jitter problems but are problematic wrt wander. At least, this was the basis behind introducing SRTS in ATM-CES. > > If a common clock is somehow available to both ingress and egress > (e.g. from GPS or from the physical layer of a single-hop > optical link) > then RTP (for CESoPSN) or SRTS (for TDMoIP) may be used. > RTP provides a layer-4 timestamp, > while the SRTS provides a layer-2 residual timestamp. > Some news here! After years of publicly stating the opposite you seem to recognize that there is some added value in RTP! I am afraid do not understand your reference to "Layer 4" and "Layer 2" timestamps, especially in conjunction with TDMoIP. I'd also like to notice that a scan of draft-anavi-05 (the latest available) has failed to detect any reference to SRTS there but did produce some hits on RTP - in fact, it has found Section 2.3. called "RTP"... > Y(J)S > > _______________________________________________ > 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: "Yaakov Stein" Subject: RE: RTP-based clock recovery (was: no subject) Date: Mon, 14 Jul 2003 12:08:39 +0300 Lines: 84 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Mon Jul 14 11:09:10 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RTP-based clock recovery (was: no subject) Thread-Index: AcNJ5A2ZrLFIFA41RLmrVWOhC5v4VwAAatsg To: "Alexander Vainshtein" 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 > > I'm a newcomer to this discussion, and I would like to know whether > > > there have already been some discussions addressing the=20 > > > synchronization issue, in an asynchronous scenario as it is = described in=20 > > > section 4.3.3 of draft-ietf-pwe3-tdm-requirements-01? > > > My concern is related to the required processing to implement when > > > providing 2Mbit/s E1 interface circuit emulation service. > > > Is there some means such as ATM AAL1 SRTS foreseen to answer=20 > > > to this issue? > >=20 > > Your question needs to be answered in two parts. > >=20 > > In the usual case there is no common clock, available to both=20 > > ingress and egress. > > In this case some adaptive clock recovery must be performed. > > There are numerous algorithms for this purpose, > > and they CAN conform to internationally recognized jitter and=20 > > wander constraints. > >=20 > This is a very interesting statement. It seems to be commonly=20 > recognized that adaptive clock recovery methods cope well with the=20 > jitter problems but are problematic wrt wander. At least, this was the = basis=20 > behind introducing SRTS in ATM-CES.=20 It is true that at the time AAL1 was developed, it was assumed that it = would be difficult to maintain the wander as prescribed in G.823.4. However, the technology has progressed a lot since then. If you wish I can show you actual MRTIE plots well under mask for up to 20 ms PDV. > > > > If a common clock is somehow available to both ingress and egress > > (e.g. from GPS or from the physical layer of a single-hop optical = link) > > then RTP (for CESoPSN) or SRTS (for TDMoIP) may be used. > > RTP provides a layer-4 timestamp, > > while the SRTS provides a layer-2 residual timestamp. > >=20 > Some news here! After years of publicly stating the opposite=20 > you seem to recognize that there is some added value in RTP!=20 I acknowledge the usefulness of a common clock. I just don't think it is a common situation. Also, I don't think RTP is the right way to exploit this clock (and I can prove that RTP is not the optimal way to recover it). =20 > I am afraid do not understand your reference to "Layer 4" and "Layer = 2"=20 > timestamps, especially in conjunction with TDMoIP.=20 Layer 4 is the RTP timestamp, Layer 2 is if you use AAL1 with SRTS (assuming a common clock - but not necessarily the physical layer one) or a layer 2 timestamp in Ethernet as is now being suggested in several forums. > I'd also like to notice that a scan of draft-anavi-05 (the=20 > latest available) has failed=20 > to detect any reference to SRTS there but did produce some=20 > hits on RTP - in fact, it has found Section 2.3. called "RTP"... And as you have said, I have been complaining about having been coerced into including that section. Regarding your first point, any mechanism that works with=20 AAL1 can be used with the AAL1 mode of TDMoIP. I never detailed SRTS since, as I mentioned before, I don't think the case that ingress and egress both have access to some common clock, is a common one. However, things are changing.=20 We have deployed systems that use GSM as a common clock, and are about to employ one that uses GPS. In addition, we have tried out locking the ethernet PHY, and that works too (but beware - there is IPR on this idea). =20 Also, ITU SG15 is working on adding physical layer clock to all-optical physical layers. So in all these cases SRTS should be considered. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: Status signaling in draft-ietf-pwe3-control-protocol-03.txt Date: Mon, 14 Jul 2003 06:33:17 -0600 Organization: Level3 Communications LLC. Lines: 274 Sender: pwe3-admin@ietf.org References: 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 Jul 14 14:41:53 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: Italian [it],French/Canada [fr- To: Hamid Ould-Brahim 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 Hamid Ould-Brahim wrote: > Comments on section 5.3 Status Signaling added > to the new revised version of the control draft. > > It looks to me some of the issues that were raised before in the mailing > list were ignored...Here are some items observed on the added > text: > > a) There is no mechanism (implicit/explicit) by which a PE will find > out what is the capability/intent of the remote PE (whether it supports > status TLV or not). This point did not get enough support. We do not feel that we need a protocol to decide if the PW status notification message is used or not. For backward compatibility an implementation specific local setting can definitely be used to achieve the correct behavior. > > b) There is no mechanism by which a PE can find out initially what > is the status of PW during PW setup phase. Upon receiving a label > mapping, > the PE assumes the PW is up and starts accepting and sending traffic that > > will end up being discarded if the remote end is down. And that happens > even if both PEs support status signaling. One may wonder what is > then the value of status signaling if it can't stop a remote PE from > sending traffic. First, if a mapping is received , it does mean then that PE that sent the mapping is ready to transmit. ALso please note that a PW status notification message indicating some other status ( other then the default one of "ready and working " ) can be sent together with the label mapping in the same LDP PDU. > > c) Ambiguity for the encoding for both the basic LDP notification and > status TLV (see below). This point is not clear. the PW tlv is different from the status tlv message. Where is the ambiguity ? As far as the length message , 0 has always meant only the group ID. This is what is currently implemented. the length field does not measure the length of the group ID as it is fixed. > d) The proposal seems not backward compatible with > existing PW behavior and that needs to be explicitly captured in > the draft. And there is no mechanism that enforces the rule requiring > both PEs to support status signaling in order for the proposal to work. > Yes I agree with this point. The question is how much backward compatibility complexity do we need to include in this protocol ? The most widely deployed implementation is ethernet , and status not very useful for ethernet vlan mode.... Thanks. Luca > See other comments below (on the added text) > > > "5.3. Signaling of Pseudo Wire Status > > 5.3.1. Use of Label Mappings. > > The PEs MUST send PW label mapping messages to their peers as soon as > the PW is configured and administratively enabled, regardless of the > CE-facing interface state. The PW label should not be withdrawn > unless the user administratively configures the CE-facing interface > down (or the PW configuration is deleted entirely). A simple label > withdraw method MAY also be supported as an alternative. In any case > if the Label mapping is not available the PW MUST be considered in > the down state." > > Hamid> The question is what is the behavior of the remote end that doesn't > support status signaling? For the *PW* to be in down state the > *two* sides of the PW should not forward customer traffic. > > Even if we assume that there is a rule that says "A notification > message > MUST always be sent after the label mapping message" which in the > text there is none. That does not prevent the above problem from > happening, and the provider will perform billing/accounting for > traffic > that will end up being discarded at the remote PE. > > And if this rule is applied this proposal forces all PWs to send > notification messages to all PEs that do not support status > signaling. > > If another rule indicates that a PE should not accept initially > traffic until positive notification is received, then the problem > that can happen is a deadlock situation. > > ..... > > more on the text: > > "The format of the Notification Message is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW FEC TLV or Generalized ID FEC Element | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" > > Hamid> If we reconstruct the complete message for PWid FEC, > we obtain the following: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW tlv |C| PW type |PW info Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Group ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW Status (0x0???) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > (No parameters are carried as suggested). > > Basic LDP the notification message looks like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |U|F| Status (0x0300) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>From that I conclude that: > > a) A PE cannot distinguish between PE Status signaling and basic > LDP status signaling. This is ambiguity (even in parsing the > message). I do not expect this is acceptable. > > b) All LDP notification messages must carry PW Status information. > I do not expect this is acceptable either. > > In the text as well: > > > "As mentioned above the Group ID field can be used to send a status > notification for all PWs associated with a particular group ID. This > procedure is OPTIONAL, and if it is implemented the LDP Notification > message should be as follows: the PW information length field is set > to 0, the PW ID field is not present, and the interface parameters > field is not present. For the purpose of this document this is called > the "wild card PW status notification procedure", and all PEs > implementing this design are REQUIRED to accept such a notification > message, but are not required to send it." > > Hamid> If PW information length field is 0 then the GROUP ID field doesn't > exist either. If the proposal implies that when PW length field > is 0 it means there are fields that are present such as GROUP_ID > and status field then the length field > is no longer a length field but a type field where 0x00 value is > reversed. > I am not in favor of overloading the length field to represent a type > field. It is better to keep the length field to represent just length > field...(doing that will avoid later on reserving other length field > values to mean something else). > > Hamid. > > > > > >>-----Original Message----- >>From: Internet-Drafts@ietf.org [ > > mailto:Internet-Drafts@ietf.org] > >>Sent: Wednesday, July 02, 2003 4:33 PM >>Cc: pwe3@ietf.org >>Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-control-protocol-03.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >>This draft is a work item of the Pseudo Wire Emulation Edge >>to Edge Working Group of the IETF. >> >> Title : Pseudowire Setup and Maintenance using LDP >> Author(s) : L. Martini, N. El-Aawar, E. Rosen >> Filename : draft-ietf-pwe3-control-protocol-03.txt >> Pages : 29 >> Date : 2003-7-2 >> >>Layer 2 services (such as Frame Relay, ATM, ethernet) can be >>'emulated' over an IP and/or MPLS backbone by encapsulating the layer >>2 PDUs and then transmitting them over 'pseudowires'. It is also >>possible to use pseudowires to provide SONET circuit emulation over >>an IP and/or MPLS network. This document specifies a protocol for >>establishing and maintaining the pseudowires, using extensions to >>LDP. Procedures for encapsulating layer 2 PDUs are specified in a >>set of companion documents. >> >>A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-pr > otocol-03.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-control-protocol-03.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-control-protocol-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: Status signaling in draft-ietf-pwe3-control-protocol-0 3.txt Date: Mon, 14 Jul 2003 10:39:06 -0400 Lines: 20 Sender: pwe3-admin@ietf.org Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jul 14 16:39:40 2003 Return-path: To: "'Luca Martini'" , "Hamid Ould-Brahim" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca: > > a) There is no mechanism (implicit/explicit) by which a PE will find > > out what is the capability/intent of the remote PE > (whether it supports > > status TLV or not). > This point did not get enough support. We do not feel that we > need a protocol > to decide if the PW status notification message is used or > not. For backward compatibility an implementation specific > local setting can > definitely be used to achieve the correct behavior. This adds to a providers provisioning burden in any sort of multi-vendor or multi-provider network. Consider this support for a negotiation option. cheers Dave From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Jim Harford Subject: ATM Forum Liaison Date: Mon, 14 Jul 2003 10:58:03 -0400 Lines: 69 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_210230953==_.ALT" X-From: pwe3-admin@ietf.org Mon Jul 14 17:01:46 2003 Return-path: X-Sender: harford2/atmware.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: pwe3@ietf.org X-Declude-Sender: harford2@atmware.com [209.42.226.217] 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 --=====================_210230953==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The ATM Forum is sending the following liaison to the IETF PWE3 working group. Let me know if you have any questions. Jim Harford AIC Chair, ATM Forum ===================================================================================================== Gentlemen: The ATM Forum met during the second week of July. We are pleased to announce that we are sending the following three documents to final ballot: 1. Version 2 of our ATM-MPLS Network Interworking specification, which is currently aligned with draft-ietf-pwe3-atm-encap-02.txt. 2. A new specification addressing N-to-one mode, as defined in ITU-T Recommendation Y.1411, which is currently aligned with draft-ietf-pwe3-atm-encap-02.txt. 3. A new specification extending PNNI to establish MPLS interworking labels. Copies of these specifications can be obtained by sending an email request to chair-aic@atmforum.com. We would appreciate you keeping us informed of your activities in these areas. The next meeting of the ATM Forum will be October 13 - 17 in London, U.K. --=====================_210230953==_.ALT Content-Type: text/html; charset="us-ascii"
The ATM Forum is sending the following liaison to the IETF PWE3 working group.  Let me know if you have any questions.

Jim Harford
AIC Chair,  ATM Forum

=====================================================================================================

Gentlemen:
The ATM Forum met during the second week of July.  We are pleased to announce that we are sending the following three documents to final ballot:
   1. Version 2 of our ATM-MPLS Network Interworking specification, which is currently aligned with draft-ietf-pwe3-atm-encap-02.txt.
   2. A new specification addressing N-to-one mode, as defined in ITU-T Recommendation Y.1411, which is currently aligned with draft-ietf-pwe3-atm-encap-02.txt.
   3. A new specification extending PNNI to establish MPLS interworking labels.

Copies of these specifications can be obtained by sending an email request to chair-aic@atmforum.com.

We would appreciate you keeping us informed of your activities in these areas.  The next meeting of the ATM Forum will be October 13 - 17 in London, U.K.
 --=====================_210230953==_.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Mon, 14 Jul 2003 16:39:53 +0100 Organization: Cisco Systems, Inc. Lines: 42 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 Mon Jul 14 17:41:39 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 The only last call issue with draft-ietf-pwe3-arch-04.txt that I am aware of is Andy's comment WRT 5.4.4 I propose the following revised text, which defines the protocol authority identifier. Is there consensus for this change? Have I missed any other issues with the draft? Stewart 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. The MPLS payload type is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PA | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: MPLS Payload Type Identifier PA protocol authority for the user plane or the control plane protocol ID 0 = PPP DLL 1-15 = Reserved Protocol ID Protocol ID following the format defined by the protocol authority identified in PA. Bits 4 to 11 inclusive are reserved for future use and must be zero. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Mon, 14 Jul 2003 20:10:33 +0200 Lines: 94 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jul 14 19:15:14 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 Stewart, One minor comment. I seem to remember that ability to distinguish between PW data packets and PW OAM packets has been mentioned as one of the possible applications of the "MPLS PID" in the corresponding email thread. Taking this into account, why should bits 0-3 of the MPLS PID be set to '0001' and not '0000' (for data)/'0001' (for OAM)? IMO it would not have any impact on the P routers' ability to distinguish PW packets (data and OAM) from IPv4/IPv6 packets (which has been the original drive for MPLS PID). ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, July 14, 2003 5:40 PM > To: pwe3@ietf.org > Subject: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > > The only last call issue with draft-ietf-pwe3-arch-04.txt > that I am aware > of is Andy's comment WRT 5.4.4 > > I propose the following revised text, which defines the > protocol authority > identifier. > > Is there consensus for this change? > > Have I missed any other issues with the draft? > > Stewart > > 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. > > The MPLS payload type is defined as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved = 0 | PA | Protocol > ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol definition > | > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: MPLS Payload Type Identifier > > PA protocol authority for the user plane or the > control plane > protocol ID > 0 = PPP DLL > 1-15 = Reserved > > Protocol ID > Protocol ID following the format defined by the protocol > authority identified in PA. > > Bits 4 to 11 inclusive are reserved for future use and > must be zero. > > > > > > _______________________________________________ > 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: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Mon, 14 Jul 2003 19:22:49 +0100 Organization: Cisco Systems, Inc. Lines: 112 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Jul 14 20:23:57 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: Sasha Vainshtein Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha Vainshtein wrote: > Stewart, > One minor comment. > I seem to remember that ability to distinguish between PW data packets > and PW OAM packets has been mentioned as one of the possible applications > of the "MPLS PID" in the corresponding email thread. > > Taking this into account, why should bits 0-3 of the MPLS PID be set to > '0001' and not '0000' (for data)/'0001' (for OAM)? Because there is one CW (SONET) that is not ECMP safe, so some data packets will have the PID. Stewart > > IMO it would not have any impact on the P routers' ability to distinguish > PW packets (data and OAM) from IPv4/IPv6 packets (which has been the > original > drive for MPLS PID). > > ---------------------------------------------------------------------------- > -------- > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Monday, July 14, 2003 5:40 PM >>To: pwe3@ietf.org >>Subject: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 >> >> >>The only last call issue with draft-ietf-pwe3-arch-04.txt >>that I am aware >>of is Andy's comment WRT 5.4.4 >> >>I propose the following revised text, which defines the >>protocol authority >>identifier. >> >>Is there consensus for this change? >> >>Have I missed any other issues with the draft? >> >>Stewart >> >>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. >> >> The MPLS payload type is defined as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>6 7 8 9 0 1 >> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 1| reserved = 0 | PA | Protocol >>ID | >> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | As defined by PPP DLL protocol definition >> | >> | >> | >> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 14: MPLS Payload Type Identifier >> >> PA protocol authority for the user plane or the >>control plane >> protocol ID >> 0 = PPP DLL >> 1-15 = Reserved >> >> Protocol ID >> Protocol ID following the format defined by the protocol >> authority identified in PA. >> >> Bits 4 to 11 inclusive are reserved for future use and >>must be zero. >> >> >> >> >> >>_______________________________________________ >>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: "Thomas D. Nadeau" Subject: Location of draft-nadeau-pwe3-vccv-01.txt Date: Tue, 15 Jul 2003 04:03:22 -0400 Organization: Cisco Systems Lines: 10 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Tue Jul 15 10:05:13 2003 Return-path: To: "'PWE3 WG \(E-mail\)'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: 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 Due to some mis-communication on my part with the I-D editor, the version 01 of VCCV did not make it into the I-D repository despite being published before the I-D cut-off. In the meantime, the draft can be found here: ftp://ftp-eng.cisco.com/tnadeau/draft-nadeau-pwe3-vccv-01.txt --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: PWE3 aganda revised to include update from Luca Date: Tue, 15 Jul 2003 09:26:30 +0100 Organization: Cisco Systems, Inc. Lines: 88 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 Tue Jul 15 10:27:08 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" , agenda@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 Pseudo Wire Emulation Edge to Edge WG (pwe3) Wednesday, July 16 at 1530-1730 =============================== CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: 1530-1540 Administrivia "Stewart Bryant" Agenda Bashing Minutes Blue Sheets "Danny McPherson" WG Document Status 1540-1550 "Thomas Narten" PWE3 move to Internet Area 1550-1600 "Thomas Nadeau" Discuss issues brought up on the mailing list since the last meeting, as well as discuss diffs between version 00 and 01. Specifically, additions to support L2TPv3. http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-01.txt 1600-1610 "Mustapha Aissaoui" http://www.ietf.org/internet-drafts/draft-aissaoui-extended-pid-00.txt 1610-1625 "Dave Allan" http://www.ietf.org/internet-drafts/draft-allan-mpls-a-bit-00.txt http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt 1625-1635 "Sasha Vainshtein" Technical issues with draft-vainshtein-cesopsn-06.txt raised during the discussion on the WG list" http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt 1635-1645 "Yaakov Stein" http://www.ietf.org/internet-drafts/draft-stein-pwe3-stpp-00.txt 1645-1655 "Danny McPherson" "Stewart Bryant" Discussion: Getting Traction on TDM 1655-1705 Luca Martini draft-ietf-pwe3-control-protocol-03.txt draft-ietf-pwe3-ethernet-encap-03.txt draft-ietf-pwe3-iana-allocation-01.txt draft-ietf-pwe3-atm-encap-02.txt 1705-1715 "Himanshu Shah" http://www.ietf.org/internet-drafts/ draft-shah-pwe3-control-protocol-extension-01.txt 1715-1725 "Ghassem Koleyni" Update on activities in ITU-T SG13 regarding interworking topics 1725-1730 Wrap-up From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: MPLS Payload Identifier Date: Tue, 15 Jul 2003 09:44:06 +0100 Organization: Cisco Systems, Inc. Lines: 16 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 Tue Jul 15 10:44:09 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 Following strong feedback* from the MPLS WG, I propose that in draft-ietf-pwe3-arch-05.txt we rename the term: "MPLS Payload Identifier" to be "PWE3 Payload Type". If there are no objections I will make the change in the -05 version of the draft. Stewart *The MPLS WG argue that a PID is not needed in MPLS, and hence they object to the name. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: Status signaling in draft-ietf-pwe3-control-protocol-0 3.txt Date: Tue, 15 Jul 2003 07:42:55 -0400 Lines: 32 Sender: pwe3-admin@ietf.org Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jul 15 13:45:07 2003 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, > > > > a) There is no mechanism (implicit/explicit) by which a PE will find > > out what is the capability/intent of the remote PE > (whether it supports > > status TLV or not). > This point did not get enough support. We do not feel that we > need a protocol > to decide if the PW status notification message is used or not. > For backward compatibility an implementation specific local > setting can > definitely be used to achieve the correct behavior. > The proposal assumes that both PEs have apriori knowledge that they both support status signaling (i.e., no capability signaling). This implies that the proposal works only for double-sided provisioning model and does not work for other provisioning models used in layer-2 VPNs such as a single-sided provisioning with an auto-discovery mechanism. In the case when a VPN auto-discovery is used, the PE does not have apriori knowledge of the remote PE it needs to establish a PW to, so it can't know whether that PE supports or not status signaling, therefore signaling the capability is one way of conveying that information. The status signaling should work with multiple provisioning models (that are as well supported by PW signaling draft). Hamid. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: D Siva Kumar Subject: doubt reg draft-kawakami-mpls-lsp-vlan-00.txt (fwd) Date: Wed, 16 Jul 2003 04:22:14 +0530 (IST) Lines: 36 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: pwe3-admin@ietf.org Wed Jul 16 01:06:12 2003 Return-path: To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, I have a doubt regarding encapsulation mentioned in above draft in section 4. Encapsulation header is shown in the draft as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ethernet source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPID 0x8100 | Pri | | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-Type 0x0800 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Network Layer Packet (IP packet) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But, in this where is the pseudowire label? directly, payload is added after the tunnel header. Correct me if I am wrong and please point some references if any, regarding this. I am a beginner in this field. expecting a reply, thanks in advance. Siva. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Alik Shimelmits Subject: STTP - slides for IETF-57 Date: Wed, 16 Jul 2003 03:11:28 +0200 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 16 02:17:19 2003 Return-path: To: Yaakov Stein 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 Yaakov, I just looked at your slides and very "emotional" description of CESoPSN. I would propose for fairness sake at least to mention that STTP actually for emulation of unstructured T1/E1 borrows CESoPSN approach, i.e. "raw encapsulation" and not AAL1-based. And I agree that it is simple approach. That somehow contradicts with draft-anavi-..-05, paragraph 4 that states: "Raw encapsulation is only advisable for high quality networks carrying unstructured TDM traffic... AAL1 is thus best for unstructured trunks...". CESoPSN is simple - you somehow mentioned on the list that RAD has implemented CESoPSN in its product as a "one-time effort to supply small remote boxes to interoperate with CESoPSN central site for a given sales opportunity" - I would say that this also means that it was relatively "simple" to implement that. Regards Alik From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: STTP - slides for IETF-57 Date: Wed, 16 Jul 2003 10:32:43 +0300 Lines: 156 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34B6C.71EB075F" Cc: X-From: pwe3-admin@ietf.org Wed Jul 16 09:34:12 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: STTP - slides for IETF-57 thread-index: AcNLL1y5gVo+FLH2SsearnuLREiIqQAO92NT To: "Alik Shimelmits" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C34B6C.71EB075F Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Alik,=20 > Yaakov, > I just looked at your slides and very "emotional" description of = CESoPSN. I wasn't aware of the emotional aspects. > I would propose for fairness sake at least to mention that STTP = actually for > emulation of unstructured T1/E1 borrows CESoPSN approach, i.e. "raw = encapsulation"=20 > and not AAL1-based. And I agree that it is simple approach. STPP is actually based on the raw mode of draft-anavi, (which has been there for a long time) i.e. it does not need any frame locking. I am glad that the latest draft-vainshtein has at long last come around to allowing this as well. I gave definite default values for payload sizes that are important for certain implementations. This was to make it easier for you to accept it. If this seems somehow improper to you, then I am much happier with a constant 256 bytes default length, or even better 47*N. > That somehow contradicts with draft-anavi-..-05, paragraph 4 that = states: > "Raw encapsulation is only advisable for high quality networks = carrying=20 > unstructured TDM traffic... AAL1 is thus best for unstructured = trunks...".=20 It is an attempt at a compromise mode for CERTAIN CASES. I still say that when the going gets hard (i.e. network imperfections, CAS signaling, etc) it is insufficient. But, for a large subset of cases STPP is good enough. > CESoPSN is simple - you somehow mentioned on the list that RAD has = implemented > CESoPSN in its product as a "one-time effort to supply small remote=20 > boxes to interoperate with CESoPSN central site for a given sales = opportunity" -=20 > I would say that this also means that it was relatively "simple" to = implement that. Actually, as you well know, it wasn't as easy as we expected, and we needed the help of an Axerra engineer to get it interoperable. How to handle the RTP was a particularly sticky issue. STPP is truly simple - just chop any hunk of TDM, stick on a control word and ship it out.=20 I added a few constrictions to get your support. Y(J)S ------_=_NextPart_001_01C34B6C.71EB075F Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: STTP - slides for IETF-57

Alik,


> Yaakov,
> I just looked at your slides and very "emotional" = description of CESoPSN.

I wasn't aware of the emotional aspects.

> I would propose for fairness sake at least to mention that STTP = actually for
> emulation of unstructured T1/E1 borrows CESoPSN approach, i.e. = "raw encapsulation"
> and not AAL1-based. And I agree that it is simple approach.

STPP is actually based on the raw mode of draft-anavi,
(which has been there for a long time)
i.e. it does not need any frame locking.
I am glad that the latest draft-vainshtein
has at long last come around to allowing this as well.

I gave definite default values for payload sizes
that are important for certain implementations.
This was to make it easier for you to accept it.
If this seems somehow improper to you,
then I am much happier with a constant 256 bytes default length,
or even better 47*N.

> That somehow contradicts with draft-anavi-..-05, paragraph 4 that = states:
> "Raw encapsulation is only advisable for high quality networks = carrying
> unstructured TDM traffic... AAL1 is thus best for unstructured = trunks...".

It is an attempt at a compromise mode for CERTAIN CASES.
I still say that when the going gets hard (i.e. network = imperfections,
CAS signaling, etc) it is insufficient.
But, for a large subset of cases STPP is good enough.

> CESoPSN is simple - you somehow mentioned on the list that RAD has = implemented
> CESoPSN in its product as a "one-time effort to supply small = remote
> boxes to interoperate with CESoPSN central site for a given sales = opportunity" -
> I would say that this also means that it was relatively = "simple" to implement that.

Actually, as you well know, it wasn't as easy as we expected,
and we needed the help of an Axerra engineer to get it = interoperable.
How to handle the RTP was a particularly sticky issue.

STPP is truly simple - just chop any hunk of TDM,
stick on a control word and ship it out.
I added a few constrictions to get your support.

Y(J)S

------_=_NextPart_001_01C34B6C.71EB075F-- 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, 16 Jul 2003 03:33:51 -0400 Organization: Alcatel Networks Corporaton Lines: 110 Sender: pwe3-admin@ietf.org References: <3F12CEC9.6010505@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 Wed Jul 16 09:35:06 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: stbryant@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, this looks good to me. It allows future extensions such as the one described in draft-aissaoui-extended-pid. One minor editorial comment though. I would prefer to add the generic format of the payload identifier as follows: 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. The generic format for the MPLS payload type is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| rsvd. | PA | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Generic MPLS Payload Type Identifier PA = protocol authority for the user plane or the control plane protocol ID 0 = PPP DLL. 1-15 = Reserved Protocol ID = Protocol ID following the format defined by the protocol authority identified in PA. Bits 4 to 11 inclusive are reserved for future use and must be zero. The specific format for resolving the IP aliasing uses PA = 0: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PA=0 | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Specific MPLS Payload Type Identifier Regards, Mustapha. ------------ Stewart Bryant wrote: > > The only last call issue with draft-ietf-pwe3-arch-04.txt that I am aware > of is Andy's comment WRT 5.4.4 > > I propose the following revised text, which defines the protocol authority > identifier. > > Is there consensus for this change? > > Have I missed any other issues with the draft? > > Stewart > > 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. > > The MPLS payload type is defined as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved = 0 | PA | Protocol ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol definition | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: MPLS Payload Type Identifier > > PA protocol authority for the user plane or the control plane > protocol ID > 0 = PPP DLL > 1-15 = Reserved > > Protocol ID > Protocol ID following the format defined by the protocol > authority identified in PA. > > Bits 4 to 11 inclusive are reserved for future use and must be zero. > > _______________________________________________ > 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: George Swallow Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 16 Jul 2003 04:24:44 -0400 Lines: 17 Sender: pwe3-admin@ietf.org References: <3F14FFDF.171CBC61@alcatel.com> Cc: stbryant@cisco.com, "pwe3@ietf.org" , swallow@cisco.com X-From: pwe3-admin@ietf.org Wed Jul 16 10:25:10 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Mustapha Aissaoui In-reply-to: Your message of "Wed, 16 Jul 2003 03:33:51 EDT." <3F14FFDF.171CBC61@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 > 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 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, 16 Jul 2003 04:42:49 -0400 Organization: Alcatel Networks Corporaton Lines: 34 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Wed Jul 16 10:44:11 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: George Swallow 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 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 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 16 Jul 2003 05:14:54 -0600 Organization: Level3 Communications LLC. Lines: 47 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> <3F151009.B738C6EA@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: George Swallow , stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Wed Jul 16 13:26:12 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: Italian [it],French/Canada [fr- To: Mustapha Aissaoui 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 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 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: Status signaling in draft-ietf-pwe3-control-protocol-0 3.txt Date: Wed, 16 Jul 2003 05:21:21 -0600 Organization: Level3 Communications LLC. Lines: 51 Sender: pwe3-admin@ietf.org References: 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 Wed Jul 16 13:28:04 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: Italian [it],French/Canada [fr- To: Hamid Ould-Brahim 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, As I said before I am not completely opposed to have some kind of status indication negotiation. However please note that the current proposal makes status signaling mandatory , or PW status will not work. So in the current proposal , if a ISP need PW status signaling all devices in the network must support this PW status notification message. Note that in some network/technologies this might not be a requirement. we will talk about this in the meeting this afternoon. Luca Hamid Ould-Brahim wrote: > Luca, > > >>>a) There is no mechanism (implicit/explicit) by which a PE will find >>> out what is the capability/intent of the remote PE >> >>(whether it supports >> >>> status TLV or not). >> >>This point did not get enough support. We do not feel that we >>need a protocol >>to decide if the PW status notification message is used or not. >>For backward compatibility an implementation specific local >>setting can >>definitely be used to achieve the correct behavior. >> > > > The proposal assumes that both PEs have apriori knowledge > that they both support status signaling (i.e., no capability signaling). > This implies that the proposal works only for double-sided > provisioning model and does not work for other > provisioning models used in layer-2 VPNs such as a single-sided > provisioning with an auto-discovery mechanism. > > In the case when a VPN auto-discovery is used, the PE does not > have apriori knowledge of the remote PE it needs to > establish a PW to, so it can't know whether that PE > supports or not status signaling, therefore signaling the capability > is one way of conveying that information. > > The status signaling should work with multiple provisioning > models (that are as well supported by PW signaling draft). > > Hamid. > 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, 16 Jul 2003 08:05:26 -0400 Organization: Alcatel Networks Corporaton Lines: 61 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> <3F151009.B738C6EA@alcatel.com> <3F1533AE.3080608@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: George Swallow , stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Wed Jul 16 14:06:10 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Luca Martini Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 16 Jul 2003 08:23:06 -0400 Organization: Cisco Systems Lines: 52 Sender: pwe3-admin@ietf.org References: <3F151009.B738C6EA@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , X-From: pwe3-admin@ietf.org Wed Jul 16 14:24:59 2003 Return-path: To: "'Mustapha Aissaoui'" , "'George Swallow'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F151009.B738C6EA@alcatel.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 > 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 thought that interworking was out of the scope in PWE3? --Tom > > 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 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 16 Jul 2003 08:26:13 -0400 Organization: Cisco Systems Lines: 65 Sender: pwe3-admin@ietf.org References: <3F151009.B738C6EA@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , X-From: pwe3-admin@ietf.org Wed Jul 16 14:27:05 2003 Return-path: To: "'Mustapha Aissaoui'" , "'George Swallow'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F151009.B738C6EA@alcatel.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 One other point. It seems to me that an MPLS label can be used to indicate the VC and its type, since the PE would have had to signal the VC originally. It doesn't seem to me that this added overhead is useful. --Tom > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mustapha Aissaoui > Sent: Wednesday, July 16, 2003 4:43 AM > To: George Swallow > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > > 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 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: Status signaling in draft-ietf-pwe3-control-protocol-0 3.txt Date: Wed, 16 Jul 2003 09:16:53 -0400 Lines: 68 Sender: pwe3-admin@ietf.org Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 16 15:20:36 2003 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, > > > yes, > As I said before I am not completely opposed to have some > kind of status > indication negotiation. > However please note that the current proposal makes status > signaling mandatory > , or PW status will not work. > So in the current proposal , if a ISP need PW status > signaling all devices in > the network must support this PW status notification message. > Note that in some > network/technologies this might not be a requirement. > we will talk about this in the meeting this afternoon. > Agreed. Hamid. > > Hamid Ould-Brahim wrote: > > Luca, > > > > > >>>a) There is no mechanism (implicit/explicit) by which a PE > will find > >>> out what is the capability/intent of the remote PE > >> > >>(whether it supports > >> > >>> status TLV or not). > >> > >>This point did not get enough support. We do not feel that we > >>need a protocol > >>to decide if the PW status notification message is used or not. > >>For backward compatibility an implementation specific local > >>setting can > >>definitely be used to achieve the correct behavior. > >> > > > > > > The proposal assumes that both PEs have apriori knowledge > > that they both support status signaling (i.e., no > capability signaling). > > This implies that the proposal works only for double-sided > > provisioning model and does not work for other > > provisioning models used in layer-2 VPNs such as a single-sided > > provisioning with an auto-discovery mechanism. > > > > In the case when a VPN auto-discovery is used, the PE does not > > have apriori knowledge of the remote PE it needs to > > establish a PW to, so it can't know whether that PE > > supports or not status signaling, therefore signaling the capability > > is one way of conveying that information. > > > > The status signaling should work with multiple provisioning > > models (that are as well supported by PW signaling draft). > > > > Hamid. > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Wed, 16 Jul 2003 09:50:32 -0400 Organization: Cisco Systems Lines: 9 Sender: pwe3-admin@ietf.org References: <3F153F86.7CA304C0@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'George Swallow'" , , "'Danny McPherson'" , "'Monique Morrow \(mmorrow\)'" X-From: pwe3-admin@ietf.org Wed Jul 16 15:51:07 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F153F86.7CA304C0@alcatel.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 There was a good show of hands (fronts only) in favor of support to adopt the draft-nadeau-pwe3-vccv-01.txt as a PWE3 working group document, and none against. The chairs asked that we "take it to the list" to confirm. --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Wed, 16 Jul 2003 09:54:25 -0400 Lines: 101 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34BA1.A9CAF336" Cc: "'George Swallow'" , stbryant@cisco.com, "'Danny McPherson'" , "'Monique Morrow (mmorrow)'" X-From: pwe3-admin@ietf.org Wed Jul 16 15:58:47 2003 Return-path: To: "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34BA1.A9CAF336 Content-Type: text/plain; charset="iso-8859-1" None Tom????? Were we in the same room? > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, July 16, 2003 9:51 AM > To: pwe3@ietf.org > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; > 'Monique Morrow (mmorrow)' > Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? > > > > There was a good show of hands > (fronts only) in favor of support to adopt > the draft-nadeau-pwe3-vccv-01.txt as a > PWE3 working group document, and none > against. The chairs asked that we "take > it to the list" to confirm. > > --Tom > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C34BA1.A9CAF336 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG = document?

None Tom????? Were we in the same room?


> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Wednesday, July 16, 2003 9:51 AM
> To: pwe3@ietf.org
> Cc: 'George Swallow'; stbryant@cisco.com; = 'Danny McPherson';
> 'Monique Morrow (mmorrow)'
> Subject: [PWE3] Accept = draft-nadeau-pwe3-vccv-01.txt as a WG document?
>
>
>
>       There was a good = show of hands
> (fronts only) in favor of support to adopt =
> the draft-nadeau-pwe3-vccv-01.txt as a
> PWE3 working group document, and none
> against. The chairs asked that we "take =
> it to the list" to confirm.
>
>       --Tom
>
>
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C34BA1.A9CAF336-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Re: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Wed, 16 Jul 2003 07:56:18 -0600 Lines: 23 Sender: pwe3-admin@ietf.org References: <00f801c34ba1$3d7065e0$44d9a051@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Jul 16 16:01:42 2003 Return-path: User-Agent: Microsoft-Entourage/10.1.1.2418 To: In-Reply-To: <00f801c34ba1$3d7065e0$44d9a051@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 Although I didn't see any hands it seems there may have been one (some). If anyone has objections to adopting VCCV as a WG item please speak say so now. -danny On 7/16/03 7:50 AM, "Thomas D. Nadeau" wrote: > > There was a good show of hands > (fronts only) in favor of support to adopt > the draft-nadeau-pwe3-vccv-01.txt as a > PWE3 working group document, and none > against. The chairs asked that we "take > it to the list" to confirm. > > --Tom > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Wed, 16 Jul 2003 10:07:34 -0400 Organization: Cisco Systems Lines: 50 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'George Swallow'" , , "'Danny McPherson'" , "'Monique Morrow \(mmorrow\)'" X-From: pwe3-admin@ietf.org Wed Jul 16 16:08:04 2003 Return-path: To: "'David Allan'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O My appologies. I might not have seen you when I looked around. --Tom > -----Original Message----- > From: David Allan [mailto:dallan@nortelnetworks.com] > Sent: Wednesday, July 16, 2003 9:54 AM > To: 'tnadeau@cisco.com'; pwe3@ietf.org > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; > 'Monique Morrow (mmorrow)' > Subject: RE: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > WG document? > > > None Tom????? Were we in the same room? > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Wednesday, July 16, 2003 9:51 AM > > To: pwe3@ietf.org > > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; > > 'Monique Morrow (mmorrow)' > > Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > WG document? > > > > > > > > There was a good show of hands > > (fronts only) in favor of support to adopt > > the draft-nadeau-pwe3-vccv-01.txt as a > > PWE3 working group document, and none > > against. The chairs asked that we "take > > it to the list" to confirm. > > > > --Tom > > > > > > > > > > _______________________________________________ > > 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: "David Allan" Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Wed, 16 Jul 2003 10:26:20 -0400 Lines: 74 Sender: pwe3-admin@ietf.org Cc: "'George Swallow'" , stbryant@cisco.com, "'Danny McPherson'" , "'Monique Morrow (mmorrow)'" X-From: pwe3-admin@ietf.org Wed Jul 16 16:36:23 2003 Return-path: To: "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O There was other than me that I saw...presumably if they have an issue, they'll speak up. My concern would be how the L2TP aspects are coordinated with that WG if there are LSP-PING modifications specifically for L2TP. VCCV currently adopts MPLS and IP tools that are sourced elsewhere. I'd appreciate if Mark T. or some other suitably qualified individual commented. cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, July 16, 2003 10:08 AM > To: Allan, David [CAR:NS00:EXCH]; pwe3@ietf.org > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; > 'Monique Morrow (mmorrow)' > Subject: RE: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > WG document? > > > > My appologies. I might not have seen > you when I looked around. > > --Tom > > > > -----Original Message----- > > From: David Allan [mailto:dallan@nortelnetworks.com] > > Sent: Wednesday, July 16, 2003 9:54 AM > > To: 'tnadeau@cisco.com'; pwe3@ietf.org > > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; > > 'Monique Morrow (mmorrow)' > > Subject: RE: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > > WG document? > > > > > > None Tom????? Were we in the same room? > > > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Wednesday, July 16, 2003 9:51 AM > > > To: pwe3@ietf.org > > > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; > > > 'Monique Morrow (mmorrow)' > > > Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > > WG document? > > > > > > > > > > > > There was a good show of hands > > > (fronts only) in favor of support to adopt > > > the draft-nadeau-pwe3-vccv-01.txt as a > > > PWE3 working group document, and none > > > against. The chairs asked that we "take > > > it to the list" to confirm. > > > > > > --Tom > > > > > > > > > > > > > > > _______________________________________________ > > > 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: neil.2.harrison@bt.com Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Wed, 16 Jul 2003 18:47:21 +0100 Lines: 148 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34BC2.4D6BB416" Cc: swallow@cisco.com, stbryant@cisco.com, danny@tcb.net, mmorrow@cisco.com X-From: pwe3-admin@ietf.org Wed Jul 16 19:48:06 2003 Return-path: To: dallan@nortelnetworks.com, tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C34BC2.4D6BB416 Content-Type: text/plain; charset="iso-8859-1" Tom....just so you are clear....we don't want any of this stuff. We want to manage the *LSPs* in a consistent manner *irrespective* of the client. The PWE3 stuff is now completely overblown...what ought to be simple client->server adaptation has now too many functional components. None of which are strictly required *if* the truly broken stuff (which lies elsewhere) is deprecated, and we accept that MPLS is not = IP...if not true why bother with MPLS at all? There are no sound arch reasons why XoverIP must be the same as XoverMPLS....and IP and MPLS can provide different functional behaviours and this 'good' not 'bad'. We'll live with the problems of LDP mp2p for now, but please don't keep building on them like this is 'right' for the future. I am particulary curious to know why, for p2p LSPs, you can't accept Y.1711 as a solution (and which is complete in terms of defects and availability definitions) but instead feel compelled to draft a further OAM solution for the 'adapatation' layer (which is far from complete)......and which as I stated should have very little functionality of this sort anyway. regards, Neil -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: 16 July 2003 14:54 To: 'tnadeau@cisco.com'; pwe3@ietf.org Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; 'Monique Morrow (mmorrow)' Subject: RE: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? None Tom????? Were we in the same room? > -----Original Message----- > From: Thomas D. Nadeau [ mailto:tnadeau@cisco.com ] > Sent: Wednesday, July 16, 2003 9:51 AM > To: pwe3@ietf.org > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; > 'Monique Morrow (mmorrow)' > Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? > > > > There was a good show of hands > (fronts only) in favor of support to adopt > the draft-nadeau-pwe3-vccv-01.txt as a > PWE3 working group document, and none > against. The chairs asked that we "take > it to the list" to confirm. > > --Tom > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C34BC2.4D6BB416 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG document?
Tom....just so you are clear....we don't want any of this stuff.  We want to manage the *LSPs* in a consistent manner *irrespective* of the client.  The PWE3 stuff is now completely overblown...what ought to be simple client->server adaptation has now too many functional components.  None of which are strictly required *if* the truly broken stuff (which lies elsewhere) is deprecated, and we accept that MPLS is not = IP...if not true why bother with MPLS at all?  There are no sound arch reasons why XoverIP must be the same as XoverMPLS....and IP and MPLS can provide different functional behaviours and this 'good' not 'bad'.
 
We'll live with the problems of LDP mp2p for now, but please don't keep building on them like this is 'right' for the future.
 
I am particulary curious to know why, for p2p LSPs, you can't accept Y.1711 as a solution (and which is complete in terms of defects and availability definitions) but instead feel compelled to draft a further OAM solution for the 'adapatation' layer (which is far from complete)......and which as I stated should have very little functionality of this sort anyway.
 
regards, Neil
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: 16 July 2003 14:54
To: 'tnadeau@cisco.com'; pwe3@ietf.org
Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; 'Monique Morrow (mmorrow)'
Subject: RE: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG document?

None Tom????? Were we in the same room?


> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Wednesday, July 16, 2003 9:51 AM
> To: pwe3@ietf.org
> Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson';
> 'Monique Morrow (mmorrow)'
> Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG document?
>
>
>
>       There was a good show of hands
> (fronts only) in favor of support to adopt
> the draft-nadeau-pwe3-vccv-01.txt as a
> PWE3 working group document, and none
> against. The chairs asked that we "take
> it to the list" to confirm.
>
>       --Tom
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C34BC2.4D6BB416-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 16 Jul 2003 18:47:22 +0100 Lines: 89 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 16 19:48:10 2003 Return-path: To: tnadeau@cisco.com, mustapha.aissaoui@alcatel.com, swallow@cisco.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 16 July 2003 13:23 > To: 'Mustapha Aissaoui'; 'George Swallow' > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > > > > 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 thought that interworking was out of the scope > in PWE3? > > --Tom NH=> So what if I say as an operator that interworking (both 'network' and 'service' types...and currently PWE3 is the former anyway) was pretty important? If bad solutions are forthcoming now in a restricted network-interworking case, then these may not be so useful to the larger service-interworking case. And, just to be further clear on what is the strategic/arch direction behind this comment, please note this: - there are 3 networking modes....cnls, co pkt-sw and co cct-sw; - all technologies map to one of these modes; - they are *all* needed because they all offer something different; - what we want is functional convergence *within* each mode (ie to stop stovepipes, avoid nasty gateways and reduce capex/opex....so edge service-interworking is key, hence my prior remarks), but what we don't want is functional convergence *across* the modes, ie specifically no GMPLS peer-model nonsense; - further, we want best-of-breed functions in each mode, and we will take solutions from whichever stds body/vendors are prepared to give us these. regards, Neil > > > > > 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: "Busschbach, Peter B (Peter)" Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Thu, 17 Jul 2003 04:51:50 -0400 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'George Swallow'" , stbryant@cisco.com, "'Danny McPherson'" , "'Monique Morrow (mmorrow)'" X-From: pwe3-admin@ietf.org Thu Jul 17 10:53:07 2003 Return-path: To: "'tnadeau@cisco.com'" , 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 Tom, I have two comments on the draft: 1) Regarding the MPLS case, I think there should be an option to indicate that the reply message should be sent over the "return LSP", i.e. the other half of the PW under test. The LSP-ping draft doesn't allow for the option to send a reply through the MPLS data plane, and hence the option should be added to the VCCV draft. 2) On the mailing list we discussed the option of uni-directional connectivity checks. This is covered by the "no-reply" option, which you explicitly mention in the draft. However, IMO you need a more complete description if you would want to use this option for propoer fault managent. E.g. (1) how do the sender and receiver agree on the frequency of sending messages; (2) when do you declare a failure? How many messages do you need to miss to conclude that the PW is down and how many messages do you need to receive to conclude that it is back up? Otherwise, I agree with making this draft a WG document. Peter > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, July 16, 2003 9:51 AM > To: pwe3@ietf.org > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny McPherson'; 'Monique > Morrow (mmorrow)' > Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? > > > > There was a good show of hands > (fronts only) in favor of support to adopt > the draft-nadeau-pwe3-vccv-01.txt as a > PWE3 working group document, and none > against. The chairs asked that we "take > it to the list" to confirm. > > --Tom > > > > > _______________________________________________ > 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: "Thomas D. Nadeau" Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Thu, 17 Jul 2003 07:11:25 -0400 Organization: Cisco Systems Lines: 69 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'George Swallow'" , , "'Danny McPherson'" , "'Monique Morrow \(mmorrow\)'" X-From: pwe3-admin@ietf.org Thu Jul 17 13:13:09 2003 Return-path: To: "'Busschbach, Peter B \(Peter\)'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: 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 Peter, > Tom, > > I have two comments on the draft: > > 1) Regarding the MPLS case, I think there should be an option > to indicate that the reply message should be sent over the > "return LSP", i.e. the other half of the PW under test. The > LSP-ping draft doesn't allow for the option to send a reply > through the MPLS data plane, and hence the option should be > added to the VCCV draft. Yes, this was an omission on our part. Will fix in the next revision. > 2) On the mailing list we discussed the option of > uni-directional connectivity checks. This is covered by the > "no-reply" option, which you explicitly mention in the draft. > However, IMO you need a more complete description if you > would want to use this option for propoer fault managent. > E.g. (1) how do the sender and receiver agree on the > frequency of sending messages; (2) when do you declare a > failure? How many messages do you need to miss to conclude > that the PW is down and how many messages do you need to > receive to conclude that it is back up? Agreed. Thanks for your comments. --Tom > Otherwise, I agree with making this draft a WG document. > > Peter > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Wednesday, July 16, 2003 9:51 AM > > To: pwe3@ietf.org > > Cc: 'George Swallow'; stbryant@cisco.com; 'Danny > McPherson'; 'Monique > > Morrow (mmorrow)' > > Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > WG document? > > > > > > > > There was a good show of hands > > (fronts only) in favor of support to adopt > > the draft-nadeau-pwe3-vccv-01.txt as a > > PWE3 working group document, and none > > against. The chairs asked that we "take > > it to the list" to confirm. > > > > --Tom > > > > > > > > > > _______________________________________________ > > 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: Luca Martini Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Thu, 17 Jul 2003 05:38:29 -0600 Organization: Level3 Communications LLC. Lines: 80 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> <3F151009.B738C6EA@alcatel.com> <3F1533AE.3080608@level3.net> <3F153F86.7CA304C0@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: George Swallow , stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Jul 17 13:45:04 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: Italian [it],French/Canada [fr- To: Mustapha Aissaoui 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 Mustapha, my statement is simple: PW PID == an MPLS label + control plane assignment. In the end there is very little difference in assigning another label in the form of a pw PID , or in the form of an MPLS label to the packet. Why would one build specialized hardware to support a minority of protocols , when we can all lump it into MPLS and using current forwarding hardware. Luca 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 >>> >> > 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: Thu, 17 Jul 2003 08:06:12 -0400 Organization: Alcatel Networks Corporaton Lines: 98 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> <3F151009.B738C6EA@alcatel.com> <3F1533AE.3080608@level3.net> <3F153F86.7CA304C0@alcatel.com> <3F168AB5.7070201@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: George Swallow , stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Jul 17 14:07:04 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Luca Martini Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, you are still talking about option 2, which is assigning a label for each user protocol. This means the PE will need to break each FR VC into a multitude of PWs (1-to-N) and signal the association to the remote PE. In my view, this is much more complex than a simple PID translation. As for the specialized hardware, a device which manipulates the MPLS/PW PID for the LSP-Ping/VCCV will be capable of doing a straighforward tranlsation towards Ethernet or FR PID. As I said in my presentation, this draft is not intended to replace the existing MPLS/PW forwarding paradigm. Is should only be used in cases where needed, like the OAM. Mustapha. --------- Luca Martini wrote: > > Mustapha, > > my statement is simple: > > PW PID == an MPLS label + control plane assignment. > > In the end there is very little difference in assigning another label in the > form of a pw PID , or in the form of an MPLS label to the packet. > Why would one build specialized hardware to support a minority of protocols , > when we can all lump it into MPLS and using current forwarding hardware. > > Luca > > 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 > >>> > >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Wei Luo Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Thu, 17 Jul 2003 11:13:57 -0700 Lines: 119 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> <3F151009.B738C6EA@alcatel.com> <3F1533AE.3080608@level3.net> <3F153F86.7CA304C0@alcatel.com> <3F168AB5.7070201@level3.net> <3F169134.AEA116B0@alcatel.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 Thu Jul 17 20:14:26 2003 Return-path: X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN To: Mustapha Aissaoui 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 First of all, what is the need to demultiplex different protocols carried in one DLCI to different PWs? Is it because you want to send them to different destinations? Not sure if the current FR switches (PEs) for legacy L2VPNs can demultiplex packets from a single DLCI into different PVCs. Suppose protocol demultiplexing is needed, you can still classify traffic from CE into different type and associate a disposition label with each type. In the hardware or software, each disposition label is associated with an action function which can be tailored for each traffic type. Therefore, the label already embeds the protocol semantics and there is no need to have another field to indicate the protocol type. Did I miss something? ---Wei Mustapha Aissaoui wrote: > > Luca, > you are still talking about option 2, which is assigning a label for > each user protocol. This means the PE will need to break each FR VC > into a multitude of PWs (1-to-N) and signal the association to the > remote PE. In my view, this is much more complex than a simple PID > translation. > > As for the specialized hardware, a device which manipulates the > MPLS/PW PID for the LSP-Ping/VCCV will be capable of doing a > straighforward tranlsation towards Ethernet or FR PID. > > As I said in my presentation, this draft is not intended to replace > the existing MPLS/PW forwarding paradigm. Is should only be used in > cases where needed, like the OAM. > > Mustapha. > --------- > Luca Martini wrote: > > > > Mustapha, > > > > my statement is simple: > > > > PW PID == an MPLS label + control plane assignment. > > > > In the end there is very little difference in assigning another label in the > > form of a pw PID , or in the form of an MPLS label to the packet. > > Why would one build specialized hardware to support a minority of protocols , > > when we can all lump it into MPLS and using current forwarding hardware. > > > > Luca > > > > 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 bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:45 2006 From: "Vishal Sharma" Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers Date: Thu, 17 Jul 2003 12:13:51 -0700 Lines: 150 Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Tom Nadeau" , "Monique J. Morrow" X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Thu Jul 17 21:13:17 2003 Return-path: To: "CCAMP" , "MPLS" , "PPVPN" , "PEW3" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SMTP-HELO: smtp018.mail.yahoo.com X-SMTP-MAIL-FROM: v.sharma@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp018.mail.yahoo.com [216.136.174.115] Status: O Folks, Thanks to those who responded to our earlier announcement of this Feature Topic issue, with an intent to contribute. For those who may have missed the earlier email, or for those who've been working in this area and thinking of contributing, we'd very much encourage you to consider sending in your contributions. It is your high-quality papers, thoughts, and insights that will make this issue a valuable one for our industry. So, if you'd like to submit a paper or if you have a question or clarification, please do drop one of the Guest Editors a note, as that is very useful in helping us plan the issue. We look forward to your participation! Thanks, -Vishal PS: The submission process is automated and very easy. Pl. check instructions below. ************************************* Vishal Sharma Metanoia, Inc. http://www.metanoia-inc.com ************************************* ==================================================================== CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "OAM in MPLS-Based Networks" ********************************************** As carriers and service providers converge multiple services and associated networks on to an MPLS-based infrastructure, OAM functionality becomes pivotal for enabling them to provide service level agreement (SLA) guarantees, service assurance, quality of service (QoS) assurance and overall interworking service management. The advent of new applications of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs) also means the emergence of added OAM requirements from operators deploying those networks. As a result, providers today require more efficient means of monitoring network health, performance, and robustness, and of quickly identifying and resolving performance problems. This is leading to the emergence of improved or novel tools and techniques, whose goal is to improve security and billing/accounting, aid in verifying QoS commitments, and reduce operating costs. Standards organizations such as the IETF and the ITU have in the recent past done significant work in this area, and this subject is also being investigated by the IEEE and the Metro Ethernet Forum. This feature topic issue of the IEEE Communications Magazine has a dual focus: to highlight operator requirements and deployment experiences with OAM in MPLS-based networks, and to present a survey of the current engineering and research developments in this area. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but not limited to) the following: * Operational consequences of inadequate OAM capabilities * Service provider requirements for efficient OAM - current operational needs and future demands * Deployment experiences with OAM over MPLS-based networks * Overview or comparative analysis of different approaches/philosophies for OAM * Standards activities o Emerging architectures o New mechanisms for OAM in development (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit connection verification (VCCV)) * Platform support for OAM * OAM impact on edge services (such as metro Ethernet) using MPLS transport * Interoperability issues, interworking with other technologies (e.g. ATM) * Review of current research in the area - E.g. setting parameters for connectivity verification and their impact on LSP recovery, trade-offs between bandwidth usage by OAM traffic and efficiency of failure/anomaly detection, and results from testbed deployments or simulations On-line CFP with submission instructions can be found at: http://www.comsoc.org/pubs/commag/cfpcommag1004.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at: http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no later than November 30, 2003. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Schedule: Manuscript Due: November 30, 2003 Acceptance Notification: February 28, 2004 Final Manuscript Due: April 15, 2004 Publication Date: October 2004 Guest Editors: Monique J. Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Tom Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824, USA. Email: tnadeau@cisco.com Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA. Email: v.sharma@ieee.org About the IEEE Communications Magazine: The IEEE Comm. Mag. is the official technical publication of conferences such as Supercomm, and has the unique distinction of being the most widely read IEEE journal, with its over 50,000 paid subscribers representing key communications engineers and technical managers in our industry. More information on the IEEE Comm. Mag., may be found here: www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Thu, 17 Jul 2003 15:55:40 -0400 Lines: 25 Sender: pwe3-admin@ietf.org References: <3F16E765.FA9B401@cisco.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Mustapha Aissaoui , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Jul 17 21:56:08 2003 Return-path: To: Wei Luo In-reply-to: Your message of Thu, 17 Jul 2003 11:13:57 -0700. <3F16E765.FA9B401@cisco.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Wei> First of all, what is the need to demultiplex different protocols Wei> carried in one DLCI to different PWs? Is it because you want to send Wei> them to different destinations? Not sure if the current FR switches Wei> (PEs) for legacy L2VPNs can demultiplex packets from a single DLCI into Wei> different PVCs. If I understand correctly, what they are worried about is service interworking, e.g., frame relay on one side and ethernet on the other. To do this kind of interworking, you need to be able to tell that a packet received on the frame relay link is, e.g., an IP packet, so that you can put on the proper IP-in-ethernet encapsulation at the other end. One can't say this is "useless", the use is clear enough. But: - As Tom points out, service interworking is out of scope. - There are other methods of doing service interworking (such as carrying the Frame Relay encaps across the pw, and then doing "ordinary" FR-to-ethernet translation at the other endpoint), and there's no consensus within the WG of the best way. - There are other possible methods of demultiplexing, using MPLS labels. However, without a charter change, discussion of this topic is academic. 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, 18 Jul 2003 10:06:15 -0400 Organization: Alcatel Networks Corporaton Lines: 46 Sender: pwe3-admin@ietf.org References: <200307171955.h6HJteAi011650@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Wei Luo , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Jul 18 16:08:59 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: erosen@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 Eric, Eric Rosen wrote: > > Wei> First of all, what is the need to demultiplex different protocols > Wei> carried in one DLCI to different PWs? Is it because you want to send > Wei> them to different destinations? Not sure if the current FR switches > Wei> (PEs) for legacy L2VPNs can demultiplex packets from a single DLCI into > Wei> different PVCs. > > If I understand correctly, what they are worried about is service > interworking, e.g., frame relay on one side and ethernet on the other. To > do this kind of interworking, you need to be able to tell that a packet > received on the frame relay link is, e.g., an IP packet, so that you can > put on the proper IP-in-ethernet encapsulation at the other end. > > One can't say this is "useless", the use is clear enough. But: > > - As Tom points out, service interworking is out of scope. 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. > > - There are other methods of doing service interworking (such as carrying > the Frame Relay encaps across the pw, and then doing "ordinary" > FR-to-ethernet translation at the other endpoint), and there's no > consensus within the WG of the best way. 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. > - There are other possible methods of demultiplexing, using MPLS labels. > > However, without a charter change, discussion of this topic is academic. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Fri, 18 Jul 2003 10:29:15 -0400 Lines: 41 Sender: pwe3-admin@ietf.org References: <3F17FED7.34F35151@alcatel.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Wei Luo , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Jul 18 16:30:06 2003 Return-path: To: Mustapha Aissaoui In-reply-to: Your message of Fri, 18 Jul 2003 10:06:15 -0400. <3F17FED7.34F35151@alcatel.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > 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. Sure, if service interworking is added to the charter then we'll need to consider 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. What about doing the translation to ethernet formats at the FR end? I don't think we're ready to rule this out. > 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. No, I don't think that this is obviously more complex than the alternatives. I can see an issue in having to maintain state for an increased number of pws, but a slight alternative might be to allow more than one label to be used per pw, with the different labels invoking different encapsulations at the receiving endpoint. (This would be something like having multiple streams on a pw, with an MPLS label for each stream.) > 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. Well, it's another thing that has to be looked up at the egress PE before you can send the frame out to the CE, so I think it IS a modification to the forwarding paradigm. My real worry about this alternative is that it might just be the tip of the iceberg; I don't think we want a large "how to interwork FR with ethernet" project in the IETF. 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, 18 Jul 2003 16:51:08 -0400 Organization: Alcatel Networks Corporaton Lines: 65 Sender: pwe3-admin@ietf.org References: <200307181429.h6IETGAi022736@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Wei Luo , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Jul 18 22:54:09 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: erosen@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 Eric, Eric Rosen 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. > > Sure, if service interworking is added to the charter then we'll need to > consider 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. > > What about doing the translation to ethernet formats at the FR end? I don't > think we're ready to rule this out. I do not rule this out. I think it is also a valid option. Though, I prefer to keep the MAC address discovery as close as possible to the Ethernet PE. > > 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. > > No, I don't think that this is obviously more complex than the > alternatives. > > I can see an issue in having to maintain state for an increased number of > pws, but a slight alternative might be to allow more than one label to be > used per pw, with the different labels invoking different encapsulations at > the receiving endpoint. (This would be something like having multiple > streams on a pw, with an MPLS label for each stream.) This starts to look more like multilink FR or Inverse Multiplexing over ATM (IMA). I am not sure I want to go down that path. In general, it is expected not to mess with customer traffic in a L2 service. > > 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. > > Well, it's another thing that has to be looked up at the egress PE before > you can send the frame out to the CE, so I think it IS a modification to the > forwarding paradigm. It is not. On egress, you are still moving payload from a single PW to a single attachment circuit. What changes is the PID to be translated. YOu can view this as part of the payload manipulation since forwarding is essentially the same (i.e., all what arrives on that PW goes out on the same AC). However, the 1-to-N PW option above is clearly a new forwarding paradigm. That is why I am reluctant to go down that path. > My real worry about this alternative is that it might just be the tip of the > iceberg; I don't think we want a large "how to interwork FR with ethernet" > project in the IETF. I share your concern. I personally believe that this kind of interworking cannot be generalized. I am looking for a practical solution for a situation that some of my customers are facing. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Sat, 19 Jul 2003 16:03:23 +0200 Lines: 143 Sender: pwe3-admin@ietf.org References: <002001c34c54$309327a0$44d9a051@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Busschbach, Peter B \(Peter\)'" , pwe3@ietf.org, "'George Swallow'" , stbryant@cisco.com, "'Danny McPherson'" , "'Monique Morrow (mmorrow)'" X-From: pwe3-admin@ietf.org Sat Jul 19 16:05:02 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: tnadeau@cisco.com In-Reply-To: <002001c34c54$309327a0$44d9a051@amer.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/19/2003 16:03:29, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/19/2003 16:03:40, Serialize complete at 07/19/2003 16:03:40 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 thomas, i agree to make this a wg document, also one or two comments that you may want to take into account in the next revision: - in the following sentence, i guess that LSR refers to the receving PE "In this case, the LSR SHOULD increment an error counter and optionally issues a system and/or SNMP notification to indicate to the system administrator that a mis-configuration exists." - in section 4.2.1 it is difficult to map the description of the tlv with the field, additional details wouldn't be superfluous here - i don't see what you mean by the following sentence "The requesting PE MAY indicate multiple *IP control* IP control channel options." - seems appropriate to indicate to which spec. you refer to "older" in the following sentence "This last method MUST be supported by all PEs in order to handle backward- compatibility with older PEs." - does the following mean that you would allow for a complete review "If the requesting PE wishes to continue, it may choose different options and try to signal the PE again." you may want to recommend a preferred method here ? some edito's: - i would explain a bit more what's meant by the last part of the following sentence "Packets sent across this channel are IP packets, allowing maximum flexibility." in ... ? - "These messages, referred to as VCCV messages, are exchanged only after the desire to exchange such traffic has been negotiated between the PEs (see section 8)." -> section 8 is "references" - vccv parameters cc types (same for the vc types): "0x1 OAM Flag set in PWE header 0x2 MPLS Router Alert Label" is it 0x01 or Ox10 ? thanks, - dimitri. Thomas D. Nadeau wrote: > > Hi Peter, > > >>Tom, >> >>I have two comments on the draft: >> >>1) Regarding the MPLS case, I think there should be an option >>to indicate that the reply message should be sent over the >>"return LSP", i.e. the other half of the PW under test. The >>LSP-ping draft doesn't allow for the option to send a reply >>through the MPLS data plane, and hence the option should be >>added to the VCCV draft. > > > Yes, this was an omission on our part. Will fix in > the next revision. > > >>2) On the mailing list we discussed the option of >>uni-directional connectivity checks. This is covered by the >>"no-reply" option, which you explicitly mention in the draft. >>However, IMO you need a more complete description if you >>would want to use this option for propoer fault managent. >>E.g. (1) how do the sender and receiver agree on the >>frequency of sending messages; (2) when do you declare a >>failure? How many messages do you need to miss to conclude >>that the PW is down and how many messages do you need to >>receive to conclude that it is back up? > > > Agreed. > > Thanks for your comments. > > --Tom > > >>Otherwise, I agree with making this draft a WG document. >> >>Peter >> >> >>>-----Original Message----- >>>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>Sent: Wednesday, July 16, 2003 9:51 AM >>>To: pwe3@ietf.org >>>Cc: 'George Swallow'; stbryant@cisco.com; 'Danny >> >>McPherson'; 'Monique >> >>>Morrow (mmorrow)' >>>Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a >> >>WG document? >> >>> >>> >>> There was a good show of hands >>>(fronts only) in favor of support to adopt >>>the draft-nadeau-pwe3-vccv-01.txt as a >>>PWE3 working group document, and none >>>against. The chairs asked that we "take >>>it to the list" to confirm. >>> >>> --Tom >>> >>> >>> >>> >>>_______________________________________________ >>>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 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Tue, 22 Jul 2003 15:08:18 -0400 Organization: Cisco Systems Lines: 163 Sender: pwe3-admin@ietf.org References: <3F194FAB.3030606@alcatel.be> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "'Busschbach, Peter B \(Peter\)'" , , "'George Swallow'" , , "'Danny McPherson'" , "'Monique Morrow \(mmorrow\)'" X-From: pwe3-admin@ietf.org Tue Jul 22 21:10:35 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F194FAB.3030606@alcatel.be> Importance: Normal 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 Thanks for the comments. Will incorporate them in the next edits. --Tom > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Saturday, July 19, 2003 10:03 AM > To: tnadeau@cisco.com > Cc: 'Busschbach, Peter B (Peter)'; pwe3@ietf.org; 'George > Swallow'; stbryant@cisco.com; 'Danny McPherson'; 'Monique > Morrow (mmorrow)' > Subject: Re: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > WG document? > > > hi thomas, i agree to make this a wg document, > > also one or two comments that you may want to take > into account in the next revision: > > - in the following sentence, i guess that LSR refers to > the receving PE "In this case, the LSR SHOULD increment > an error counter and optionally issues a system and/or > SNMP notification to indicate to the system administrator > that a mis-configuration exists." > > - in section 4.2.1 it is difficult to map the description > of the tlv with the field, additional details wouldn't > be superfluous here > > - i don't see what you mean by the following sentence > "The requesting PE MAY indicate multiple *IP control* > IP control channel options." > > - seems appropriate to indicate to which spec. you refer > to "older" in the following sentence "This last method > MUST be supported by all PEs in order to handle backward- > compatibility with older PEs." > > - does the following mean that you would allow for a > complete review "If the requesting PE wishes to continue, > it may choose different options and try to signal the > PE again." you may want to recommend a preferred method > here ? > > some edito's: > - i would explain a bit more what's meant by the last part > of the following sentence "Packets sent across this > channel are IP packets, allowing maximum flexibility." > in ... ? > - "These messages, referred > to as VCCV messages, are exchanged only after the desire to > exchange such traffic has been negotiated between the PEs > (see section 8)." > -> section 8 is "references" > - vccv parameters cc types (same for the vc types): > "0x1 OAM Flag set in PWE header > 0x2 MPLS Router Alert Label" > is it 0x01 or Ox10 ? > > thanks, > - dimitri. > > Thomas D. Nadeau wrote: > > > > > Hi Peter, > > > > > >>Tom, > >> > >>I have two comments on the draft: > >> > >>1) Regarding the MPLS case, I think there should be an option > >>to indicate that the reply message should be sent over the > >>"return LSP", i.e. the other half of the PW under test. The > >>LSP-ping draft doesn't allow for the option to send a reply > >>through the MPLS data plane, and hence the option should be > >>added to the VCCV draft. > > > > > > Yes, this was an omission on our part. Will fix in > > the next revision. > > > > > >>2) On the mailing list we discussed the option of > >>uni-directional connectivity checks. This is covered by the > >>"no-reply" option, which you explicitly mention in the draft. > >>However, IMO you need a more complete description if you > >>would want to use this option for propoer fault managent. > >>E.g. (1) how do the sender and receiver agree on the > >>frequency of sending messages; (2) when do you declare a > >>failure? How many messages do you need to miss to conclude > >>that the PW is down and how many messages do you need to > >>receive to conclude that it is back up? > > > > > > Agreed. > > > > Thanks for your comments. > > > > --Tom > > > > > >>Otherwise, I agree with making this draft a WG document. > >> > >>Peter > >> > >> > >>>-----Original Message----- > >>>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>>Sent: Wednesday, July 16, 2003 9:51 AM > >>>To: pwe3@ietf.org > >>>Cc: 'George Swallow'; stbryant@cisco.com; 'Danny > >> > >>McPherson'; 'Monique > >> > >>>Morrow (mmorrow)' > >>>Subject: [PWE3] Accept draft-nadeau-pwe3-vccv-01.txt as a > >> > >>WG document? > >> > >>> > >>> > >>> There was a good show of hands > >>>(fronts only) in favor of support to adopt > >>>the draft-nadeau-pwe3-vccv-01.txt as a > >>>PWE3 working group document, and none > >>>against. The chairs asked that we "take > >>>it to the list" to confirm. > >>> > >>> --Tom > >>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>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 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 23 Jul 2003 12:06:14 -0400 Lines: 31 Sender: pwe3-admin@ietf.org References: <3F185DBC.A4B3CD45@alcatel.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Wei Luo , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Wed Jul 23 18:11:01 2003 Return-path: To: Mustapha Aissaoui In-reply-to: Your message of Fri, 18 Jul 2003 16:51:08 -0400. <3F185DBC.A4B3CD45@alcatel.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric> Well, it's another thing that has to be looked up at the egress PE Eric> before you can send the frame out to the CE, so I think it IS a Eric> modification to the forwarding paradigm. Mustapha> It is not. On egress, you are still moving payload from a single Mustapha> PW to a single attachment circuit. What changes is the PID to be Mustapha> translated. You can view this as part of the payload manipulation Mustapha> since forwarding is essentially the same (i.e., all what arrives Mustapha> on that PW goes out on the same AC). However, the 1-to-N PW Mustapha> option above is clearly a new forwarding paradigm. That is why I Mustapha> am reluctant to go down that path. We seem to mean different things by "forwarding paradigm". By "forwarding paradigm", I mean "receive an MPLS packet, look up the label, determine the rewrite string (i.e., the header modifications) and the outgoing interface." So if you can't determine the header modifications without looking up something in addition to the label, the "forwarding paradigm" is changed. The need to look up something other than the label may significantly impact performance in certain systems, which is why I think it important to try to avoid. Note that the distinction between 1-1 and 1-N forwarding that you mention above doesn't impact the "forwarding paradigm" as I defined it. There are cases in which the forwarding paradigm (as I defined it) cannot work unchanged. E.g., if the egress PE is forwarding an IP packet out an ethernet interface, it may be necessary to consult the ARP table in order to produce the rewrite string. I think of this as a necessary evil. What you are suggesting is no worse than that, but still something that might be worth avoiding. 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, 23 Jul 2003 13:42:38 -0400 Organization: Alcatel Networks Corporaton Lines: 58 Sender: pwe3-admin@ietf.org References: <200307231606.h6NG6EAi026113@rtp-core-2.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 Wed Jul 23 19:46:27 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: erosen@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 Eric, Eric Rosen wrote: > > Eric> Well, it's another thing that has to be looked up at the egress PE > Eric> before you can send the frame out to the CE, so I think it IS a > Eric> modification to the forwarding paradigm. > > Mustapha> It is not. On egress, you are still moving payload from a single > Mustapha> PW to a single attachment circuit. What changes is the PID to be > Mustapha> translated. You can view this as part of the payload manipulation > Mustapha> since forwarding is essentially the same (i.e., all what arrives > Mustapha> on that PW goes out on the same AC). However, the 1-to-N PW > Mustapha> option above is clearly a new forwarding paradigm. That is why I > Mustapha> am reluctant to go down that path. > > We seem to mean different things by "forwarding paradigm". By "forwarding > paradigm", I mean "receive an MPLS packet, look up the label, determine the > rewrite string (i.e., the header modifications) and the outgoing interface." > So if you can't determine the header modifications without looking up > something in addition to the label, the "forwarding paradigm" is changed. > The need to look up something other than the label may significantly impact > performance in certain systems, which is why I think it important to try to > avoid. MA> Well, what you describe here is what we do in all PWE encapsulations. We need to interpret the header in the received packet in order to create the new payload to be sent out on the outgoing interface. For example, in the ATM encapsulation, there is a bit which says what encapsulation it is using (cell of AAL5 frame mode). As far as I am concerned, this is all part of payload manipulation. Forwarding is always based on the received label or attachement circuit identifier. In contrast, in the 1-N option, the PE requires the knowledge of the FR DLCI plus the RFC2427 PID in order to determine the outgoing PW label. Is this not a change in the forwarding paradigm we currently use in MPLS and PWE3? > Note that the distinction between 1-1 and 1-N forwarding that you mention > above doesn't impact the "forwarding paradigm" as I defined it. > > There are cases in which the forwarding paradigm (as I defined it) cannot > work unchanged. E.g., if the egress PE is forwarding an IP packet out an > ethernet interface, it may be necessary to consult the ARP table in order to > produce the rewrite string. I think of this as a necessary evil. What you > are suggesting is no worse than that, but still something that might be > worth avoiding. MA> My main issue with the 1-N is the troubleshooting of such a mechanism (OAM, etc). Also, there is a concern that customer traffic is split over multiple PWs and this can impact the transparency of the service. Though, I agree that interworking between dissimilar L2 technologies is not trivial and there are many higher-layer protocol specific issues that need to be resolved. So, I think there will be many neccessary evils to deal with. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Wed, 23 Jul 2003 14:00:34 -0400 Organization: Cisco Systems Lines: 110 Sender: pwe3-admin@ietf.org References: <3F1EC90E.AB7345E7@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Wed Jul 23 20:03:33 2003 Return-path: To: "'Mustapha Aissaoui'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F1EC90E.AB7345E7@alcatel.com> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mustapha Aissaoui > Sent: Wednesday, July 23, 2003 1:43 PM > To: erosen@cisco.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > > Eric, > > Eric Rosen wrote: > > > > Eric> Well, it's another thing that has to be looked up at the > > Eric> egress PE before you can send the frame out to > the CE, so I > > Eric> think it IS a modification to the forwarding paradigm. > > > > Mustapha> It is not. On egress, you are still moving > payload from a > > Mustapha> single PW to a single attachment circuit. What > changes is > > Mustapha> the PID to be translated. You can view this as > part of the > > Mustapha> payload manipulation since forwarding is > essentially the same (i.e., all what arrives > > Mustapha> on that PW goes out on the same AC). > However, the 1-to-N PW > > Mustapha> option above is clearly a new forwarding > paradigm. That is > > Mustapha> why I am reluctant to go down that path. > > > > We seem to mean different things by "forwarding paradigm". By > > "forwarding paradigm", I mean "receive an MPLS packet, look up the > > label, determine the rewrite string (i.e., the header > modifications) > > and the outgoing interface." So if you can't determine > the header > > modifications without looking up something in addition to the > > label, the "forwarding paradigm" is changed. The need to look up > > something other than the label may significantly impact > performance > > in certain systems, which is why I think it important to try to > > avoid. > > MA> Well, what you describe here is what we do in all PWE > encapsulations. We need to interpret the header in the > received packet in order to create the new payload to be sent > out on the outgoing interface. For example, in the ATM > encapsulation, there is a bit which says what encapsulation > it is using (cell of AAL5 frame mode). First, why are you creating a new payload on the outgoing side and not just changing the payload encapsulation? Also, we discussed this issue during the PWE3 meeting (and I think Eric re-stated this above). As I recall, it was pointed out by several people that if the PEs remember which label has been bound to which VC, then you can use this information decapsulate and forward traffic from any VC. If you are worried about different ATM encap types, bind a different label to each VC as you signal it and remember the specific encap type. When the packets from that VC come back, you know precisely how to forward them out the disposition interface. I don't understand why this simple algorithm is insufficient to address the case you are giving above. Are you concerned about running out of labels or something? --Tom > As far as I am concerned, this is all part of payload > manipulation. Forwarding is always based on the received > label or attachement circuit identifier. In contrast, in the > 1-N option, the PE requires the knowledge of the FR DLCI plus > the RFC2427 PID in order to determine the outgoing PW label. > Is this not a change in the forwarding paradigm we currently > use in MPLS and PWE3? > > > Note that the distinction between 1-1 and 1-N forwarding > that you > > mention above doesn't impact the "forwarding paradigm" as I > > defined it. > > > > There are cases in which the forwarding paradigm (as I > defined it) cannot > > work unchanged. E.g., if the egress PE is forwarding an > IP packet out an > > ethernet interface, it may be necessary to consult the ARP table in > > order to produce the rewrite string. I think of this as a > necessary > > evil. What you are suggesting is no worse than that, but still > > something that might be worth avoiding. > > MA> My main issue with the 1-N is the troubleshooting of such a > mechanism (OAM, etc). Also, there is a concern that customer > traffic is split over multiple PWs and this can impact the > transparency of the service. > > Though, I agree that interworking between dissimilar L2 > technologies is not trivial and there are many higher-layer > protocol specific issues that need to be resolved. So, I > think there will be many neccessary evils to deal with. > > _______________________________________________ > 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, 23 Jul 2003 14:30:30 -0400 Organization: Alcatel Networks Corporaton Lines: 80 Sender: pwe3-admin@ietf.org References: <00bf01c35144$50d22080$e2371e42@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jul 23 20:31:38 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: tnadeau@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 "Thomas D. Nadeau" wrote: > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Mustapha Aissaoui > > Sent: Wednesday, July 23, 2003 1:43 PM > > To: erosen@cisco.com > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4 > > > > > > Eric, > > > > Eric Rosen wrote: > > > > > > Eric> Well, it's another thing that has to be looked up at the > > > Eric> egress PE before you can send the frame out to > > the CE, so I > > > Eric> think it IS a modification to the forwarding paradigm. > > > > > > Mustapha> It is not. On egress, you are still moving > > payload from a > > > Mustapha> single PW to a single attachment circuit. What > > changes is > > > Mustapha> the PID to be translated. You can view this as > > part of the > > > Mustapha> payload manipulation since forwarding is > > essentially the same (i.e., all what arrives > > > Mustapha> on that PW goes out on the same AC). > > However, the 1-to-N PW > > > Mustapha> option above is clearly a new forwarding > > paradigm. That is > > > Mustapha> why I am reluctant to go down that path. > > > > > > We seem to mean different things by "forwarding paradigm". By > > > "forwarding paradigm", I mean "receive an MPLS packet, look up the > > > label, determine the rewrite string (i.e., the header > > modifications) > > > and the outgoing interface." So if you can't determine > > the header > > > modifications without looking up something in addition to the > > > label, the "forwarding paradigm" is changed. The need to look up > > > something other than the label may significantly impact > > performance > > > in certain systems, which is why I think it important to try to > > > avoid. > > > > MA> Well, what you describe here is what we do in all PWE > > encapsulations. We need to interpret the header in the > > received packet in order to create the new payload to be sent > > out on the outgoing interface. For example, in the ATM > > encapsulation, there is a bit which says what encapsulation > > it is using (cell of AAL5 frame mode). > > First, why are you creating a new payload on the outgoing > side and not just changing the payload encapsulation? > Also, we discussed this issue during the PWE3 meeting (and I > think Eric re-stated this above). As I recall, it was pointed > out by several people that if the PEs remember which label has > been bound to which VC, then you can use this information > decapsulate and forward traffic from any VC. If you are worried > about different ATM encap types, bind a different label to each > VC as you signal it and remember the specific encap type. When > the packets from that VC come back, you know precisely how to > forward them out the disposition interface. I don't understand > why this simple algorithm is insufficient to address > the case you are giving above. Are you concerned about > running out of labels or something? > > --Tom > Tom, I am not sure we are exactly talking about the same thing here. I am referring to a FR or ATM VC which carries more than one higher-layer protocol and which is terminated locally at a PE. It is terminated locally because the remote PE-CE interface is different, i.e., Ethernet. In this scenario, you need to identify the user payload in a PW, packet by packet, as it changes. You cannot signal it ahead of time because you do not have a priori knowledge of it. From owner-mpls@UU.NET Wed Dec 27 16:41:45 2006 From: Dave McDysan Subject: MPLS 2003 International Conference Date: Wed, 23 Jul 2003 15:00:27 -0400 Lines: 120 Sender: owner-mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-From: owner-mpls@UU.NET Wed Jul 23 23:33:40 2003 Return-path: To: Mpls , Ccamp , l2vpn@ietf.org, l3vpn@ietf.org, pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk Status: O MPLS 2003 International Conference Omni Shoreham Hotel, Washington D.C. October 26-28, 2003 ================================================================== http://www.mpls2003.com ================================================================== You are cordially invited to attend the MPLS 2003 International Conference to be held in Washington D.C. October 26-28, 2003 hosted by ISOCORE. The 3-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. Registration for the conference is now open. Early registration discounts are extremely lucrative and are valid for a limited time only. To register, go to: http://www.mpls2003.com/registration.htm Important Dates: --------------------- - Early Registration Rates Cut-Off Date: July 30 - Tutorials: October 26, 9:00am - 5:30 pm - Conference sessions: October 27-28, 8:45am-6:30pm - Exhibits: October 27-28, 8:45am-6:30pm Program: -------- (visit http://mpls2003.com/sessions.htm for details) Sunday October 26 Tutorial 1 Tutorial 2: VPNs Tutorial 3: Layer 2 VPNs/VPLS Tutorial 4: MPLS Security Monday, October 27 Opening remarks - Peter Hill (BellSouth Telecommunications) & Dr. Hamid Ahmadi (AT&T Labs) Introduction - Luca Martini (Level3 Communications) Keynote Session: Convergence (Service Provider's Perspective) - What is the Role of MPLS in Network Convergence? - MPLS: The Catalyst of Convergence? Session: OAM - New Developments in MPLS and IP OAM - Network Management of MPLS-based VPNs - MPLS Convergence, Control and OAM Implications - Service OA&M for MPLS VPNs Session: Reliability - High Availability for MPLS LSRs - Next Generation Core Routers: Defining IP Reliability and Resiliency - High Resiliency MPLS Network Design - Hardening MPLS-based Networks Session: L2/L3 VPNs - BGP-VPN Services: Lessons Learned - Design and Deploy Scalable Inter-AS MPLS VPNs - L2-MPLS Networks - MPLS in Multi-AS Networks Panel: MPLS as a Fusing Technology - Chair: P. Hill, VP Technology Planning & Deployment, BellSouth Telecommunications - Members: D. McDysan (MCI), C. Kalmanek (ATT), P. Delavenne (LambdaNet), R. Wilder (Masergy), R. Doukov (Flag Telecom), McManus (Verizon), C. Liljenstolpe (Cable & Wireless), Y. Sato (NTT) Tuesday, October 28 Keynote Lessons Learned - Yakov Rekhter Critical Considerations for Network Consolidation - Daniel Awduche (MCI) Session: Layer 2 Transport & Interworking over MPLS - VPLS - Remember LANE? - Transitioning a Profitable Service Portfolio to an MPLS Core Network - VPLS Provisioning, Performance and Scalability: Problems and Solutions Session: IP Optical Integration - Optical Market Forces on GMPLS - Multiservice Metro Networks in Sweden and Their Plans to Go GMPLS - Photonic Internet Laboratory: New Challenges for Future Photonic Network - Generalized VPNs (GVPNs) Session: New MPLS Features - Scalable Multicast MPLS Technology for Next Generation Broadband Services Network - Multicast Traffic Engineering with MPLS - LDP Fast Convergence - How to secure an MPLS/VPN network - Integration of IPv6 and IPv6 VPN Services over MPLS Session: Traffic Engineering - Inter-area and Inter-AS MPLS Traffic Engineering - Traffic Engineering in Hierarchical Multiprovider Networks - Multi-Region (multiarea/multiAS) Traffic Engineering - Advanced MPLS Application Testing Session: Service & Provisioning Issues - MPLS Network Management: Enterprise Deployment Management - Attracting New Enterprise Customers with MPLS VPN Services - MPLS Beyond Service Provider Cores - Critical Quality of Service Issues in MPLS Networks - Practical Implementation of Tools Allied to the Network Management of IP/MPLS-based Networks We look forward to seeing you at the Conference. Regards, Dave McDysan, Luca Martini, Bijan Jabbari From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: Minutes - PWE3 WG Meeting IETF-57, Wed 16th July 2003 Date: Fri, 25 Jul 2003 21:32:49 +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 Fri Jul 25 22:33:06 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 The following minutes were taken at the IETF PWE3 WG Comments please Stewart 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 tunnelling. 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 Vitual 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 contol 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 signalled 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 circtuit. and put IP in code pont. 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. Stewart Bryant: take WG document discussion to mailing list. Sense of the room: Yes, but continue on 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: preceeds 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 dicussed 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 correlcaton is an issue. Need to increase localityof 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. Multihop 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. Resreved 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 absense of control word, depends on implementation Rahul Aggarwal: boarderline 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'. Summarises 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 ie.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 IETF52. 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 roup 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. 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: Agress 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 ---------------------------------------- Rewrittent 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 signalling. Draft proposes mechanism for 2 Pes to exhange 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 signalling: 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 signalling., but other attributes can be exchanged e.g. IP address TLV, IP+MAC address TLV, etc. Conclusion: need generic mechanism to extend signalling in backward compatible fashion to include capability signalling. 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 proposinga 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. Signalling 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: Highlights of PWE3 WG IETF-57 Date: Fri, 25 Jul 2003 21:51:51 +0100 Organization: Cisco Systems, Inc. Lines: 18 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 Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Jul 25 22:51:46 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: jon.peterson@neustar.biz, mankin@psg.com, Danny McPherson 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 Top 5 items: 1) Requirements and Architecture drafts will go to IESG in next few days. 2) Common unstructured-TDM draft by Vainshtein and Stein by 1st Sept. Authors invited to submit their structured work as informationals. 3) All other WG-drafts in good shape, aligned with ITU, and expected to go to IESG within next 4 to 6 months. 4) draft-nadeau-pwe3-vccv-01.txt - request to list to be accepted as WG item. 5) WG will shortly transition to Internet Area. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Proceedings from PWE3 @IETF57 Date: Fri, 25 Jul 2003 15:03:53 -0600 Lines: 7 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Jul 25 23:04:56 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 Folks, all of the proceedings from the meeting (including the draft version of the minutes Stewart just posted) are now available at the following URL: http://pwe3.tcb.net/meetings/ietf57 -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Akiva Sadovski Subject: M- and V-bits in ATM VCC cell transport service Date: Sun, 27 Jul 2003 16:10:20 +0200 Lines: 33 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-admin@ietf.org Mon Jul 28 00:03:46 2003 Return-path: To: "'matthew.bocci@alcatel.co.uk,'" , >, "'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 Matthew and all, being a newcomer to atm encapsulations, i failed to understand the meaning of M- and V- bits in 7.3. ATM VCC Cell Transport Service. * M (transport mode) bit Bit (M) of the control byte indicates whether the packet contains an ATM cell or a frame payload. If set to 0, the packet contains an ATM cell. If set to 1, the PDU contains an AAL5 payload. * V (VCI present) bit Bit (V) of the control byte indicates whether the VCI field is present in the packet. If set to 1, the VCI field is present for the cell. If set to 0, no VCI field is present. In the case of a VCC, the VCI field is not required. For VPC, the VCI field is required and is transmitted with each cell. but the draft states:"VCC cell transport service is characterized by the mapping of a single ATM VCC"; therefore frames will never be carried in this encap, and there's no need to carry VCI along with payload. Why can't M- and V- bits be set to 0 at ingress and ignored at egress in this mode ? thanks in advance, Akiva From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Tim.Frost@Zarlink.Com Subject: Re: Minutes - PWE3 WG Meeting IETF-57, Wed 16th July 2003 Date: Mon, 28 Jul 2003 11:26:16 +0100 Lines: 502 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "pwe3@ietf.org" , pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Mon Jul 28 12:28:25 2003 Return-path: To: stbryant@cisco.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12 |February 13, 2003) at 07/28/2003 06:26:20 AM, Serialize complete at 07/28/2003 06:26:20 AM 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 Slight correction to my comments as reported in the minutes: 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. I actually said re-write with just *structured* - as the chairs suggested. I also wish to withdraw my comment about a final run-off, I'll go with the chairs suggestion of progressing the structured versions of draft-vainshtein and draft-anavi as informational. Regards, Tim Stewart Bryant Sent by: pwe3-admin@ietf.org 25-Jul-2003 09:32 PM Please respond to stbryant To: "pwe3@ietf.org" cc: Subject: [PWE3] Minutes - PWE3 WG Meeting IETF-57, Wed 16th July 2003 The following minutes were taken at the IETF PWE3 WG Comments please Stewart 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 tunnelling. 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 Vitual 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 contol 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 signalled 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 circtuit. and put IP in code pont. 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. Stewart Bryant: take WG document discussion to mailing list. Sense of the room: Yes, but continue on 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: preceeds 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 dicussed 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 correlcaton is an issue. Need to increase localityof 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. Multihop 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. Resreved 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 absense of control word, depends on implementation Rahul Aggarwal: boarderline 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'. Summarises 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 ie.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 IETF52. 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 roup 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. 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: Agress 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 ---------------------------------------- Rewrittent 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 signalling. Draft proposes mechanism for 2 Pes to exhange 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 signalling: 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 signalling., but other attributes can be exchanged e.g. IP address TLV, IP+MAC address TLV, etc. Conclusion: need generic mechanism to extend signalling in backward compatible fashion to include capability signalling. 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 proposinga 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. Signalling 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 _______________________________________________ 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: Request to revise Figure 11 Date: Mon, 28 Jul 2003 12:26:59 +0100 Organization: Cisco Systems, Inc. Lines: 65 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 Mon Jul 28 14:24:48 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 I am editing at add the agreed 5.4.4 changes and to change MPLS PID to PWE3 PID, and notice that we have the following: +---------------------+ | Payload | /=====================\ +--------------------------------+ H Payload Convergence H--+------>| Flags, Frag, Len, Seq #, etc | H---------------------H | +--------------------------------+ H Timing H--------->| RTP | H---------------------H | +--------------------------------+ H Sequencing H--+ | PWE3 Payload Type Ident | \=====================/ | +--------------------------------+ | PW Demultiplexer |--------->| PW Label | +---------------------+ | +--------------------------------+ | PSN Convergence |--+ +--->| Outer Label or MPLS-in-IP encap| +---------------------+ | +--------------------------------+ | PSN |-----+ +---------------------+ | Data-link | +---------------------+ | Physical | +---------------------+ Figure 11: PWE3 over an MPLS PSN using a control word At the ITU SG13 TDM meeting that followed on from ITEF-57 we descided to layer RTP over the CW and not as shown above. The CW for TDM is now ECMP safe so the PWE3 PID is not needed. TDM is the only service using RTP, and most of the key IETF TDM designers were at the meeting and bought into the agreement. I would therefore like to match the arch draft with the latest ITU text and the expected new TDM drafts. Figure 11 should therefore become: +---------------------+ | Payload | /=====================\ H Payload Convergence H--+ H---------------------H | +--------------------------------+ H Timing H--------->| RTP | H---------------------H | +--------------------------------+ H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc | \=====================/ | +--------------------------------+ | PW Demultiplexer |----+ | PWE3 Payload Type Ident | +---------------------+ | | +--------------------------------+ | PSN Convergence |--+ +---->| PW Label | +---------------------+ +--------------------------------+ | PSN |--------->| Outer Label or MPLS-in-IP encap| +---------------------+ +--------------------------------+ | Data-link | +---------------------+ | Physical | +---------------------+ Figure 11: PWE3 over an MPLS PSN using a control word Any objections? Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: M- and V-bits in ATM VCC cell transport service Date: Mon, 28 Jul 2003 09:38:47 -0400 Organization: Alcatel Networks Corporaton Lines: 62 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Matthew BOCCI , PWE3 X-From: pwe3-admin@ietf.org Mon Jul 28 15:42:06 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Akiva Sadovski X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA01093 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 Akiva, although the type of encapsulation can be inferred from the label, the M-= bit is required in the AAL5 PDU mode because you need to switch to cell mode to = carry an OAM cell. Although the V-bit is not really required in this draft, it is there for backward compatiblity reason. The ATM Forum specification for ATM-MPLS ne= twork interworking allows for a VCI optimization mode in the case of VPs with concatenation (see Section 6.3.1 of str-aic-mpls -niwf-02.02, =93ATM-MPLS= Network Interworking Version 2.0=94. Regards, Mustapha. ----------- Akiva Sadovski wrote: > Matthew and all, > being a newcomer to atm encapsulations, i failed to understand the me= aning > of M- and V- > bits in > > 7.3. ATM VCC Cell Transport Service. > > > * M (transport mode) bit > > Bit (M) of the control byte indicates whether the packet contain= s > an ATM cell or a frame payload. If set to 0, the packet contains > an ATM cell. If set to 1, the PDU contains an AAL5 payload. > > * V (VCI present) bit > > Bit (V) of the control byte indicates whether the VCI field is > present in the packet. If set to 1, the VCI field is present for > the cell. If set to 0, no VCI field is present. In the case of a > VCC, the VCI field is not required. For VPC, the VCI field is > required and is transmitted with each cell. > > > but the draft states:"VCC cell transport service is characterized by th= e > mapping of a > single ATM VCC"; therefore frames will never be carried in this encap, = and > there's no need to > carry VCI along with payload. Why can't M- and V- bits be set to 0 at > ingress and ignored at > egress in this mode ? > > thanks in advance, > Akiva > > _______________________________________________ > 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: Eric Rosen Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Mon, 28 Jul 2003 13:47:59 -0400 Lines: 19 Sender: pwe3-admin@ietf.org References: <3F1EC90E.AB7345E7@alcatel.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Jul 28 19:49:08 2003 Return-path: To: Mustapha Aissaoui In-reply-to: Your message of Wed, 23 Jul 2003 13:42:38 -0400. <3F1EC90E.AB7345E7@alcatel.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O MA> Well, what you describe here is what we do in all PWE encapsulations. We MA> need to interpret the header in the received packet in order to create MA> the new payload to be sent out on the outgoing interface. Correct. But I don't care what we do before the MPLS label goes on, I only care what we do after it goes on, ;-) since that's the only thing that affects the MPLS forwarding paradigm. So to be consistent, I should advocate that all reencapsulation be done by the ingress rather than by the egress. Unfortunately, this is not the position I was taking last week (viz., that for FR-ethernet interworking, the FR side should do everything). Okay, I see that there is an issue to be discussed if service interworking gets put in the charter. Have you compared your proposal with draft-sajassi-l2vpn-interworking- 01.txt? From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: pre-draft-ietf-pwe3-arch-05.txt Date: Mon, 28 Jul 2003 18:54:45 +0100 Organization: Cisco Systems, Inc. Lines: 56 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 Mon Jul 28 19:57:20 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 I have made the following updates to draft-ietf-pwe3-arch-04.txt Added PWE3-PID to the Terminology section < < PWE3 Payload Type A identifier used to distinguish between < Identifier an MPLS IP payload and a CW that is not < (PWE3-PID) ECMP safe. < Changed MPLS PID to PWE3 PID (or PWE3 Payload Type Identifier) everywhere as appropriate. Consistently changed the text to read "forwarder" rather than "FWRD" to make the text more readable Changed Figure 11 to: +---------------------+ | Payload | /=====================\ H Payload Convergence H--+ H---------------------H | +--------------------------------+ H Timing H--------->| RTP | H---------------------H | +--------------------------------+ H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc | \=====================/ | +--------------------------------+ | PW Demultiplexer |----+ | PWE3 Payload Type Ident | +---------------------+ | | +--------------------------------+ | PSN Convergence |--+ +---->| PW Label | +---------------------+ +--------------------------------+ | PSN |--------->| Outer Label or MPLS-in-IP encap| +---------------------+ +--------------------------------+ | Data-link | +---------------------+ | Physical | +---------------------+ Figure 11: PWE3 over an MPLS PSN using a control word (I know that I have a request to the list about this, and will change it back if that is consensus) Changed XiPeng Xiao's affiliation to Riverstone Networks Changed my own office address. I have posted a preview of the draft to ftp://ftp-eng.cisco.com/stbryant/pre-draft-ietf-pwe3-arch-05.txt I would like some quick feedback before I submit the draft in the usual way. Thanks 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: Mon, 28 Jul 2003 14:53:44 -0400 Organization: Alcatel Networks Corporaton Lines: 41 Sender: pwe3-admin@ietf.org References: <200307281748.h6SHm0MK004642@rtp-core-1.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 Mon Jul 28 20:56:16 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: erosen@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 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 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. 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. Thanks for the interesting exchange. Mustapha. ----------- Eric Rosen wrote: > MA> Well, what you describe here is what we do in all PWE encapsulations. We > MA> need to interpret the header in the received packet in order to create > MA> the new payload to be sent out on the outgoing interface. > > Correct. But I don't care what we do before the MPLS label goes on, I only > care what we do after it goes on, ;-) since that's the only thing that > affects the MPLS forwarding paradigm. > > So to be consistent, I should advocate that all reencapsulation be done by > the ingress rather than by the egress. Unfortunately, this is not the > position I was taking last week (viz., that for FR-ethernet interworking, > the FR side should do everything). > > Okay, I see that there is an issue to be discussed if service interworking > gets put in the charter. > > Have you compared your proposal with draft-sajassi-l2vpn-interworking- > 01.txt? From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Genadi Velev" Subject: RE: doubt reg draft-kawakami-mpls-lsp-vlan-00.txt (fwd) Date: Tue, 29 Jul 2003 17:04:49 +0200 Lines: 78 Sender: pwe3-admin@ietf.org References: <20030716195802.017A.KAWAKAMI.TETSU@jp.panasonic.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: , X-From: pwe3-admin@ietf.org Tue Jul 29 17:09:46 2003 Return-path: thread-index: AcNV4sFbnDQKt4Z/T2K18jXQRoPcDg== Content-Class: urn:content-classes:message Priority: normal To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20030716195802.017A.KAWAKAMI.TETSU@jp.panasonic.com> X-OriginalArrivalTime: 29 Jul 2003 15:04:49.0131 (UTC) FILETIME=[C158FBB0:01C355E2] 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 Siva, I'm sorry for the delayed reply. Your email was forwarded to me by a colleague, since I was not subscribed to the PWE3 ML at that time. Our draft (draft-kawakami-mpls-lsp-vlan-00.txt) was initially intended for the MPLS WG and not for the PWE3 WG. Thus, our method represents a technique for tunneling of Ethernet packets over VLAN tag-aware switches using a VLAN tag as a label (with other words, to form a point-to-point tunnel over an Ethernet network). Therefore, our method cannot be used as a pseudowire (tunnel) over an IP/MPLS-based network, as required in PWE3. This is the reason, why you cannot find a pseudowire label in the packet header. BTW, if you are interested, you can find a new version of this draft in: http://www.ietf.org/internet-drafts/draft-kawakami-vlan-lsp-signalling-00.tx t I hope this helps. regards, Genadi > > Forwarded by kawakami tetsuya > ----------------------- Original Message ----------------------- > From: "D Siva Kumar" > To: pwe3@ietf.org > Date: Wed, 16 Jul 2003 04:22:14 +0530 (IST) > Subject: [PWE3] doubt reg draft-kawakami-mpls-lsp-vlan-00.txt (fwd) > ---- > > > > Hi, > I have a doubt regarding encapsulation mentioned in above > draft in section 4. > > Encapsulation header is shown in the draft as: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ethernet destination address | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Ethernet source address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TPID 0x8100 | Pri | | VID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | E-Type 0x0800 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | > / Network Layer Packet (IP packet) / > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > But, in this where is the pseudowire label? directly, payload is added > after the tunnel header. > > Correct me if I am wrong and please point some references if any, > regarding this. I am a beginner in this field. > > > expecting a reply, thanks in advance. > > Siva. > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > --------------------- Original Message Ends -------------------- > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-vccv-00.txt Date: Tue, 29 Jul 2003 12:15:05 -0400 Lines: 86 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jul 29 18:20:44 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 : Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) Author(s) : T. Nadeau, R. Aggarwal Filename : draft-ietf-pwe3-vccv-00.txt Pages : 0 Date : 2003-7-29 This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with psuedowire connections. VCCV supports connection verification applications for pseudowire VCs regardless of the underlying MPLS or IP tunnel technology. VCCV makes use of IP based protocols such as Ping and MPLS-Ping to perform operations and maintenance functions. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-vccv-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-vccv-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Wei Luo Subject: Comment on draft-ietf-pwe3-control-protocol-03.txt section 5.4 Date: Tue, 29 Jul 2003 10:12:12 -0700 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Jul 29 19:16:33 2003 Return-path: X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN 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 In Section 5.4 - Requested VLAN ID. An Optional 16 bit value indicating the requested VLAN ID. This parameter MAY be used by an PE that is incapable of rewriting the 802.1Q ethernet VLAN tag on output. If the ingress PE receives this request it MAY rewrite the VLAN ID tag in input to match the requested VLAN ID. If this is not possible, and the VLAN ID does not already match configured ingress VLAN ID the PW should not be enabled.This parameter is applicable only to PW type 4. What does "PW should not be enabled" mean exactly? Unlike the MTU parameter that both PEs send and verify it, only the egress PE that doesn't perform egress VLAN rewrite sends this parameter. Suppose the ingress PE is unable or unwilling to honor ingress rewrite and both PEs have exchanged label bindings. Certainly, the ingress PE can keep the PW down in the data plane when it sees this parameter. However, from the egress PE's perspective, the PW is UP (because it doesn't know whether the ingress PE accepts or rejects it) and it will send traffic towards the ingress PE. Therefore, packets are blackholed at the ingress PE. Not a big deal except a big waste of network bandwidth and resource. ---Wei From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Fwd: [iesg-secretary #8912] ATM Forum Liaison Date: Tue, 29 Jul 2003 11:44:14 -0600 Lines: 22 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Jul 29 19:46:39 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: "Amy Katherine" > Date: Tue Jul 29, 2003 9:30:06 AM America/Denver > To: danny@tcb.net > Subject: Re: [iesg-secretary #8912] ATM Forum Liaison > Reply-To: iesg-secretary@ietf.org > > Your request #8912 was updated by amyk: > > Dear Danny, > > We have posted the ATM Forum's Liaison Statement on the IESG's > Liaison Statements page on the IETF Web site > (http://www.ietf.org/IESG/liaison.html). > > Thank you, > > The IETF Secretariat > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Fwd: ID Nits Reminder Date: Tue, 29 Jul 2003 12:06:04 -0600 Lines: 42 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Jul 29 20:16:48 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 Folks, Please note the following if you've got documents getting ready to move to the IESG... -danny Begin forwarded message: > From: IETF Secretariat > Date: Tue Jul 29, 2003 11:31:31 AM America/Denver > To: wgchairs@ietf.org > Cc: iesg@ietf.org > Subject: ID Nits Reminder > > Dear Working Group Chairs: > > In the course of your efforts, you will be submitting Internet-Drafts > to the IESG > for consideration as RFCs. Please note that all Internet-Drafts > offered for > publication as RFCs must conform to the requirements specified in ID > Nits > (http://www.ietf.org/ID-nits.html), or they will be returned to the > author(s) > for revision. Therefore, the IETF Secretariat strongly recommends > that you address > all of the issues raised in this document before submitting a request > to publish > an Internet-Draft to the IESG. The content issues should be addressed > early on > in the work since they are integral to the technical makeup of the > Internet-Draft. > > Thank you in advance for your cooperation. > > The IETF Secretariat > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: draft-fang-ppvpn-security-framework-01.txt Date: Wed, 30 Jul 2003 18:00:13 +0100 Organization: Cisco Systems, Inc. Lines: 366 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Wed Jul 30 19:04:02 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: Ron Bonica , luyuanfang@att.com X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA08150 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a good analysis of the PPVPN security issues. Of necessity it overlaps with the detailed security analysis that we need (but have not yet written) for PWE3. The overlap is not complete in that there is obviously some material here that we do not need, and there is other material that is not addressed (i.e. timing attacks on TDM PWs). It would be good if we could find a way to share this work rather than start from scratch. I have a number of detailed comments below. Regards Stewart SB> Number of authors exceeds current limit=20 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. 3. Security Threats A successful attack on a particular PPVPN or on a service provider's PPVPN infrastructure would be expected to have effects of the following unhappy sorts: SB> unhappy :( ? I think that the sentence needs rewording? In the case of PPVPNs, some parties may be in more advantaged positions that enable them to launch types of attacks not available to others. For example other PPVPN users of the same service SB> s/other PPVPN/PPVPN/ SB> Also shouldn't it now be l3vpn? Although there is some overlap SB> with l2vpn, there are important differences in the vulnerabilities. It is also useful to consider the likelihood of different sorts of threats occurring. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as: - In a TDM or ATM access network between a PPVPN user and the service provider - In an Ethernet access network SB> I am not sure that there issues are VPN specific, but we will see SB> what gets said later. - In a PPVPN contained within one service provider's network - In a PPVPN transiting the public Internet SB> It may be dangerous to differentiate from because this may change SB> within the lifetime of a service - assuming PPVPN is succesfull 3.1.3. Unauthorized Observation/Modification/Deletion of Data Traffic This refers to "sniffing" VPN packets and examining their contents. It also includes modifying the contents of packets in flight, or causing packets in flight to be discarded. Such attacks would typically occur on links in the network but might also occur in a compromised node of the network. SB> I would have thought that modification or deletion was more likely SB> in a node. SB> Under dataplane you also need to consider DOS on the PE (from either SB> inside or outside the VPN) which I do dnot think that you cover. 3.2. Attacks on the Control Plane This category encompasses attacks on the control structures operated by the PPVPN service provider. 3.2.1. Denial of Service Attacks on the Network Infrastructure DOS attacks could be mounted specifically against the mechanisms the service provider uses to provide PPVPNs e.g. IPsec, MPLS, etc., or against the general infrastructure of the service provider e.g. core routers. (The latter case is within the scope of this document only if the attack happens in relation with the VPN service, otherwise is not a PPVPN-specific issue.) Of special concern for PPVPNs is denial of service to one PPVPN user caused by the otherwise-legitimate activities of another PPVPN user. This can occur for example if one PPVPN user's activities are allowed to consume excessive network resources of any sort that are also needed to serve other PPVPN users. SB> This is a legitimate attack, but I don't think that it belongs under SB> control plane sub-heading. It is a dataplane attack. 3.2.3. Cross-connection of Traffic Between PPVPNs This refers to the event where expected isolation between separate PPVPNs is breached. This includes cases such as: - A site being connected into the "wrong" VPN - Two or more VPNs being improperly merged together - A point-to-point VPN connecting the wrong two points - Any packet or frame being improperly delivered outside the VPN it is sent in. Mis-connection or cross-connection of VPNs has a high likelihood of being the result of service provider or equipment vendor error rather than malicious action. SB> A compomised router could do this. 3.2.4. Attacks Against PPVPN Routing Protocols This encompasses attacks against routing protocols that are run by the service provider. SB> This sentence needs a scope limiting rider. In layer 3 VPNs with dynamic routing this would typically relate to the distribution of per-VPN routes as well as backbone routes. In layer 2 VPNs this would typically relate only to the distribution of backbone routes. Specific attacks against popular routing protocols have been widely studied and described in [Beard]. SB> Again I am worried about the scoping here. SB> Surely in L2 it is the distribution of VPN endpoints (or authenticati= on SB> info that is the PPVPN specific concern, general route distribution i= s SB> surely out of scope. 3.2.7. Other Attacks on PPVPN Control Traffic Besides routing and management protocols (covered separately in the previous sections) a number of other control protocols are used for membership discovery and tunnel establishment in various PPVPN approaches. These include but may not be limited to: - MPLS signaling (LDP, RSVP-TE) - IPsec signaling (IKE) - L2TP - BGP-based membership discovery - Database-based membership discovery (e.g. RADIUS-based) Attacks might subvert or disrupt the activities of these protocols, for example via impersonation or DOS attacks. SB> A network that has these vulnerabilities does not just have PPVPN SB> issues. 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? 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? 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? 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. 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). 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. 7. Provider Security Requirements The PPVPN service provider requirements defined here are the requirements for the PPVPN core in the reference model. The core network can be implemented with different types of network technologies, and each core network may use different technologies to provide the PPVPN services to users with different levels of offered security. Therefore, a PPVPN service provider may fulfill any number of the security requirements listed in this section. This ^^^^^^^^^^ SB> Surely the necessary number? These requirements are focused on: 1) how to protect the PPVPN core from various attacks outside the core including PPVPN users and non- SB> attacks originating from ...? SB> Some of this is out of scope Note that a PPVPN core is not more vulnerable against attacks than a core that does not provide PPVPNs. SB> That depends. There are for example more potential methods of SB> disguising an originator, and there are likely to be tunnel SB> endpoints that might be put to use. SB> SB> Your contrasting point is correct, but I am not sure that the SB> previous point adds value. With the cost of authentication coming down rapidly, the application of control plane authentication may not increase the cost of implementation for providers significantly, and will help to improve the security of the core. If the core is dedicated to VPN services=20 rd and without any interconnects to 3 par= ties=20 then this may reduce the requirement for authentication of the core control plane. SB> layout problem that appears in the HTML that I cut this from. Missing SB> LF? Normal TTL propagation may be altered to make the backbone look like one hop from the outside, but caution needs to be taken for loop prevention. SB> I thought that this was the default in a tunnel? This prevents the backbone addresses to be exposed through trace route, however this must also be assessed against operational requirements for end to end fault tracing. SB> Addresses? Surely hop count? I don't see how you propagate the SB> trace route packets between the user and the provider network. SB> A secure VPN infrastructure is surely a VPN wrt the user VPN, and SB> hence traffic mixing cannot occur? Many of these were not particular issues when an IP core was designed to support Internet services only. When providing PPVPN services, new requirements are introduced to satisfy the security needs for VPN services. Similar consideration apply to L2 VPN services. SB> This needs to be fleshed out. An example perhaps? 7.1.2. Data Plane Protection PPVPN using IPSec technologies provide VPN users with encryption of secure user data. In today=C6s MPLS, ATM, or Frame Relay networks, encryption is not provided as a basic feature. Mechanisms can be used to secure the MPLS data plane to secure the data carried over MPLS core. SB> But a private MPLS core switching a PW is just as secure (or insecure= ) SB> as the ATM or FR network that it is replacing. Additionally, if the core is dedicated to VPN services and without=20 rd any external interconnects to 3 party netw= orks=20 then there is no obvious need for encryption of the user data plane. SB> layout? 7.2. Protection on the User Access Link Peer / Neighbor protocol authentication may be used to enhance security. For example, BGP MD5 authentication may be used to enhance security on PE-CE links using eBGP. In the case of Inter-provider connection, authentication / encryption mechanisms between ASes, such as IPSec, may be used. SB> Is this a special to PPVPN problem? 7.2.4 Customer VPN monitoring tools End users requiring visibility of VPN specific statistics on the core e.g. routing table, interface status, QoS statistics, impose requirements for mechanisms at the PE to both validate the incoming user and limit the views available to that particular users VPN. SB> It is not clear to me that the customer has any right to these, SB> surely the customer just has the right to test the SLA from their SB> own side of the fence? 7.3. General Requirements for PPVPN Providers SB> I am not sure this section adds much value given that the reader SB> has read this far. 8.2. Template SB> I am not sure that this section adds much value 9. Security Considerations There are no further security considerations in addition to what discussed in the previous sections. SB> A Catch-22 problem if ever I saw one :) SB> It might be worth noting somewhere that most existing "physical" SB> networks are actually virtual (TDM, ATM, FR etc), and so the SB> comparision is not zero risk to PPVPN risk, but SOME risk to SB> PPVPN risk. 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, 31 Jul 2003 06:11:04 -0700 Lines: 30 Sender: pwe3-admin@ietf.org References: <200307171955.h6HJteAi011650@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Wei Luo , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Jul 31 16:58:40 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mustapha Aissaoui , erosen@cisco.com In-Reply-To: <3F17FED7.34F35151@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 > >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. >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. -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: Wed, 30 Jul 2003 13:21:58 -0700 Lines: 78 Sender: pwe3-admin@ietf.org References: <200307160824.EAA09306@bifocal.cisco.com> <3F151009.B738C6EA@alcatel.com> <3F1533AE.3080608@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: George Swallow , stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Jul 31 16:58:56 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mustapha Aissaoui , Luca Martini In-Reply-To: <3F153F86.7CA304C0@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 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 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: Ali Sajassi Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4 Date: Thu, 31 Jul 2003 07:47:44 -0700 Lines: 94 Sender: pwe3-admin@ietf.org References: <200307281748.h6SHm0MK004642@rtp-core-1.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 Jul 31 17:01:58 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mustapha Aissaoui , erosen@cisco.com In-Reply-To: <3F257138.2820BBE@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: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. >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. >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 !!! -Ali >Thanks for the interesting exchange. > >Mustapha. >----------- >Eric Rosen wrote: > > > MA> Well, what you describe here is what we do in all PWE > encapsulations. We > > MA> need to interpret the header in the received packet in order to > create > > MA> the new payload to be sent out on the outgoing interface. > > > > Correct. But I don't care what we do before the MPLS label goes on, I > only > > care what we do after it goes on, ;-) since that's the only thing > that > > affects the MPLS forwarding paradigm. > > > > So to be consistent, I should advocate that all reencapsulation be > done by > > the ingress rather than by the egress. Unfortunately, > this is not the > > position I was taking last week (viz., that for FR-ethernet > interworking, > > the FR side should do everything). > > > > Okay, I see that there is an issue to be discussed if service > interworking > > gets put in the charter. > > > > > Have you compared your proposal with draft-sajassi-l2vpn-interworking- > > 01.txt? > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3